Community discussions

MikroTik App
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Port Forwarding Not Working, Hairpin NAT & More!!

Tue Oct 12, 2021 1:37 am

Port Forwarding can fail and some of the common solutions are discussed.........
This article is meant to discuss the often tripped over Hairpin NAT scenario and the extra work required to deal with a dynamic WANIP in conjunction with destination NAT.

Unable to access your server via the DOMAIN name from the LAN???
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. 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.
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 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 as the source 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.

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 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. Using in-interface list=WAN, quite clearly excludes LAN users from the equation as they are NOT coming from the WAN interface. Therefore the following iterations attempt to identify the current WANIP interface to mimic the fixed/static IP addressing which works as its not dependent upon an incoming interface-list (aka the common factor being traffic heading towards the relevant destination -for both incoming external users and internal LAN users)

(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)

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!
/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
Last edited by anav on Tue Nov 30, 2021 4:37 pm, edited 75 times in total.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 3:22 am

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:
/ip firewall nat
add chain=srcnat dst-address=192.168.88.0/24 src-address=192.168.88.0/24 action=masquerade
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):
/ip firewall nat
add chain=srcnat dst-address=192.168.88.0/24 src-address=192.168.88.0/24 action=src-nat to-addresses=47.123.12.89
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):
/ip firewall nat
add chain=srcnat dst-address=192.168.88.0/24 src-address=192.168.88.0/24 action=netmap to-addresses=192.168.99.0/24
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:
/ip firewall nat
add chain=dstnat <destination> protocol=tcp dst-port=12566 action=dst-nat to-addresses=192.168.88.68
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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5987
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 10:20 am

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

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.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5987
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 10:25 am


@Sob welcome back, @Anav it made me worry for you that you were gone, they thought the worst, given the period ...
 
User avatar
Znevna
Member
Member
Posts: 430
Joined: Mon Sep 23, 2019 1:04 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 10:50 am

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.
MTKEK Certified
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5987
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 11:02 am

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.
 
User avatar
Znevna
Member
Member
Posts: 430
Joined: Mon Sep 23, 2019 1:04 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 11:13 am

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.
Last edited by Znevna on Sat Nov 20, 2021 11:17 am, edited 2 times in total.
MTKEK Certified
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 5987
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 11:15 am

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.
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 5:45 pm

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. :)
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 9:37 pm

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'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
User avatar
Znevna
Member
Member
Posts: 430
Joined: Mon Sep 23, 2019 1:04 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 9:43 pm

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!
MTKEK Certified
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 10:34 pm

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.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
User avatar
Znevna
Member
Member
Posts: 430
Joined: Mon Sep 23, 2019 1:04 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 10:42 pm

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 :)
MTKEK Certified
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 11:10 pm

@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. :twisted: But it's nice when I can use it, no so much when I have to.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sat Nov 20, 2021 11:40 pm

Okay article revamped, please be gentle but comments welcome!!!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sun Nov 21, 2021 12:24 am

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sun Nov 21, 2021 12:46 am

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:
/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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 2075
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Krugersdorp (Home town of Brad Binder)
Contact:

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Sun Nov 21, 2021 4:08 pm


@Sob welcome back
I'll 2nd the above, welcome back @sob
MTCNA, MTCTCE, MTCRE & MTCINE
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Mon Nov 22, 2021 1:19 am

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:
/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.......
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Mon Nov 22, 2021 4:16 am

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
Amm0
Member Candidate
Member Candidate
Posts: 232
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Mon Nov 22, 2021 7:26 am

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.
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - Some of the Ways To Achieve O......

Mon Nov 22, 2021 5:11 pm

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'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Mon Nov 22, 2021 8:28 pm

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
Amm0
Member Candidate
Member Candidate
Posts: 232
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: SEXY Hairpin NAT - The Right Way To Achieve O......

Mon Nov 22, 2021 9:07 pm

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".
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - Some of the Ways To Achieve O......

Wed Nov 24, 2021 4:29 pm

Done and done for recommended amends
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
 
Sob
Forum Guru
Forum Guru
Posts: 6595
Joined: Mon Apr 20, 2009 9:11 pm

Re: SEXY Hairpin NAT - Some of the Ways To Achieve O......

Thu Nov 25, 2021 2:00 am

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 9149
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: SEXY Hairpin NAT - Some of the Ways To Achieve O......

Thu Nov 25, 2021 5:43 pm

Most comments now included!
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!

Who is online

Users browsing this forum: No registered users and 1 guest