{ linked from New User Pathway To Success Config Success - viewtopic.php?t=182373 }

Port Forwarding can fail and some of the common solutions are discussed......... (thanks to Sob for his support on this article)
This article is meant to mainly discuss both the often tripped over Hairpin NAT scenario and the extra work required to deal with a dynamic WANIP in conjunction with destination NAT.

Caution: Issues with port forwarding may indicate you do NOT have a PUBLIC IP! Are you on LTE If so jump to item 5.
Note: If you want to simply check your basic Port Forwarding associated rules/format - JUMP to item 6.

Intro: Hairpin NAT
1. Adding Source-NAT Rule (Hairpin NAT) - solutions for static, dynamic WANIPs
2. Changing Subnet of Server (avoiding Hairpin NAT)
3. DNS Method (avoiding Hairpin NAT)
4. Multiple Destination NATs & Jump (for static WAN IPs)
5. Public IP - Are you Sure?
6. NAT & IP Firewall Rules
7. Source & Destination NAT Simplified
8. Adguard / PiHole

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
HAIRPIN NAT INTRO

Unable to access your server via the DOMAIN name from the LAN??? <-------- @dhanushka
Easily solved but every person will have to decide what is the optimal way to configure their device(s) for hairpin NAT (sometimes called Loopback).

INTRO: Hairpin NAT is a funny situation of what is often incorrectly considered a dst-nat problem/variation for the case of port forwarding, (and its really a source-nat issue) where the use case describes a server on a local subnet and the local users on that subnet, as follows:

a. The server and the LAN users of the server are on the same subnet
b. The server admin requires that access to the server is provided via its domain name (external WAN IP).
i. This could be for several reasons but for example when one has multiple vlans and a standard method for access is provided that works for all users, regardless of vlan associated forward chain firewall rules.
ii. The admin for other reasons does not want users to use the LANIP address of the servers.
iii. {Leave blank for other reasons.}

There is one quick work around - Let your LAN users use the LANIP of the server!!!

If the simple work-around option is not a feasible alternative then we have to adjust the config of the Mikrotik appliance and there is one main approach dealing with Source NAT, and two other discussed options that use an approach to bypass the issue, one touching upon DNS changes and the other involves moving the Server to a different subnet. The main solution consists of using one necessary src-nat rule and various manipulations of dst-nat rules in case one's WANIP is dynamic ( properly configured fixed/static WANIP dst nat rules are already good to go). All solutions work, it depends on your particular configuration and your level of comfort in modifying the configuration. If coming from other vendors, this scenario was often handled by a simple check in a check box labelled "LOOPBACK".

RELEVANT SCENARIO INFORMATION FOR EXAMPLES
Server IP is 192.168.88.68, protocol tcp, port 12566,
WANIP=47.123.12.89 (for static examples), domain name=www.myserver.net
WANIP=dynamicIP (for dynamic examples) domain name=www.myserver.net
Alternate LAN subnet server IP192.168.50.5

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1. ADDING SOURCE-NAT RULE (HAIRPIN)

To fix the scenario where the LAN users and the Server are on the same subnet, all that is required is the following generic source NAT rule, often called the HAIRPIN NAT Rule placed as the first source NAT rule (although I have been told order here is not important). This required source NAT rule is independent of the type of WANIP (static/dynamic).

The key addition to the NAT rules is the addition of a source-nat rule placed before the default src-nat rule (substitute with your server subnet).
add chain=srcnat action=masquerade dst-address=192.168.88.0/24 src-address=192.168.88.0/24

Courtesy of Sob, (the problem):
"- user client 192.168.88.5 wants to connect to www.myserver.net, resolves hostname, gets 47.123.12.89 and sends initial packet to it
- client doesn't have any idea where 47.123.12.89 is, as far as it knows, it can be on the other side of planet
- dstnat rule changes packet's destination address to 192.168.88.68 and sends it to server
- source address is not changed, it's still 192.168.88.5 <- the problem
- server gets the packet and sends response directly to 192.168.88.5, because it's in same subnet!!
- client throws it away, because it doesn't expect any response from 192.168.88.68
the client is expecting a response from 47.xx

WHY this additional SRC NAT rule works: When the client sends the outgoing request now two things happen, the first thing is as before the destination NAT rule will change the destination from that resolved to the WANIP 47.xx to that of the Server .68, and now additionally, the outgoing traffic also gets masqueraded gets 'natted' to the subnet gateway address. Therefore the traffic is now headed to the Server with source IP address of the gateway of the subnet (vice the client). Then when the server replies to the traffic it sends the traffic back to the router as what it sees now as the source (originator of the traffic) is the IP 192.168.88.1. The router tracking the packets then applies the dst-nat rules and masquerade rules recognizing the returned traffic and thus un dst-nats the traffic from dst of 192.168.88.86 back to original dest of 47.xx and un-source nats the traffic from 192.168.88.1 to the original 192.168.88.5 and the packet arrives at the client and is accepted.

The explanation diagrams found here may be helpful(courtesy of Greg) : http://gregsowell.com/?p=4242

Finally this explanation on hairpin nat from MKX is invaluable!!
Standard SRC-NAT is masquerading source address and standard DST-NAT is masquerading destination address. And hairpin NAT is masquerading both addresses, one to each end (client doesn't use the correct dst-address and server doesn't see correct src-address).

Usual hair-pin NAT (in typical port forwarding) makes sure that the LAN client can talk to LAN server via some foreign (to both client and server) IP address, in the case of masquerading (redirecting) WANIPs, then the case becomes the WAN client talking to LAN server via some foreign (to both client and server) IP address (and that communication needs to pass router in both directions). Remember that any of the router's own IP addresses are treated equally regardless of ingress interface of a particular packet
- e.g packet targeting router's WAN IP address, ingressing through LAN interface is treated the same way as packet targeting same IP address ingressing through WAN interface.

Finally if you want to read the explanation of how using hairpin nat addresses a similar situation where the WANIP needs to be 'fixed' using source-nat (hairpin technique) for a particular scenario, look at this post! ( example of WAN Client talking to LAN server )
viewtopic.php?p=921962#p919200

A. STATIC-FIXED WAN IP.

With the above rule in place and the CORRECT DST NAT rule for static WANIPs is utilized, the router will now handle both the 'normal' external incoming requests as well as internal server requests via the dst NAT rule.
add action=dst-nat chain=dstnat dst-address=47.123.12.89 dst-port=12566 protocol=tcp to=addresses=192.168.88.68

B. DYNAMIC WANIP

Dynamic WANIP is an issue because we cannot use the DST-ADDRESS=WANIP part of the configuration due to the fact that the IP can change (hence dynamic). Most iterations of dynamic WANIP attempt to solve this particular issue. The problem is exacerbated by the fact that the often used default DSTNAT rule for dynamic WAN with in-interface-list=WAN or in-interface=eth1 will not work for internal LAN users. Using in-interface list=WAN, quite clearly excludes LAN users from the equation as they are NOT coming from the WAN interface. The following methods, shown below, attempt to address this problem by using techniques to mimic the fixed/static IP addressing standard in order to identify the current WAN interface. In other words, the admin wants to include both external and internal users by acknowledging the destination of both these groups is the current WANIP. We have to do this without using in-interface-list=LAN OR in-interface=eth1.

(i) ]DYNAMIC WAN IP Local Address approach

This method is fairly straight forward in that you config the router to use a local address as the destination address, but then deny the local subnet address to the router as an option. Effectively one is attempting to match any local interface that is not excluded. In a one subnet LAN, that leaves only the WAN interface as the only available local address for destination, success achieved. The reason we dont simply state =local address, is due to the fact that any other request on port 12566, unrelated to the server would be forwarded to the server. Not necessarily an issue with an obscure port but would be problematic lets say on port 80.
add chain=dstnat action=dst-nat dst-address-type=local dst-address=!192.168.88.1 \
protocol=tcp dst-port=12566 to-addresses=192.168.88.68

Limitations: This rule ONLY suffices for a single subnet structure behind the Router. As soon as you add more subnets/vlans the rule gets more complex and one would then have to use a firewall address list to identify all subnets on the network that should not be considered as a local subnet to force the router to choose the only remaining available local address, which then would be the WAN interface.
Add chain=dstnat action=dst-nat dst-address-type=local dst-address-list=!allsubnets \
protocol=tcp dst-port=12566 to-addresses=192.168.88.68
Where:
Add ip=subnetofserver list=allsubnets (contains users and server)
Add ip=othersubnetA list=allsubnets (contains users)
Add ip=othersubnetB list=allsubnets (contains users)
Etc.

(ii) DYNAMIC WAN IP - Firewall Address List and IP Cloud (kudos to Steveocee) ALSO GOOD FOR ANY DYNDNS URL APPROACH

This method relies upon using ones IP Cloud IP address as a firewall address list entry to replace the actual dst-address of the router. The IP Cloud function periodically updates the WAN IP every few minutes. Thus, instead of using dst-address=WAN IP one uses dst-address-list=updatedCloudIP
add chain=dstnat action=dst-nat dst-address-list=updatedCloudIP address protocol=tcp dst-port=12566 to-addresses=192.168.88.68

See https://www.youtube.com/watch?v=_kw_bQyX-3U&t=257s for an excellent presentation.

Limitations: There is a chance of a gap in correct coverage if the WANIP is changed or whatever reason in between IP Cloud updates.
Advantages:
a. Best when there is 1:1 NAT; OR
b. if the router itself doesn’t have a public IP address as the IP Cloud service will provide the correct public IP in front of your router.

(iii) DYNAMIC WAN IP - Firewall Address List and IP DHCP Client related script (most elegant and courtesy of Sob (still kicken!))

This method utilizes a script that pulls the actual WAN IP from your IP DHCP Client settings. The script also is not schedule dependent, vice the IP cloud updates method.
DHCP lease script:
:if ($bound=1) do={
/ip firewall address-list set [/ip firewall address-list find where comment="wan1ip"] address=$"lease-address" disabled=no
} else={
/ip firewall address-list set [/ip firewall address-list find where comment="wan1ip"] disabled=yes
}
Where,
/ip firewall address-list
add comment=wan1ip disabled=yes list=external_wan

Limitations: Not suited for a private WANIP setup.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AVOIDING HAIRPIN NAT RULE

2. CHANGING SUBNET OF SERVER

In this scenario, there is no requirement for a sourcenat rule addition as our effort is aimed at avoiding hairpin natting! In fact, there is no hairpin required because the server and users are now on a different subnet, HOWEVER, one has to ensure a properly formatted DST-NAT rule for the dynamic WANIP setup.

a. Fixed IP Static......... the standard DST-NAT rule will suffice.
add action=dst-nat chain=dstnat dst-address=47.123.12.89 dst-port=12566 protocol=tcp to=addresses=192.168.88.68

b. Dynamic WANIP.............
In this case the standard default dynamic dst nat rule will NOT work.
add action=dst-nat chain=dstnat in-interface-list=WAN or in-interface=eth1-WAN dst-port=12566 protocol=tcp to=addresses=192.168.88.68
INSTEAD
use one of the techniques listed abovefor dynamic WANIP
(1)B. (i), (ii), (iii)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3. DNS METHOD - AVOID NAT – REDIRECT LAN REQUEST VIA DNS (courtesy of rextended & ZeroByte)

Similar to moving the Server to a different subnet, using DNS tricks also avoids hairpin NAT.

Create the following rule!
/ip dns static
add address=192.168.88.68 regexp="(^|www\\.)myserver\\.net\$" ttl=5m

The precedence for using DNS within the router is as follows...........
a. static first,
b. static regexp next, and
c. others...

This rule tells the router that for any DNS traffic that is generated to look for the domain name www.myserver.net location, there is no need to go to dynamic servers, cached servers, external internet internet servers etc., go directly to the location of the LAN IP indicated (our Server).

Two Points and One Reminder:
(i) You'd need to make sure "allow remote request" is turned on in /IP DNS,
(ii) Ensure there are no static entries in DNS as they take precedence, and
(iii) Confirm you are using default firewall rules and specifically on the input chain, the drop all from the WAN rule:
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
OR the common replacement, as the last rule in the input chain:
add action=drop chain=input comment="drop all else"

Not really a concern with a decent firewall but in general we want to ensure that DNS requests from the internet are blocked to avoid dns-amp ddos attack etc...
One could consider invoking a raw rule dropping all DNS queries from the WAN side.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

That concludes hopefully a more full discussion of the reasons for Hairpin NAT and the options available to tackle this issue depending upon type of WAN connectivity.
Any suggestions comments additions welcome.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4. (OTHER) FIXED WANIP - MANY DST NAT RULES - USE OF JUMP. (Courtesy of Sob)

When dealing with a static IP there is a way to be more efficient with the rule set and this efficiency is also useful in case the Fixed IP changes for whatever reason.
Here is an example of how to setup JUMP rules such that the one rule is checked for WANIP only. One can intuitively see that if the IP ever changes, one only has to modify one IP address entry for potentially a long list of dst-nat rules. SWEET!
...

5. PUBLIC IP? Before tripping over hairpin NAT it is common to discover that an admins issue is the fact their public IP or so they thought is not all the public.
1) Do you know what is a public address?
2) Do you have public address? CGNAT ( aka LTE variety or STARLINK is NOT a public IP! }
3) Check with the ISP that they are not blocking ports (udp, tcp etc)

USING LTE WITH APN..........
Ensure you have a custom APN , ( not the default network APN ) from the ISP provider, which enables a Public IP!!

Checking What Your IP IS:
In other words, the admin should ensure that the WANIP the router gets is the same one that the external World sees. This can be accomplished via
a. 'whats my IP' in your browser
b. Checking the public IP that shows up when one enables IP Cloud.
c. Checking what IP address is shown under the details of IP DHCP Client
d. Checking what IP address is shown in IP routes - look for a (DAC) entry and preferred source.
They should ALL be the same if your router is getting a valid Public IP. If not, then you may be getting a private IP address from your Provider.

If the public IP is clearly not public...........
i. Call your ISP tech support and describe the issue with your WANIP addressing. It could be a misconfiguration at their end!
ii. If not a misconfiguration, ask tech support if you can get a PUBLIC IP.
iii. Ask tech support if it is possible for you to access the ISP modem/router (many do for the exact purposes of forwarding ports etc..)
iv. If you already have a password to access the ISP modem router, try to access the ISP modem/router and port forward the port needed for your server, to the WANIP of your router (a LANIP on the ISP device's subnet).

TROUBLESHOOTING BY LOGGING:
Simple.
To get a sense of what is happening with your external originated traffic you can use logging to track if traffic is reaching the router and try some online port tester and any port.
/ip firewall mangle
add chain=prerouting in-interface=<WAN> connection-state=new action=log log-prefix=INCOMING (if you have a specific dst-port and protocol include those as well)
And you need to be testing this from internet, not from device in same LAN (once it works from internet, it's possible to make it work from LAN too, but requires additional config). This will be useful information when you come to the forum for assistance.

Complex. - viewtopic.php?p=963756#p963756 (courtesy of Sob) ...

6. NAT AND IP FIREWALL RULES ---> normally consists of three rules.

For basic destination nat which includes basic port forwarding, if coming from other devices, one needs ONE firewall rule in the forward firewall filter chain. The rule (example below) basically allows port forwarding to a server on the LAN, that has a corresponding DST NAT rule in the config. Then you need DST-NAT rules fore every port forwarding, each with all the details. A source nat rule is a more general rule so that any traffic initiated by the LAN is natted by the Routers WANIP on the way out. Thus source-nat is important only if local users are directed to the server (not through LANIP) but through the WANIP.

a. Filter Rule: add chain=forward action=accept connection-nat-state=dstnat
{ any traffic with destination ports identified in DST NAT rules will be allowed through firewall }

b. Source Nat Rule:

case1: Dynamic WANIP add chain=srcnat action=masquerade out-interface-list=WAN { will also work for fixed/static WANIPs but not as technically correct }

case2: Fixed/Static WANIP add chain=srcnat action=src-nat out-interface=ether1 to-addresses=WANIP(static) { where out interface must be the active interface, pppoe1-out, vlan etc. }

c. Destination Nat Rule:

case1: Dynamic WANIP add chain=dstnat action=dst-nat dst-port=xxxx protocol=yyy in-interface-list=WAN \
to-addresses=IPof Server { to ports not required if same as dst-ports }

case2: Fixed Static WANIP add chain=dstnat action=dst-nat dst-address=WANIP(static) dst-port=xxxx \
protocol=yyy to-addresses=IPofServer to-ports=zzzz { in this case users come in on port xxxx but the port gets translated to zzzz before hitting the server }

c. Destination Port Ranges: Caution, ensure port ranges do NOT overlap with expected incoming VPN listenting ports as DST nat takes precedence over input chain rules.

7. SOURCE NAT & DESTINATION NAT SIMPLIFIED (courtesy of sob)

Masquerade is special kind of srcnat that automatically chooses source address, the one which is on outgoing interface. So if there's really just one, there's no problem, but if for some reason there are more, it may not choose the one you want. Then you'd need action=src-nat and choose one yourself. Even if you have only one, you can still use action=src-nat to-addresses=192.168.88.1.

If you have out-interface=ether1, it's just one of possible conditions, it's not linked to masquerade choosing address from outgoing interface. Masquerade will always do that, even if the rule is just: This would mean that any connection passing through router in any direction gets masqueraded. And because usually you don't want that, you can use various conditions (out-interface, src-address, dst-address, anything RouterOS allows) to limit when it happens.

SRCNAT changes source addresses and/or ports, DSTNAT changes destination addresses and/or ports. And it can be anything to anything. Most common is private addresses to public address (to access internet), but you can do any other translation you can imagine. Some will make sense and do something useful, some won't. Instead of translating your internal private addresses to your public one, you can translate them to some other private address(es), some public address(es) you don't even have, anything. Router will be happy to do it for you. Only it won't do you any good, because you won't be able to connect to anything with resulting invalid source address.

As for masquerade, let's say you have simple router with few interfaces:
- WAN with public address 1.2.3.4
- LAN1 with 192.168.88.1/24
- LAN2 with 192.168.99.1/24
- VPN with 10.20.30.40/8
If packet goes out via WAN, masquerade will use 1.2.3.4 as source, for LAN1 it will be 192.168.88.1, for LAN2 192.168.99.1, for VPN 10.20.30.40. In short, whatever is on outgoing interface.


8. Adguard / PiHole - Directing Users to Servers on LAN Subnet. (courtesy of sob)
A typical situation where one wants to ensure users are using the admin provided DNS or other server vice a typical server. The one slight twist is that for users within the same subnet of the Server, hairpin nat, just like in the case of generic servers where folks get to the server via the WANIP, also applies here where users are attempting to reach 8.8.8.8 for example but are redirected back to adguard.

In general one needs to ensure that users have access to DNS services in the input chain, if for nothing else, the Adguard/PiHole server and for any users not being directed. In addition all the users need access in the forward chain to the admin provided DNS/adguard server. The next step is to highlight the dhcp-server network settings such that the adguard/pihole IP is used where applicable (in all subnets the admin wants to force traffic to DNS/adguard with one exception). In the case of the subnet the DNS/adguard server is in, simply use the gateway of the subnet. Almost the last step are dst-nat rules to force/redirect users to the Adguar/PiHole just in case they may have IPV4 DNS settings on devices that are different. Finally, one needs to use a hairpin source nat rule for the users in the same subnet as the server.

Note: This will not prevent users that are technically savvy to use DoH to get buy such configurations. Suggest another form of discipline for these cases.

Example: VLANS 10,20,30,40,50 and they all belong to the interface list of LAN.
- Vlan 50 contains adguard/dns server on 192.168.50.50,
- Vlan 20 needs to use regular DNS from router
- Firewall address list called "excluded" includes 192.168.20.0/24 AND 192.168.50.50

Step 1.
/ip dhcp-server network
add address=192.168.10.0/24 gateway=192.168.10.1 dns-server=192.168.50.50
add address=192.168.20.0/24 gateway=192.168.20.1 dns-server=192.168.20.1
add address=192.168.30.0/24 gateway=192.168.30.1 dns-server=192.168.50.50
add address=192.168.40.0/24 gateway=192.168.40.1 dns-server=192.168.50.50
add address=192.168.50.0/24 gateway=192.168.50.1 dns-server=192.168.50.1

Step2.
input chain rules.
add chain=input action=accept in-interface-list=LAN dst-port=53 protocol=tcp
add chain=input action=accept in-interface-list=LAN dst-port=53 protocol=udp

forward chain rules
add chain=forward action=accept in-interface-list=LAN dst-address=192.168.50.50

Step3.
Dst Nat rules
add chain=dstnat action=dst-nat in-interface-list=LAN src-address-list=!excluded dst-port=53 protocol=tcp to-addresses=192.168.50.50
add chain=dstnat action=dst-nat in-interface-list=LAN src-address-list=!excluded dst-port=53 protocol=udp to-addresses=192.168.50.50

Step4.
Src Nat Hairpin Rule for Server Subnet users
add chain=srcnat action=masquerade dst-address=192.168.50.0/24 src-address=192.168.50.0/24

Note: You can be more specific and make it two rules (tcp, udp) and specific to the port if desired.

If you don't mind a bit of constructive criticism from self-proclaimed NAT expert...

You should more clearly separate hairpin NAT and proper dstnat rules, because even though here they work together, they are two completely different things.

Hairpin NAT

just fixes the problem with communication between client and server in same subnet, which is (using your addresses):

- client 192.168.88.5 wants to connect to www.myserver.net, resolves hostname, gets 47.123.12.89 and sends initial packet to it
- client doesn't have any idea where 47.123.12.89 is, as far as it knows, it can be on the other side of planet
- dstnat rule changes packet's destination address to 192.168.88.68 and sends it to server
- source address is not changed, it's still 192.168.88.5 <- the problem
- server gets the packet and sends response directly to 192.168.88.5, because it's in same subnet
- client throws it away, because it doesn't expect any response from 192.168.88.68

The problem is fixed by adding single srcnat rule (if you have one LAN subnet; otherwise individual rules for each subnet, but only for subnets containing both clients and servers that need to communicate), which must change source address in a way that server will send response back to router. A quick fix is what you have:
But it's not the only way. Masquerade will use address from router's LAN interface (192.168.88.1), but it would work with any other address which server can access only via this router, so basically anything not in local subnet. I personally like to use router's public address (it functions the same, but looks better in server logs):
Or it can be any random address (preferably something not used anywhere else) you choose to clearly distinguish connections from LAN. It can be even whole subnet (same size as LAN subnet), if you insist that you must be able to tell internal clients from each other (it's not perfect, because 192.168.99.X is not real address, but at least X stays the same):
If you're perfectionist, you can exclude connections from router itself using src-address-type=!local. Usually it doesn't matter, but it could be useful for some configs, e.g. if router has more addresses from same LAN subnet for some reason.

Proper dstnat rules

is actually what many (most?) people struggle with. Hairpin NAT (described above) is just one static rule, it's foolproof, you can't mess it up (ok, I know I underestimate creativity of some people), dstnat is the hard one (relatively). The rule is:
Key element is <destination>. The Right Way™ is dst-address=47.123.12.89, because it does exactly what you need, nothing less and nothing more. Trouble is, you need to input the right address, which is easy for static one, but less easy otherwise.

With dynamic addresses, probably the most common workaround or shortcut (and then also a problem, so it should be mentioned) is in-interface=WAN (or in-interface-list=WAN). It works for connections from outside, but it clearly can't match connections from LAN. People often add correct hairpin (srcnat) rule and then wonder why it doesn't work, when they have wrong dstnat rules like this.

Better workaround is dst-address-type=local dst-address=!192.168.88.1, which you have as (4), but I don't like the explanation very much. The idea behind that is to match any address assigned to router (it would be enough for use with hairpin), but exclude router's LAN address, because you may want e.g. public web server on port 80, but you also want to access WebFig from LAN on same port 80, which would not be possible with just dst-address-type=local alone, because everything would be forwarded to web server). This is probably fine for most cases, but remember, it's still workaround with possible unwanted side effects. What you really want is to match one address, but it matches all router's addresses you don't exclude. If that's a problem for you, it's possible to use dst-address or dst-address-list even with dynamic addresses (5) or (6). But still, major advantage of this workaround is that it's static, there are no moving parts that could break. The other ones shouldn't either, but here it's pretty much guaranteed.

-

Few other things:

The whole exercise with another subnet seems pointless to me. Sure, it's a valid solution, but what's the extra config for? You don't need any of that, just add proper dstnat rules (see above) and that's all.

About the DNS-based solution (1), in a way it's a correct one, because if server is 192.168.88.68, then it's right for hostname to point to 192.168.88.68. But it's also limited and requires too much work. You need to always keep it in sync. If you add another hostname to server, you have to also add it to router. If you remove one, you have to remove it from router too. It doesn't work with numeric addresses. If fails when you can't force client to use your DNS server, and that's a problem with things like DoH (DNS over HTTPS). Hairpin NAT on the other hand is one-time thing. Once you add it, it works transparently with anything, numeric addresses, new hostnames, everything is automatic, you don't need to touch anything. I'm not saying that DNS method is bad, but it's more when you really know what you're doing.

You cannot use "Hairpin" if you are bald. ( )

There are two quick work-arounds to avoid the necessity to deal with Hairpin NAT and they include:
a. Move the LAN users OR Server to a different subnet, ALMOST ***** done!
b. Allow the LAN users to use the LAN IP of the server for access, done!

here is missing:

c. ADD another subnet just between router and server, without reconfig what already exist.


About the DNS method:
Your network, your rule, your DNS (MikroTik, bind, Microsoft, PiHole, etc. etc. etc. ) already must be used for all.
Provided by DHCP or set as static, the devices must use your own DNS.
No NAT necessary if you have control, simply drop all DNS query on raw not directed to your DNS server (not necessary must be the RouterOS DNS)
And all the idiots than try to use another server than what you want use, do not work and must have to revert back to your configurations.
Everytime is criticized like:

You need to always keep it in sync. If you add another hostname to server, you have to also add it to router. If you remove one, you have to remove it from router too.

But the "standard user" do not have those problems, and for the "true" network administrator, server have public IP and/or is always on another subnet and everytime no DNS or Hairpin required.

Jus one thing is sufficient make the DNS method superior for user than can not create own network without "Hairpin" or DNS:
The traffic do not go trought CPU / NAT / connection-tracking for work.
Obviously exceptions are already finded just for say something, like "for stay on you need the power source"...

Please, now don't go looking for idiotic exceptions like "I have to manage 1000 sites and DNS is not good as a method",
because it is clear that the problem is not using Hairpin / Subnet / DNS, but you just don't know how to do your own work if one arrives at certain needs.

(my) Conclusion (, my opinoin):
The DNS method, which still remains the best, the "Subnet" method and the "Hairpin" method,
are used only if there are shortages of resources or lack of freedom of configuration, or if you have programmed the network with your feet.
In normal use, none of these methods should be used.

There we go, @rextended back on track with bold writing, huge fonts, screaming for attention.
All those you call idiots contribute to your salary if you run a network, maybe not smart to call them idiots, bet they won't be happy of you hijacking dns requests. But hey, that's why DoH and other were invented, so bad admins like you can't screw with users anymore
Hairpin vs split horizon dns is a long lasting debate with pros and cons for each of them.
Everyone is free to use what he sees fit.
If I only have ONE service I need to access from inside and that's just some stats server (or some other low traffic thing), I'll use the damned hairpin, and no, it won't clog my firewalls connection tracking, even my smartband could handle that if it was running RouterOS.
Cheers.

There we go, @rextended back on track with bold writing, huge fonts, screaming for attention.

Bold writing? @Anav and @Sob posts are full of bold writing...
And also @Sob use huge fonts.
Strange that you have not noticed that, you were too busy trying to bother me.

Is clear that for you is only a way to try to troll...

All those you call idiots contribute to your salary if you run a network, maybe not smart to call them idiots, bet they won't be happy of you hijacking dns requests. But hey, that's why DoH and other were invented, so bad admins like you can't screw with users anymore

Your vision is limited as usual, you are confusing corporate networks with home user networks.
None of the "idiots" employees gives me the job, indeed, probably if the user does what he likes on the corporate network, he is fired and he is asked for damages.

At home he will do what he likes, but in the company he has to abide by the rules.

I'm sure corporate network admins will come here in the forum asking for advices from @anav or you, because they have no idea of how to do this already and don't have the knowledge to do it properly. Yeah... right.
These posts are all about and for home users, little guides that help the average Joe or Bob out there that didn't take any networking classes.
You are the confused one, sorry.
PS: the ones that DO write are the ones that run their own networks, and they can't get fired, since you know, they are the "big boss" they just have no idea about what they're doing.

Writing seriously, I've really seen them here...

...and before you give me a few more jokes, I'm not talking about myself...

Ohhh...
Znevna, sorry, I take myself too seriously, you are right to take the piss, I deserve it.

But who cares, I only took my wife home yesterday from the hospital, but who cares about anything else.

Jus one thing is sufficient make the DNS method superior for user than can not create own network without "Hairpin" or DNS:
The traffic do not go trought CPU / NAT / connection-tracking for work.

That's certainly interesting when there's going to be heavy traffic between client and server. Otherwise not so much.

...the "Subnet" method and the "Hairpin" method,
are used only if there are shortages of resources or lack of freedom of configuration, ...

Well, you just described the situation with IPv4. Basically, if there's any need for NAT, you're already in the land of compromises and hairpin NAT doesn't make it worse, but actually slighly more bearable.

Overall, you seem to be focusing on big networks with enough resources, dedicated admins, etc. That's not the main target group for hairpin NAT. But even there it could be useful, because of how simple and maintenance-free it is. You can go around, forcing people to use your DNS resolver, deal with support calls when they don't and something doesn't work for them, etc. And sure, if you already have other reasons for that, it's no extra work when you need it for this. But if you'd start that from scratch only for this, you may ask yourself, if it's really worth it. Setting up hairpin NAT will take five minutes of your work, with no futher extra attention required ever again, no support call caused by it, ... tell me it doesn't sound nice.

Well clearly I have botched this all up and need to do a rewrite, can you email me Sob, as its too difficult to attempt on this thread due to my lack of understanding of Italian and the extra noise created by Trollnevna!.

I'm sorry that you seem to like italian trolling more.
I like pizza and pasta too, but this doesn't justify we need to read his every angry argument against your work.
But whatever makes you happy!
Sob was trying to say that there's nothing wrong doing Hairpin NAT and it's even (under certain circumstances) easier to manage, less headaches, unless of course there's no high traffic involved that will overwhelm the router, but in most cases, that's not an issue.
Cheers!

Thanks Znevna, and all made some modifications so that the writeup is closer to the mark.
I will have to do some more amends as Sob has brought up other iterations or use cases to consider vice the mainstream ones.

You could mention what I wrote in my first reply here, in the DNS Method section.
The "DNS Method" will not work if a device in LAN uses DoH for example, bypassing the DNS hijacking done at the router level.
Or even an app running on that device, like: Chrome could work and Firefox not if Firefox has DoH enabled and Chrome doesn't. That'll give headaches to users

@anav: I see no problem in discussing things here, it won't be worse than many other threads. And it doesn't hurt to let others chime in too, even Italians, trolls (I'm not commenting about that or making any judgements ), or pretty much anyone else can possibly add something interesting or useful.

And I wouldn't say that you botched this all up. You started to overthink the part with another subnet, that wasn't necessary. All you need there is another subnet and proper dstnat, nothing else. The rest is correct, but if you look at it as beginner, I think it's a bit overwhelming. It should be possible to give it some more accessible structure, explain that it's actually quite simple. Because that should be the goal, to help people understand what they need to do, why and how, not just copy and paste some configs and keep thinking about strange magic.

@Znevna: Sob was trying to say (althought not very clearly here) that he in fact hates NAT. The damn thing is so utterly unnecessary in most cases. Primary reason for widespread NAT is lack of public addresses. Which is something that was solved more than a quarter of century ago(!) when they came up with IPv6, which for some strange reason is still not everywhere.

Just imagine how simple it could be. I want to run a server, so I just start service on any machine (which of course automatically has public address, even more if needed), optionally add one AAAA DNS record for it, and I'm done.

Now in best case, I just need to add another A DNS record for IPv4. That's if I have enough public IPv4 addresses, but often I don't. Then I have to play with NAT and forward ports from router to server. And then it doesn't work for people from LAN! Why not stop right there and say "enough!"? Why should I add another special config just for LAN users? Including dirty tricks like intercepting DNS traffic? I don't like it anymore! And that's exactly where hairpin NAT comes in, one last rule, and I don't need to worry about anything else. All further changes will be only what I'd need to do for public access anyway. Nothing more. As such, it's actually pretty nice.

And ok, I lied, sort of. While it's true that I do hate NAT, it's also great fun to play with it, because it allows to do all kinds of completely crazy and messed up things. But it's nice when I can use it, no so much when I have to.

Okay article revamped, please be gentle but comments welcome!!!

Different subnet scenario is now wrong in different way. Your in-interface-list=PFWD will break it, because it says nothing about destination address. It will catch connections to your server, but also connections to any other server. You'll realize your mistake very quickly, if you try that with some standard port like 80 or 443.

Remember, the only difference between different subnet and hairpin NAT is the lack or presence of the one srcnat (hairpin) rule. Everything about dstnat (static, dynamic, how to update it) is exactly same for both.

I still think that explanation about dst-address-type=local dst-address=!192.168.88.1 could be clearer. What you really want to match is public address, but since you don't know it, you match all router's addresses, except listed ones. So if you list router's all other non-WAN addresses, only the right one should be left (but don't forget that there could be also new dynamic addresses added for e.g. vpn clients). This is absolutely necessary only if you want to use same port also for service on router (e.g. WebFig), but it's probably better to do it anyway, just to avoid burning yourself later. You can also use shortcuts, e.g. if you know that you have several LAN subnets and they all use 192.168.X.0/24, you don't need to list 192.168.1.1, 192.168.2.1, 192.168.3.1, you can simply use dst-address=!192.168.0.0/16.

And one small detail about dhcp script, there's no schedule, it just happens right away when dhcp gets address.

One loosely related bonus tip:

Even if you have static address (but not as static to be guaranteed forever, because you may e.g. change ISP), you may be tempted to use shortcuts like in-interface=WAN (let's forget for a while that you can't use it anyway if you want hairpin NAT), simply because it will work even if the public address changes, and you won't have to update all your thousand dstnat rules with dst-address=1.2.3.4.

There's a better solution for that, subchains, where this condition is only in one rule:
Additionally, it will ease the router a little bit, because dstnat rules need to be checked for every single new connection, including outgoing ones from LAN to internet. So with many dstnat rules directly in dstnat chain, each connection to Google/Facebook/whatever needs to be checked against all those rules. If you use jump, then it's only one rule. Other rules in subchain will be checked only for connections to router's address.

@Sob welcome back

I'll 2nd the above, welcome back @sob

One loosely related bonus tip:

Even if you have static address (but not as static to be guaranteed forever, because you may e.g. change ISP), you may be tempted to use shortcuts like in-interface=WAN (let's forget for a while that you can't use it anyway if you want hairpin NAT), simply because it will work even if the public address changes, and you won't have to update all your thousand dstnat rules with dst-address=1.2.3.4.

There's a better solution for that, subchains, where this condition is only in one rule:

Code: Select all

/ip firewall nat
add chain=dstnat dst-address=1.2.3.4 action=jump jump-target=port-forward
add chain=port-forward protocol=tcp dst-port=443 action=dst-nat to-addresses=192.168.1.10
add chain=port-forward protocol=tcp dst-port=3389 action=dst-nat to-addresses=192.168.10.33
...
add chain=port-forward protocol=tcp dst-port=25 action=dst-nat to-addresses=192.168.20.13

Additionally, it will ease the router a little bit, because dstnat rules need to be checked for every single new connection, including outgoing ones from LAN to internet. So with many dstnat rules directly in dstnat chain, each connection to Google/Facebook/whatever needs to be checked against all those rules. If you use jump, then it's only one rule. Other rules in subchain will be checked only for connections to router's address.

So are you saying that if the destination address changes, then only one rule will be checked the first one and the rest will not be seen (no jump).
One still has to figure out that the address has changed I suppose but one only has to change one dst nat rule I guess is the other advantage.......

Yep, that's the idea.

Btw, your last edit, nice try with RFC1918 subnets, but it will break NAT 1:1 scenarios where such address can be also on WAN interface. And in-interface-list=PFWD still isn't doing anything useful.

If you got here, the lesson maybe you should try to avoid needing a hairpin NAT in the first place. Since that's not always possible, this reads like encyclopedia, not the "right way" guide.

I'll offer that my opinion that the DNS re-write and firewall rules to redirect DNS cannot be the "right way" – obviously workable in some/most cases, and part of a catalog of approaches – but that's not same thing as "right way".

Additionally, I'd skip, or relegate the DHCP WAN variant of (ii) /ip/cloud in address-list to a different section. Similar with the optimized jumps. Both are cleaver and useful beyond hairpin NAT, but seemingly gets a little off-topic. There all some kind of variant of how do I get a dynamic public IP, pick one and run with it, then go into the variants.

Thanks Sob,
Will attempt to satisfy your pernicious penchant for particularly pimply and prickly, pickyness ;-P

I do have a JUMP question for you.......
can that be used for different scenarios................
let say its this scenario, dynamic wanip,

add chain=dstnat action=dst-nat dst-address-type=local dst-address=!192.168.88.1 \
protocol=tcp dst-port=12566 to-addresses=192.168.88.68

But I have 10 such rules for different ports going to 192.168.88.68.
CAN I

/ip firewall nat
add chain=dstnat dst-address-type=local dst-address=!192.168.88.1 action=jump jump-target=port-forward
add chain=port-forward protocol=tcp dst-port=12556 action=dst-nat to-addresses=192.168.88.10
add chain=port-forward protocol=tcp dst-port=11233action=dst-nat to-addresses=192.168.88.10
...
add chain=port-forward protocol=tcp dst-port=4500 action=dst-nat to-addresses=192.168.88.10


AND I just now noticed that in your example even the server IP can change, is that also true here.........?
what about changing protocol ????

I'll offer that my opinion that the DNS re-write and firewall rules to redirect DNS cannot be the "right way" ...

I have no problem with local DNS. It's fine, aside from some extra maintenance required (adding new hostnames, etc; no matter how little, it's more than zero required for hairpin NAT). But for me it crosses the line when you need to forcefully redirect DNS queries to your resolver. That's a dirty trick. And it's not even reliable anyway, when DoH gets around it.

Additionally, I'd skip, or relegate the DHCP WAN variant of (ii) /ip/cloud in address-list to a different section. Similar with the optimized jumps.

Yeah, jumps were probably a "mistake". But otherwise, the funny thing about hairpin NAT is that any article about it is likely to be 90% about something else, because the main element of hairpin NAT is one simple srcnat rule, there's not much to discuss there. The "difficult" part is correct dstnat.

-

@anav: You can jump as much as you want. E.g. if you're going to have thousands of forwarded ports, you can have one jump for matched address, another jump to special chain for tcp ports, next for udp ports, even additional jumps to divide ports in different ranges, to optimize processing (= lower the average number of rules that have to be checked for new connection) even more. Just don't overdo it!(!!! ) It makes sense for performace reasons if there's going to be significant difference. Other than that, it can be useful to make the config more clear, even if it won't help with performance. But just because it can be a good thing, it doesn't have to be everywhere.

And as most other things, it's nothing complicated, the idea is simply to get rid of one repeating condition, which is moved to the rule with jump, then it can be exluded from rules of target chain. But nothing else changes, you're free to use any other conditions or actions there.

I didn't mean to sound negative – an encyclopedia isn't a bad thing.

But for me it crosses the line when you need to forcefully redirect DNS queries to your resolver. That's a dirty trick. And it's not even reliable anyway, when DoH gets around it.

In fact, I only commented because the force DNS redirect firewall rules – that where it "jump" the shark. I believe, DoH usage (AND other approaches to name resolution) is only going to increase and quickly going to be out of an network admin's control, so long term someone likely better off not going down the proverbial DNS "route".

Done and done for recommended amends

I'd use different wording here and there, but I don't want to be nitpicking too much and try to turn it into my guide instead of yours.

But just one thing, your added "more accurately the router knows its in the same subnet!!" may be true, but irrelevant. Router did forward packet to server, but server doesn't care about from where it came physically, it's sees client's IP address as source, so it sends response there, and router can't say anything about it, because it won't even see it.

Most comments now included!

This thread is an excellent resource. Many thanks all of you who have contributed.

I'd like to clarify something that was alluded to above, but isn't stated specifically. Since the simple srcnat rule causes all traffic to the server to look as if it came from the router, I assume all server access logs will show the router's address rather than the true client address. (Right?) That would be a downside, if so, and might push me into moving the server to a different subnet, or implementing the netmap rule mentioned by Sob.

(Disclaimer: I haven't yet tried enabling hairpin nat in any form.) very often

Not all traffic, only traffic from same LAN clients. And yes, the usual simple hairpin NAT rule hides original source addresses behind one. Which one, it's up to you, it can be router's internal address (default for masquerade), router's public address (with manual srcnat), or any other address you choose. You won't be able to tell these clients apart, but do you really need to? Hairpin NAT is handy shortcut to have publicly accessible services work also from LAN with no additional config, aside from the single srcnat (hairpin) rule. If there's remote LAN with thousand clients using one public address, you can't tell those apart either. And it's the same with client from your LAN.

Thanks for the confirmation.

Mark, thanks

@anav

a simple question from a simple, master-of-nothing, good-only-at-copy-and-paste-rules, miserable, 'en-passant' Mikrotik user

You wrote: "
The key addition to the NAT rules is the addition of a source-nat rule placed before the default src-nat rule (substitute with your server subnet).
add chain=srcnat action=masquerade dst-address=192.168.88.0/24 src-address=192.168.88.0/24
.....
When the client sends the outgoing request now two things happen, the first thing is as before the destination NAT rule will change the destination from that resolved to the WANIP 47.xx to that of the Server .68, and now additionally, the outgoing traffic also gets masqueraded gets 'natted' to the subnet gateway address. Therefore the traffic is now headed to the Server with source IP address of the gateway of the subnet (vice the client)...."

As far as I've understood, the NAT rule above says, "if any connection request comes from an IP in the LAN toward any device in the LAN itself then masquerade it with the gateway LAN IP ".
Got it right?
since the client requests for 47.123.12.89 only, it means that the router already "knows" that the public IP is "connected" with the server IP in the LAN somehow.
My question: from where the router gets this information in advance? From the destination rules before the NAT rule or what?
I am struggling to understand what exactly happens at this point inside the Mikrotik router and how it process it?
I hope that I make myself understood.

Thanks

Hi broderick, not sure I can add much to both the Sob statement or my addition immediately after the statement you are referring too.
Did you look at the link from Sowell and the diagrams??

Hi broderick, not sure I can add much to both the Sob statement or my addition immediately after the statement you are referring too.
Did you look at the link from Sowell and the diagrams??
His diagrams illustrate the before (without) and the after (with) the source nat rule in place!
https://gregsowell.com/?p=4242

Hi broderick, not sure I can add much to both the Sob statement or my addition immediately after the statement you are referring too.
Did you look at the link from Sowell and the diagrams??

You mean this one?
https://gregsowell.com/?p=4242

yes, I think it is clear what it does, but as I said, I am still confused about a very specific step/point of the process. I mean, there must be a "place" where the router gets the information from.
From the destination rule above it or in the router table?
It must know already that what the client wants (the server IP and establishing a connection with it) is in the LAN itself and the NAT rule above says nothing about it
I hope I was clearer now

Thanks.

The outgoing traffic is predicated on normal traffic rules....... and the destination nat rule takes the flow heading to the router and then directs it to the server, nothing special really.

The hard part for me is what happens when the traffic is being returned from the SERVER itself and what the router does with that data.
Here is where the Router is aware that the requestor on the LAN already exists and thus tries to send the reply directly back to the requestor.
However the requestor asked for the information to the WANIP, and thus when the reply does not come back from the WANIP, but from the server itself, the client requestor ignores the returning traffic.

With the sourcenat rule in place, the traffic is no longer coming from the single device IP, its coming from the subnet gateway IP........
In other words the traffic is not going back directly to the client anymore, its going to the router.......... the router says okay I have to un dst-nat that traffic from server IP to WANIP and un sourcenats the traffic from subnetgateway IP, to requestor IP. Hence the router sends the reply to the requestor and the requestor is expecting this traffic coming back from WANIP.

It's simple, you need to look at this diagram: https://wiki.mikrotik.com/wiki/Manual:P ... ng_Diagram

Main point is that the simplified order is dstnat -> routing decision -> srcnat. So first there's public address as destination, but before routing can see it, dstnat changes it to internal address, so routing already sees both source and destination being internal addresses, and so does srcnat later.

The hard part for me is what happens when the traffic is being returned from the SERVER itself and what the router does with that data.
Here is where the Router is aware that the requestor on the LAN already exists and thus tries to send the reply directly back to the requestor.
However the requestor asked for the information to the WANIP, and thus when the reply does not come back from the WANIP, but from the server itself, the client requestor ignores the returning traffic.

With the sourcenat rule in place, the traffic is no longer coming from the single device IP, its coming from the subnet gateway IP........
In other words the traffic is not going back directly to the client anymore, its going to the router.......... the router says okay I have to un dst-nat that traffic from server IP to WANIP and un sourcenats the traffic from subnetgateway IP, to requestor IP. Hence the router sends the reply to the requestor and the requestor is expecting this traffic coming back from WANIP.

It may sound strange to you but this is the "easier" part for me

The outgoing traffic is predicated on normal traffic rules....... and the destination nat rule takes the flow heading to the router and then directs it to the server, nothing special really.

this is the hardest one instead (related to the hairpin NAT, not for the destination rules in general)


ok
let's see if we can narrow down the area I'm interested in, and get to the precise point eventually.

Do we need the dst-nat rule necessary before the masquerade rule for the hairpin NAT to work correctly?

It's simple, you need to look at this diagram: https://wiki.mikrotik.com/wiki/Manual:P ... ng_Diagram

Sorry, I'm kind of an occasional mikrotik user, and that diagram barely makes sense to me

Main point is that the simplified order is dstnat -> routing decision -> srcnat. So first there's public address as destination, but before routing can see it, dstnat changes it to internal address, so routing already sees both source and destination being internal addresses, and so does srcnat later.

hmmmm, maybe we are getting to the right point here. More details about it please

Right now I'm leaving, but I have one quick tip, understand this diagram and you'll be king.

You can try if it's better with colors: viewtopic.php?p=768157#p768157

Right now I'm leaving, but I have one quick tip, understand this diagram and you'll be king.

then I'll be waiting for you.

You can try if it's better with colors: viewtopic.php?p=768157#p768157

ok at the very least, it means that I am going to have a coloured misunderstanding of it

Thanks

Think about it a little bit, it's not difficult. That's how router works, packets (every single one) are passing through different steps and various things are (can be) done to them:

• at first there's packet from 192.168.88.100:12345 (client and random source port) to 47.123.12.89:80 (public address and port);
  in that colored diagram it starts at "input interface" (bottom left)
• ignore hotspot for now
• next you'll see it in "/ip firewall raw chain=prerouting" and if you drop it there, it's the end
• next is conntrack, it's the magic part that makes it work, now (if it's first packet) it will make a note about new connection and its source and destination addresses
• next is "/ip firewall mangle chain=prerouting", nothing happens there in this example, but it can e.g. change routing
• then "/ip firewall nat chain=dstnat" where dstnat changes destination to 192.168.88.20:8080 (server); conntrack makes a note about that
• follows routing decision, which looks at current destination (192.168.88.20) and decides where to send it (to LAN)
• next is "/ip firewall mangle chain=forward"
• then "/ip firewall filter chain=forward" where you can allow or block it
• then "/ip firewall mangle chain=postrouting"
• then "ip firewall nat chain=srcnat" where source is changed to 192.168.88.1:23456 (router and possibly random port); conntrack takes a note
• follow few more steps that are not important right now
• packet now has source 192.168.88.1:23456 and destination 192.168.88.20:8080, and that's what server will see when it gets it

When server responds, it will send packet from 192.168.88.20:8080 to 192.168.88.1:23456, it will again come to router, and the whole process (almost) will happen again. The difference will be that conntrack will recognize it as part of existing connection. That's because it knows that it sent packet from 192.168.88.1:23456 to 192.168.88.1:23456, so it expects packets with swapped source and destination. As a result, it will skip srcnat and dstnat, because that can't be used in the middle of connection, only for first packet. It will also undo all changes done by srcnat and dstnat, so in the end will be packet from 47.123.12.89:80 to 192.168.88.100:12345, which will make client happy, because hooray, connection to server worked!

@sob
thanks for your explanation
much clearer now. it help me start cleaning the fog at least

you wrote:
....
* next is conntrack, it's the magic part that makes it work, now (if it's first packet) it will make a note about new connection and its source and destination addresses
...
then "/ip firewall nat chain=dstnat" where dstnat changes destination to 192.168.88.20:8080 (server); conntrack makes a note about that
.....
then "ip firewall nat chain=srcnat" where source is changed to 192.168.88.1:23456 (router and possibly random port); conntrack takes a note
..

It seems that conntrack comes into play three times at least, even though it is placed almost at the beginning of the prerouting chain in the diagram. A bit confusing to me, I admit

last thing last, I hope

about this NAt rule again:
add chain=srcnat action=masquerade dst-address=192.168.88.0/24 src-address=192.168.88.0/24

I almost always uses maquerade when it comes to translating Private IPs into Public ones and viceversa.
The rule above translate a private IP into another one. Ok, got it.
Is it correct to say that the rule as it is written above "automatically" triggers the translation of the client IP into the gateway's?
I mean I don't need "to-addresses=192.168.88.1" in the action tab, do I? Why?

Thanks

Well, position of connection tracking in diagram may be slightly confusing, it just shows where it starts.

Masquerade is special kind of srcnat that automatically chooses source address, the one which is on outgoing interface. So if there's really just one, there's no problem, but if for some reason there are more, it may not choose the one you want. Then you'd need action=src-nat and choose one yourself. Even if you have only one, you can still use action=src-nat to-addresses=192.168.88.1 (there's explanation somewhere why src-nat is actually better than masquerade, but I don't remember the link).

Other thing is that it doesn't have to be 192.168.88.1 (router's LAN address), it can be any address that makes the server send response to router. More about that here. Also mentioned there is src-address-type=!local, which is related to scenario when router for some reason has multiple addresses (e.g. 192.168.88.1/24, 192.168.88.2/24) and it should use selected one as source when communicating with some other device. It wouldn't work with simple srcnat rule that has only src/src-address=192.168.88.0/24, because it would apply also to router's own traffic. Adding src-address-type=!local fixes it.

Well, position of connection tracking in diagram may be slightly confusing, it just shows where it starts.

Masquerade is special kind of srcnat that automatically chooses source address, the one which is on outgoing interface. So if there's really just one, there's no problem, but if for some reason there are more, it may not choose the one you want. Then you'd need action=src-nat and choose one yourself. Even if you have only one, you can still use action=src-nat to-addresses=192.168.88.1 (there's explanation somewhere why src-nat is actually better than masquerade, but I don't remember the link).

ok. This is clear. Thanks

Other thing is that it doesn't have to be 192.168.88.1 (router's LAN address), it can be any address that makes the server send response to router. More about that here. Also mentioned there is src-address-type=!local, which is related to scenario when router for some reason has multiple addresses (e.g. 192.168.88.1/24, 192.168.88.2/24) and it should use selected one as source when communicating with some other device. It wouldn't work with simple srcnat rule that has only src/src-address=192.168.88.0/24, because it would apply also to router's own traffic. Adding src-address-type=!local fixes it.

Ok, we are probably getting close to the point.
I also read your post above you linked me, but I don't want to add a level of complexity at the moment.
Please bear with me. I want to go deeper into the 'masquerade' rule above only. My everyday NAT rule (not for the hairpin) is:

add action=masquerade chain=srcnat comment="defconf: masquerade" disabled=yes ipsec-policy=out,none out-interface=ether1

I used it on my Mikrotik just for "normal" nat to get access to the internet. Nothing special, but I thought that you always need to specify an IP or the out-interface at least.
as you can see I have specified the out-interface.

I have never overthought it since it works and it was just fine to me. But even though I'm not an expert,
I realized that you need to understand what is going on to do more complex things when needed.

your post above says, "But it's not the only way. Masquerade will use address from router's LAN interface (192.168.88.1)"
This statement maybe answers my question, that it, the masquerade NAT rule will use LAN IP (in this case) unless otherwise specified.
The dst-address=192.168.88.0/24 src-address=192.168.88.0/24 have to be on the same subnet which you want the IP (the gateway) be tranlated to as well??
I mean, is this information, consisting of the same subnet for dst and src address) that enables the router to NAT the original IP in the gateway's (192.168.88.1)?
I hope I was clear.

Thank you very much indeed

If you have out-interface=ether1, it's just one of possible conditions, it's not linked to masquerade choosing address from outgoing interface. Masquerade will always do that, even if the rule is just:
This would mean that any connection passing through router in any direction gets masqueraded. And because usually you don't want that, you can use various conditions (out-interface, src-address, dst-address, anything RouterOS allows) to limit when it happens.

If you have out-interface=ether1, it's just one of possible conditions, it's not linked to masquerade choosing address from outgoing interface. Masquerade will always do that, even if the rule is just:

Code: Select all

/ip firewall nat
add chain=srcnat action=masquerade

This would mean that any connection passing through router in any direction gets masqueraded. And because usually you don't want that, you can use various conditions (out-interface, src-address, dst-address, anything RouterOS allows) to limit when it happens.

So, any connection passing through router gets masqueraded with the router lan IP?

Thanks

No, with the one on outgoing interface. So for connections from LAN to internet it will be the one from WAN interface. For forwarded ports to internal servers it will be the one from LAN interface. And if you have more interfaces, then when something goes there, it will use address from that interface.

For forwarded ports to internal servers it will be the one from LAN interface.

Is this our case for the hairpin NAT then?

Thanks

The unconditional rule I posted covers everything, including hairpin NAT. But also traffic from internet forwarded to internal servers (dstnat), so you wouldn't want that. Also traffic between multiple LAN, which is in most cases also unwanted. That's why normally you use rules with conditions, to make them work only for selected stuff.

The unconditional rule I posted covers everything, including hairpin NAT. But also traffic from internet forwarded to internal servers (dstnat), so you wouldn't want that. Also traffic between multiple LAN, which is in most cases also unwanted. That's why normally you use rules with conditions, to make them work only for selected stuff.

Ok, I got this.
I know that I am having some difficulties grasping the process because of my lack of computer networking skills and knowledge.
I'm focusing on the reason why that rule translated to 192.168.88.1. Is it alway the case with any NAT rule (does it get the LAN IP first?)

I know that we use nat basically to translate a private IP from internal LAN into the router's public IP (even with a basic masquerade nat as the one you posted erlier):
the only one that routers on the internet can handle

Client LAN IP -> public WAN IP
and when it comes from outside
WAN public IP ->client LAN IP

Thus, my troubles to understand where the LAN IP comes from exactly. In which step it "pops up".
maybe a little, simple diagram would help.
Thanks

It's much broader, srcnat changes source addresses and/or ports, dstnat changes destination addresses and/or ports. And it can be anything to anything. Most common is private addresses to public address (to access internet), but you can do any other translation you can imagine. Some will make sense and do something useful, some won't. Instead of translating your internal private addresses to your public one, you can translate them to some other private address(es), some public address(es) you don't even have, anything. Router will be happy to do it for you. Only it won't do you any good, because you won't be able to connect to anything with resulting invalid source address.

As for masquerade, let's say you have simple router with few interfaces:

- WAN with public address 1.2.3.4
- LAN1 with 192.168.88.1/24
- LAN2 with 192.168.99.1/24
- VPN with 10.20.30.40/8

If packet goes out via WAN, masquerade will use 1.2.3.4 as source, for LAN1 it will be 192.168.88.1, for LAN2 192.168.99.1, for VPN 10.20.30.40. In short, whatever is on outgoing interface.

...
If packet goes out via WAN, masquerade will use 1.2.3.4 as source, for LAN1 it will be 192.168.88.1, for LAN2 192.168.99.1, for VPN 10.20.30.40. In short, whatever is on outgoing interface.

ok, so the packet gets 192.168.88.1 as source IP because it doesn't reach the WAN port, doesn't it?

According to the image at the link: https://gregsowell.com/?p=4242 STEP 5
the position of the rules matters. Right?

I think I got it now, my problem was (still is partially) visualizing correctly where the "magic" takes place and why. the reason why it gets IP 192.168.88.1, instead of the WAN's again.
Thanks

Imagine the router as room and its interfaces as doors leading to different destinations (other rooms, public street, another public street, your private yard, your garden, neighbour's yard, ... it's well connected room). There are some boots near each door. When going through door, you may want to put some boots on. That's srcnat. And it can be either action=src-nat to-addresses=x.x.x.x if you want to always wear your favourite boots, or action=masquerade when you just want to use whatever is near the door you're going through.

Position of rules generally matters, but in the linked example not necessarily for all. There are three srcnat rules:
The first one makes outgoing connections from server appear as from 1.1.1.2. It also works as hairpin NAT rule for server itself. If 192.168.1.10 tried to connect to 1.1.1.2, it would also get 1.1.1.2 as source. Other 192.168.1.x connecting to 1.1.1.2 would get 192.168.1.1 as source from second rule. If you'd swap these two rules, everything would still work, only server connecting to 1.1.1.2 would also get 192.168.1.1 as source. Last rule affects only traffic to internet (from anything other than 192.168.1.10, because 192.168.1.10 was already handled by first rule), because of out-interface=ether1. Those connections will probably get 1.1.1.1 as source, but because ether1 has also 1.1.1.2, not just 1.1.1.1 (even though it's not shown in image), it may be a bit unpredictable (lower number is probably preferred, but it's better to also use action=src-nat to-addresses=1.1.1.1 instead of masquerade).

...
Other 192.168.1.x connecting to 1.1.1.2 would get 192.168.1.1 as source from second rule. If you'd swap these two rules, everything would still work, only server connecting to 1.1.1.2 would also get 192.168.1.1 as source.
...

Thanks again @sob, I really appreciate your efforts to make me understand the entire NAT process, but this above is, more or less, the very step that I can't visualize exactly even though I've understood how hairpin NAT basically works. I mean where and when the destination address 1.1.1.2 (from the client 192.168.1.2 in the link) gets "grabbed and recognized" to be translated in 192.168.1.10 in order for the NAT rule add action=masquerade chain=srcnat disabled=no dst-addresses=192.168.1.0/24 src-addresses=192.168.1.0/24 to be triggered. From then it's quite clear.
Could it be that the "first magic" takes place here (the point I'm struggling with)?



If this is the case and I got it right this time, the DST-NAT rule, if any, gets triggered, otherwise (if the server is outside our own LAN) packets go through router gets Masquerade and reach internet via WAN.
Please, just bear with me last time. I won't bother you again on the same topic.
Thank you

First, you got wrong image, it's for bridge NAT, not the same as IP firewall NAT. Second, don't worry, I'd tell you if I decided to give up. But after the training I have with @anav, it's not imminent.

Packets change as they pass through router. Check again this older post, it describes what happens and when.

What you seem to be trying to find, but can't because it doesn't exist, is the link between srcnat and dstnat rules. There's logical link for you, because you need them to work together. Router doesn't see it this way, it has dstnat rule and completely independent srcnat rule, and if they happen to apply to same connection, then ok, why not. But that's all, for router it still doesn't make them related in any way.

And the part you quoted, it's about order of rules. If there's this dstnat rule:
And these srcnat rules (again, for router it's two independent things):
Then connection 192.168.1.10 -> 1.1.1.2 (server connecting to own public address) will first be turned into 192.168.1.10 -> 192.168.1.10 by dstnat. And when it gets to srcnat, rules will be checked one by one, until a first matching one is found and that will be used (or none will match and then srcnat won't do anything). In this case, first rule has only one condition, src-addresses=192.168.1.10, and it matches, so it changes packet to 1.1.1.2 -> 192.168.1.10 and server will see 1.1.1.2 as source. If you swap first two rules, then new first one (second in above code block) has two conditions, src-addresses=192.168.1.0/24 dst-addresses=192.168.1.0/24 and they also match, so it will be used. And because action is masquerade, it will take IP address from outgoing interface, which is LAN, because destination is 192.168.1.10 and it's connected there. So in this case server will see 192.168.1.1 as source.

What is imminent is continued dialogue. Its clear that Sob answers questions in a such an obscure way its sure to invite further questions and thus he gets to hear himself type; And I thought I was the narcissist. I actually learn more about networking from his posts then any book, the trick is to act so dumb (or just be yourself) that he finally breaks down and answers the questions in English and not IT speak. I can feel the luv!!

First, you got wrong image, it's for bridge NAT, not the same as IP firewall NAT. Second, don't worry, I'd tell you if I decided to give up. But after the training I have with @anav, it's not imminent.

Maybe this is hopefully the right one on the same diagram:

[/URL

Packets change as they pass through router. Check again [url]https://forum.mikrotik.com/viewtopic.php?p=921836#p921836 it describes what happens and when.

I think I can understand this your previous post now, because of this step in particular:
then "/ip firewall nat chain=dstnat" where dstnat changes destination to 192.168.88.20:8080 (server); conntrack makes a note about that


BUT, strangely enough

Then connection 192.168.1.10 -> 1.1.1.2 (server connecting to own public address) will first be turned into 192.168.1.10 -> 192.168.1.10 by dstnat. And when it gets to srcnat, rules will be checked one by one, until a first matching one is found and that will be used (or none will match and then srcnat won't do anything). In this case, first rule has only one condition, src-addresses=192.168.1.10, and it matches, so it changes packet to 1.1.1.2 -> 192.168.1.10 and server will see 1.1.1.2 as source. If you swap first two rules, then new first one (second in above code block) has two conditions, src-addresses=192.168.1.0/24 dst-addresses=192.168.1.0/24 and they also match, so it will be used.

This made me take, say, a step back. First, why should the server do this? In which occasions?
Why do we need add action=src-nat chain=srcnat disabled=no src-addresses=192.168.1.10 to-addresses=1.1.1.2 since the server replies to the LAN IP already because of the next NAT rule?
add action=masquerade chain=srcnat disabled=no dst-addresses=192.168.1.0/24 src-addresses=192.168.1.0/24

Weren't we considering only the client perspective? I mean, the client trying to reach the server on the other side of the LAN and the hairpin NAT making the server send the packet to the router first?
There wasn't such a rule in the old Mikrotik wiki page about hairpin NAT (I saved this webpage on local)

Thanks

What is imminent is continued dialogue. Its clear that Sob answers questions in a such an obscure way its sure to invite further questions and thus he gets to hear himself type; And I thought I was the narcissist. I actually learn more about networking from his posts then any book, the trick is to act so dumb (or just be yourself) that he finally breaks down and answers the questions in English and not IT speak. I can feel the luv!!

Ok I'll be just myself then; it will save me any effort too

by the way, thanks for the training @sob had to go through because of you. It turned out to be useful and profitable for me too

Thanks

I'm talking about the example you linked to. It uses two public addresses, only it forgot to specifically mention and show in images that they are both on router's WAN interface. Server has 1.1.1.2 for itself and other LAN devices use 1.1.1.1 when going to internet. And server has 1.1.1.2 not only for incoming connections, but also for outgoing ones. So when server is connecting to something in internet, target device will see 1.1.1.2 as source, but if another device from LAN connects there, 1.1.1.1 will be used as source.

Why would the server connect to itself isn't really important. It may not be aware that 1.1.1.2 is its own address. It knows for sure that it has 192.168.1.10, because it's assigned to its interface, but 1.1.1.2 is somewhere else. So if it hosts e.g. webserver for www.example.tld, it resolves to 1.1.1.2, and something on same server tries to connect to www.example.tld, it will be connecting to same machine without even knowing about that.

But it makes nice example. You can't think only about what you want it to do, but also about what you don't want it to do (some unwanted bonus as e.g. the unconditional masquerade would give you). Try this:

/ip firewall nat
add chain=srcnat src-addresses=192.168.1.10 action=src-nat to-addresses=1.1.1.2
add chain=srcnat dst-addresses=192.168.1.0/24 src-addresses=192.168.1.0/24 action=masquerade
add chain=srcnat out-interface=ether1 action=masquerade

Legend: condition, action

And now you can imagine different scenarios and think about what will happen:

1) 192.168.1.5 connects to external 5.5.5.5, which rule will match? #1 no, #2 no, #3 yes => source will be changed to 1.1.1.1
2) 192.168.1.10 connects to external 5.5.5.5: #1 yes, #2 no, #3 yes (because #1 matches, #2 and #3 won't be actually checked) => source will be changed to 1.1.1.2
3) external 3.3.3.3 connects to 1.1.1.2, so dstnat will send it to 192.168.1.10: #1 no, #2 no, #3 no => source won't be changed
4) 192.168.1.5 connects to 1.1.1.2, dstnat will send it to 192.168.1.10: #1 no, #2 yes, #3 no => source will be changed to 192.168.1.1
5) 192.168.1.10 connects to 1.1.1.2, dstnat will send it to 192.168.1.10: #1 yes, #2 yes, #3 no => source will be changed to 1.1.1.2

To expand the unwanted bonuses a bit, this one is obvious:

/ip firewall nat
add chain=srcnat action=masquerade

There's no condition, anything will match. Or something perhaps a bit less obvious, an attempt to optimize hairpin NAT:

/ip firewall address-list
add list=LANs address=192.168.1.0/24
add list=LANs address=192.168.2.0/24
add list=LANs address=192.168.3.0/24
/ip firewall nat
add chain=srcnat src-address-list=LANs dst-address-list=LANs action=masquerade

There are servers in all three LANs and why add separate rules for each, if one can do it, right? Except, what if 192.168.1.5 wants to connect directly to 192.168.3.10? Is the source in LANs list? Yes. Is destination in LANs list? Yes. So the rule matches and source will be changed to 192.168.3.1, even though you probably don't want that.

.....

/ip firewall nat
add chain=srcnat src-addresses=192.168.1.10 action=src-nat to-addresses=1.1.1.2
add chain=srcnat dst-addresses=192.168.1.0/24 src-addresses=192.168.1.0/24 action=masquerade
add chain=srcnat out-interface=ether1 action=masquerade

Legend: condition, action

And now you can imagine different scenarios and think about what will happen:

1) 192.168.1.5 connects to external 5.5.5.5, which rule will match? #1 no, #2 no, #3 yes => source will be changed to 1.1.1.1
2) 192.168.1.10 connects to external 5.5.5.5: #1 yes, #2 no, #3 yes (because #1 matches, #2 and #3 won't be actually checked) => source will be changed to 1.1.1.2
3) external 3.3.3.3 connects to 1.1.1.2, so dstnat will send it to 192.168.1.10: #1 no, #2 no, #3 no => source won't be changed
4) 192.168.1.5 connects to 1.1.1.2, dstnat will send it to 192.168.1.10: #1 no, #2 yes, #3 no => source will be changed to 192.168.1.1
5) 192.168.1.10 connects to 1.1.1.2, dstnat will send it to 192.168.1.10: #1 yes, #2 yes, #3 no => source will be changed to 1.1.1.2

Everything is clear now!!

To summarize, what I kept missing was basically the DST-NAT rule first, then where it takes place.
Apart from knowing what hairpin NAT is about and how it works, I think I have now a slightly better understanding of networking and RoutersOS
So, Anav was right when he wrote, "I actually learn more about networking from his posts than any book."

Thank you very much indeed.

Perhaps I should write a book? If only I wasn't lazy...

Perhaps I should write a book? If only I wasn't lazy...

Why not?

To expand the unwanted bonuses a bit, this one is obvious:

/ip firewall nat
add chain=srcnat action=masquerade

There's no condition, anything will match. Or something perhaps a bit less obvious, an attempt to optimize hairpin NAT:

Sorry, I read this post now. Maybe it is due to the fact that I am probably still sleeping, but I was wondering if the masquerade NAT rule above have no condition like
out-interface=ether1, how does it know which traffic it has to NAT (in particular the one which is going to internet)?? Does it masquerade anything going through routing decision and/or between different subnets?
Thanks

Why it's not likely to ever see a book written by me, simple explanation, laziness, procrastination, I'm not exactly sure, but it's something like that. Add some level of perfectionism and it's deadly combination, mission impossible.

The rule with no conditions is exactly that, no conditions => happens every time. It's like "if you do something for me, I'll give you million dollars" / "I'll give you million dollars". The latter has no conditions, so good new for you. Well, would be, if it wasn't just example. So yes, anything passing through router will be masqueraded. You most likely don't want that.

Why it's not likely to ever see a book written by me, simple explanation, laziness, procrastination, I'm not exactly sure, but it's something like that. Add some level of perfectionism and it's deadly combination, mission impossible.

The rule with no conditions is exactly that, no conditions => happens every time. It's like "if you do something for me, I'll give you million dollars" / "I'll give you million dollars". The latter has no conditions, so good new for you. Well, would be, if it wasn't just example. So yes, anything passing through router will be masqueraded. You most likely don't want that.

got it!
Thanks again

one tidbit I found ref preferred source
.......

Also from same page:

Connected routes represent the network on which hosts can be directly reached (direct attachment to Layer2 broadcast domain). These routes are created automatically for each IP network that has at least one enabled interface attached to it (as specified in the /ip address or /ipv6 address configuration).

For manual routes it still works.

After dealing with something that @Sob captured here, but a little different: viewtopic.php?t=179343#p922929
(when dealing with multiple local subnets and you probably don't want to masquerade all the inter-local-subnets traffic that your router .. routes, and you don't want rules that give headaches.)
I've found this: viewtopic.php?t=172380
But still something was missing, and of course instead of improving that method of doing hairpinning, some of the usual suspects started trashing the topic and.. that was it.
How can we improve the connection mark method of doing hairpinning? As it wasn't mentioned in here, it seems, and I won't cover the dst nat part of it, plenty of examples around here of how to do it.
So, why don't we mark only the connections that we need?
Let's say we have this address list containing our local subnets: We setup our dstnats the way we like and that was covered already in these topics.
We mark only our dstnatted connections that originated from inside our network: (connections with connection-nat-state=dstnat are first seen in the forward chain it seems, you can check).
We masquerade those marked connections: And if we're using fasttrack we want to exclude marked connections from being fasttracked, as fasttrack strips the marks and nothing that we did here will work:
I like doing it this way.
Cheers!
LE: fixed 2nd link.
LE2: removed redundant check from the mangle rule, as pointed below by @Sob: connection-mark="!NAT Hairpin"

Hi Msatter, what is the practical application? The only reason to use hairpin nat for servers is when the USERS are on the same subnet. If not a different subnet its not an issue (as long as one doesnt make a firewall forward chain associated rule that includes -in-interface-list=LAN.
In other words, I see what you are doing but not the why do it..............

Right no the simple source nat hairpin nat rule works, I am interested in why we have to go to the more complex marking traffic approach??

Hi Msatter

Weird, what did @msatter write in here and I've missed? Otherwise, check your glasses prescription.
And regarding your questions: for me, marking only the needed connections and masquerading only those seems simpler and easier to manage.
Your hard to follow guide above doesn't cover a working example of multiple services dstnatted to multiple subnets with proper hairpinning.
Feel free to add an example.

@Znevna: Few things:

- The connection-mark="!NAT Hairpin" seems useless, if this rule is the only one that can set "NAT Hairpin" mark and it's limited to first packet using connection-state=new.
- It can have false positives. Original had dst-address-list=WANs (with WANs list containing public addresses), so it only marked traffic going to them. This could also mark other traffic, if you'd be doing some dstnat between LANs (not common, but possible).
- This goes also for original, connection marks is rare resource, you have only one per connection. If you use them for other purposes, there may be conflicts and extra care required to avoid them.

It's not bad and can have some uses. For example when there's VPN with overlapping subnets (see description in this thread) and the usual hairpin rule takes even traffic that it shouldn't. But otherwise I'd probably stick with the usual, it's simple and foolproof. And unless you have some extreme number of subnets, adding rule for each shouldn't be a problem.

I'm still playing with this method, I'm sure there are improvements that can be made and cases where the other methods fit better, cases where you can't mark those connections, like you've said.
It's just an alternative worth mentioning.
LE: Regarding the false positives, depends on you configure the dstnat rules, no? you can either make sure those don't catch unnecessary traffic or you adjust the marking rule, but I think one should start with proper dstnat rules.

I'm not sure how much it can be improved, but keep playing. The original was already pretty good. It marked all connections to router's public address(es) even when there was no dstnat, but there shouldn't be any problem with that. Downside was the need to keep updated list of addresses. It's doable, but can be a bit annoying.

I tend to keep the annoying parts out, that's why I wanted to try the matching by connection-nat-state. ^^

My bad, I meant the other annoying guy LOL.

Concur with Sob, I think the overlapping VPNs has more of a practical bent to it, but how the heck would that happen?
One usually sets a VPN address on the router so why set one that is the same as subnet on the router?
Or do you mean you may have a subnet of remote users exiting a tunnel at the router with IPs already existing with local users............. not clear what you are referring too.

As for the example, yes, I suppose we had three subnets,
Subnet A, Server A
Subnet B, Server B,
Subnet C, No Server'
WAN1 - static fixed
WAN2 - dynamic

Where users on A,B,C are going to be accessing both servers.
Where external users should be able to come in on either WAN

Is that close to what you mean?
Sob, how would I work in a VPN angle ?

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

About false positives, let's say I have clients 192.168.88.x directly accessing server 192.168.99.100, which I need to move to different address, either within same subnet (192.168.99.200) or different one (192.168.100.100), but e.g. because I need some time to reconfigure all clients, I'd do:
to make the old address work too. Your rule would match and connection would be masqueraded. This dstnat rule is not wrong, it's fully intentional. So this traffic would have to be excluded from your rule. Again, this won't happen often, but it's good to remember that something like this is possible.

@anav: See this (and notice that I did mention you ).

The alternative to connection marking above would be to have a masquerade line for each subnet, right?
Config exports from different devices would have too many differences, I like my configs as simple and as similar as they can be, they're easier to manage that way.
Probably that's the only reason for me.
@Sob, in that case, yes, the mangle rule would have to be adjusted.

Here I am again.
Would the Harpin Nat rules above work with double NAT?

Thanks

It's long thread with many rules. But it's simple, if you have double NAT and you control the last router, you can either let the upstream router handle hairpin NAT and not worry about anything if it does, or you can intercept traffic to public address on your router. Which makes things work in case upstream router doesn't do it, or at least optimizes it a bit, because traffic doesn't unnecessarily go to upstream router and back. If you want it simple without duplicating rules, create address list:
And then use dst-address-list=dstnat-ips in dstnat rules.

It's long thread with many rules. But it's simple, if you have double NAT and you control the last router, you can either let the upstream router handle hairpin NAT and not worry about anything if it does, or you can intercept traffic to public address on your router. Which makes things work in case upstream router doesn't do it, or at least optimizes it a bit, because traffic doesn't unnecessarily go to upstream router and back. If you want it simple without duplicating rules, create address list:

Code: Select all

/ip firewall address-list
add list=dstnat-ips address=<private IP address on router's WAN>
add list=dstnat-ips address=<DDNS hostname pointing to public address>

And then use dst-address-list=dstnat-ips in dstnat rules.

Hi,
I am not sure if I got it right. What do you mean with "last" and "upstream" router exactly?
Anyway, thank to you and @Anav I think that I've understood what Hairpin NAT is for and
how it works overall, but I would probably have some problems at setting it up properly, mostly because of the DYNAMIC WAN IP scenario.

Here is my situation...more or less:



My Mikrotik router is behind the ISP router which gets a Public WAN IP dinamically. The ISP's LAN subnet is 192.168.1.0/24, and MY Mikrotik device gets 192.168.1.11
as an IP address, which it is also its WAN IP. I can open port 443 and 80 in the ISP router.
Since I have a dynamic public IP, I set a DDNS service which runs on my server. So, if users from Internet want to reach the nextcloud and the wordpress services running on my server
they can do it by typing nextcloud.riknetwork.org or wordpress.riknetwork.org via port 443 I opened in the ISP router, then my Mikrotik router forward the requests to my server
via a simple dst nat rule: On my server also runs Nginx PM which manages these services and SSL certificates for them as well, and it redirects any requests coming from port 443 to the internal docker network when the
services actually run which their own internal IP. Everything works flawlessly when users need to access services via the DOMAIN name from the WAN public IP.

I added two DNS static entries in my Mikrotik router so that I also can acces the two services from my LAN via the DNS method unless DoH is set in the browser.
As I said, everything works well and I am happy with that since I have no particular needs.
However, I'd like to figure out what should I do and how to set it up properly if I want to use Hairpin NAT in my HOME LAB in place of the DNS method, not because I
need it, but because I think it would help me get a better understanding of how a mikrotik device works and about computer networking in general.
Thank you.

"last" = Mikrotik Router
"upstream" = ISP ROUTER

You're almost done already, dstnat rules need to catch packets to 192.168.1.11 (for access from internet; you already have that) and to <whatever your DDNS hostname resolves to> (for access from LAN; this needs to be added). And that's it, then you can remove static DNS records (*) and it will still work without them (if you have the srcnat rule for connections from and to LAN subnet 192.168.2.0/24).

(*) Can, but don't have to. You can have both them and hairpin NAT at the same time. If something uses your router as resolver, it will get internal address and use shorter path to destination (packets won't have to go to router and back). And if something bypasses router and gets address from elsewhere (which will be the public one), hairpin NAT will take care of that.

On the other hand, unless there's some heavy traffic from LAN that would benefit from going to server directly, you can keep only hairpin NAT, because it will transparently work for everything. That can help if in future you decide to move some sites elsewhere, then you won't have to remember to remove local static records pointing to old server.

Although, static records have an advantage that they are not influenced by changing public address. Address list with DDNS hostname will always lag behind changes, depending on TTL, but probably at least few seconds. So for this short while, connections from LAN wouldn't work if you'd have only hairpin NAT. We're now talking about details, but if you want to know everything...

"last" = Mikrotik Router
"upstream" = ISP ROUTER

You're almost done already, dstnat rules need to catch packets to 192.168.1.11 (for access from internet; you already have that) and to <whatever your DDNS hostname resolves to> (for access from LAN; this needs to be added). And that's it, then you can remove static DNS records (*) and it will still work without them (if you have the srcnat rule for connections from and to LAN subnet 192.168.2.0/24).

(*) Can, but don't have to. You can have both them and hairpin NAT at the same time. If something uses your router as resolver, it will get internal address and use shorter path to destination (packets won't have to go to router and back). And if something bypasses router and gets address from elsewhere (which will be the public one), hairpin NAT will take care of that.

On the other hand, unless there's some heavy traffic from LAN that would benefit from going to server directly, you can keep only hairpin NAT, because it will transparently work for everything. That can help if in future you decide to move some sites elsewhere, then you won't have to remember to remove local static records pointing to old server.

Although, static records have an advantage that they are not influenced by changing public address. Address list with DDNS hostname will always lag behind changes, depending on TTL, but probably at least few seconds. So for this short while, connections from LAN wouldn't work if you'd have only hairpin NAT. We're now talking about details, but if you want to know everything...

ok.
if I got it right I should add this srcnat rule at the top of my NAT rules:
then I should create this address-list:
finally, I need to modify the dst-nat rule this way:
I also disabled the static dns entries.

Is that correct?

Thanks

Almost. In previous post you have mix of 192.168.1.10 and 192.168.1.11, so choose the right one. And if both hostnames resolve to same address, it's enough to have only one in list.

Almost. In previous post you have mix of 192.168.1.10 and 192.168.1.11, so choose the right one.

Yes, It was a typo.

And if both hostnames resolve to same address, it's enough to have only one in list.

Exactly! I too noticed that I don't need more than one domain in the address-list. The first one gets the Public IP, and it is enough to make the second one work as well.

AND

.....Drum roll......

IT WORKS!!

OMG. I didn't imagine that I would be able to make it work until a few months ago, when I barely knew what hairpin NAt was for.
As someone has already said in this forum, I probably have learned much more thanks to this thread than reading an entire book on Mikrotik or computer network.
Thank you very much indeed!!

ps: Could I change this srcnat rule: to this one
just to make it affect only the requests to the server?

You can, but unless you have some less usual other config, it won't be improvement of any kind. Because normally there won't be any other traffic from 192.168.2.x to 192.168.2.y anyway. Except perhaps something initiated by router itself, and that can be excluded using src-address-type=!local. If you keep whole subnet as both src and dst, it will cover all future forwarded ports and you won't need to think about it.

edit: If you do replace it, correct destination would be 192.168.2.18/32.

You can, but unless you have some less usual other config, it won't be improvement of any kind. Because normally there won't be any other traffic from 192.168.2.x to 192.168.2.y anyway. Except perhaps something initiated by router itself, and that can be excluded using src-address-type=!local. If you keep whole subnet as both src and dst, it will cover all future forwarded ports and you won't need to think about it.

I was wondering if it can affect traffic toward my pihole which runs on a different device but on the same subnet 192.168.2.0/24

Thanks

Depends on exact config, but probably not. You can't have routed traffic from 192.168.2.x to 192.168.2.y without srcnat, that wouldn't work. And if it's switched/bridged traffic, then IP firewall doesn't touch it.

Depends on exact config, but probably not. You can't have routed traffic from 192.168.2.x to 192.168.2.y without srcnat, that wouldn't work. And if it's switched/bridged traffic, then IP firewall doesn't touch it.

I added the dst NAT rule below to force any dns request coming from my LAN to go through my pi-hole at IP 192.168.2.16
The only drawback of this NAT rule is that any request seem to come from the router itself, so in the pihole-dashboard you can't see which device exactly in the LAN makes the dns query.
Maybe the new dst rule I made for the hairpin issue makes this old one unnecessary, doesn't it?
Thanks

Don't mix dstnat and srcnat. If you want to redirect DNS requests from clients to pi-hole, you must keep this dstnat rule, because that's what does it. But it was able to previously work only because of some other srcnat rule that did the same as newly added srcnat rule (src/dst-address=192.168.2.0/24 action=masquerade). So one of these srcnat rules may be unnecessary (depends on what all conditions the old one has).

And yes, pi-hole seeing router's address is expected. It's the side effect of hairpin NAT. It can't keep real address of client (*). It's not ideal, but it's either this or not working at all. See description of problem in first post, section 1.

(*) Not completely true, it can be done, but not by router itself, pi-hole would have to do some work. It could watch source MAC address and if it's router's MAC address, it would know that it must send responses back to router and not directly to client.

In conclusion, nothing needs to be added to the main page of the article?
As for pihole what for ? Ads........

https://avoidthehack.com/best-dns-privacy

Don't mix dstnat and srcnat. If you want to redirect DNS requests from clients to pi-hole, you must keep this dstnat rule, because that's what does it. But it was able to previously work only because of some other srcnat rule that did the same as newly added srcnat rule (src/dst-address=192.168.2.0/24 action=masquerade). So one of these srcnat rules may be unnecessary (depends on what all conditions the old one has).

Apart from the Hairpin src-nat rule I added yesterday, the only one I had was:
I also used to have these src-nat rules a couple of years ago to redirect dns queries to pihole running as a container on my Proxmox machine:

plus, of course, the dst-nat as well.

But I disabled them because they didn't seem to affect the redirection of the dns queries to pihole. I meant, the dst-nat rule was enough. I might be wrong here though.

...
(*) Not completely true, it can be done, but not by router itself, pi-hole would have to do some work. It could watch source MAC address and if it's router's MAC address, it would know that it must send responses back to router and not directly to client.

Not sure if I've understood this.

Thanks

Something is missing. If you have pi-hole with 192.168.2.16/24, client with 192.168.2.x/24, which thinks that it's connecting to e.g. 1.1.1.1 but router redirects it to 192.168.2.16, it can't work without some srcnat. The one with out-interface-list=WAN can't help unless you have LAN interface (where 192.168.2.0/24 is) in WAN list. It's exactly the problem that hairpin NAT solves:

- client 192.168.2.x sends packet to 1.1.1.1
- router changes destination to 192.168.2.16
- pi-hole sees source 192.168.2.x, i.e. same local subnet, so it sends response directly to client
- client throws it away, because it doesn't expect anything from 192.168.2.16

But if there's srcnat, then source gets changed to 192.168.2.1 (router) and pi-hole sends response there.

About the "hairpin without srcnat", if target server run RouterOS, you could do:
So connections from LAN subnet that came indirectly via router will get marked, and then responses will be sent to router, instead of directly to clients.

...
- client 192.168.2.x sends packet to 1.1.1.1
- router changes destination to 192.168.2.16
- pi-hole sees source 192.168.2.x, i.e. same local subnet, so it sends response directly to client
- client throws it away, because it doesn't expect anything from 192.168.2.16
But if there's srcnat, then source gets changed to 192.168.2.1 (router) and pi-hole sends response there.

ok. But it seems to be working nonetheless. As far as I know, I noticed no issue with dns.
Anyway, the srcnat rule I set for the Hairpin NAT and placed at the top of the firewall nat rule list :
should be also useful for the DNS issue. Correct?

About the "hairpin without srcnat", if target server run RouterOS, you could do:

Code: Select all

/ip route
add dst-address=192.168.2.0/24 gateway=192.168.2.1 routing-table=via_router
/ip firewall mangle
add chain=prerouting src-address=192.168.2.0/24 src-mac-address=<router's MAC address> action=mark-connection new-connection-mark=lan_via_router
add chain=output connection-mark=lan_via_router action=mark-routing new-routing-mark=via_router

So connections from LAN subnet that came indirectly via router will get marked, and then responses will be sent to router, instead of directly to clients.

I haven't yet started learning mangle unfortunately, so it is an advanced topic for me. Basically, I avoid to use rules and setup I don't understand, the most part at least.

Thanks

Hi WOPR, correct, the sourcenat rule will also help the clients on the same subnet utilize the pi-hole successfully.
Recently updated here - Para 8. - viewtopic.php?t=179343

Hi WOPR, correct, the sourcenat rule will also help the clients on the same subnet utilize the pi-hole successfully.
Recently updated here - Para 8. - viewtopic.php?t=179343

Ok, thanks

By the way, is your last edit to the topic exactly about - Para 8.?
- viewtopic.php?t=179343

Always tweaking text so probably.