It breaks all kinds of fundamental standards and norms, not to mention statistics, security, things like fasttrack, etc. It makes transitions away from your current configuration more difficult. It's impossible for future people to interpret, as it shouldn't be done and without adequate explanation can often require a confusing mess of other work, especially if you've got any queues or packet mangling.

Imagine wanting to go into your living room, but to do so you need to go out the back door, around the block, and in through your front door. If that seems too much of an exaggeration, draw out what you are planning on doing using networking nomenclature. It's equally silly. Your problem, if you state it properly, is that you are not addressing the resource in a way that allows you the shortest path to it. So the problem is how you address it, not how you access it. Once you have accepted that, you can move to the next problem, which is ubiquitous access methods. You don't want to think about where you are, or what network you're on, in order to access the resource. Clearly using the local IP won't work, since that won't work outside the network. Luckily, we have a solution in DNS. Now all that's left is to configure a local DNS server to handle requests from within and around the local network, and configure your external DNS to do the same.

Edit:
People use meth to escape their shitty lives. People speed in their cars because they can't manage their time well. People don't pick their dogs shit up because they're lazy. This is similar - people that have no idea what they're doing have created a solution to a problem they don't understand. This was made worse for a long time by shitty router manufacturers that included (and still do include) options to implement this specifically, because it quickly satisfies, as you said, a common problem. That does not mean it's correct. It isn't. You have literally everything you need on any ROS device to handle this problem correctly, without ever using hairpin NAT.

I agree with quoted comment by thirdstreetzero.

Just think about going IPv6 ... no NAT there. So HairpinNAT really is an obscure solution to a specific problem ... and use case of @ivicask is just further exagerated misuse.

Quite a few times people requested full-featured DNS server for ROS ... and excuse is that they've got super-duper CCR1072 sitting in the comms closet and that it should be fit to perform those duties as well. I guess those people use their super-size wheel loaders for drift racing and container loading as well? People should use proper tools for particular job, that's all.

Use internal DNS.


When someone on the internet asks for your server web.myserver.com on inernal ip 192.168.10.50 he asks a public DNS and gets IP 85.12.134.20 (sample IP)
Then when you are on the internal net, you will use the DNS server you get from your DHCP server. That should not be google or other public DNS, server, but your DNS server. There you will get local IP 192.168.10.50. So you access your internal server directly without passing trough your router.

Code: Select all

server0.home.com 192.168.10.50
server1.home.com 192.168.10.51
server2.home.com 192.168.10.52
server3.home.com 192.168.10.53
server4.home.com 192.168.10.54
server5.home.com 192.168.10.55
server6.home.com 192.168.10.56
server7.home.com 192.168.10.57
server8.home.com 192.168.10.58
server9.home.com 192.168.10.59

If you buy for a DNS name (10$ a year) you can register as many public name as you like.
No need to use other ports than default

Could you give an full example on where Hairpin Nat is the only solution?
DNS name, ports, local/piblic IP etc.

Now i have set in my RDC connection file public dns name with ports matching which server i wanna access
blablab.dyndns.org:3000
blablab.dyndns.org:4000
blablab.dyndns.org:5000

Now i have set in my RDC connection file public dns name with ports matching which server i wanna access
blablab.dyndns.org:3000
blablab.dyndns.org:4000
blablab.dyndns.org:5000

I see that could be a problem.
But I would not have done it this way. For what you need to pay for dyndns.org each year to not need to renew it all the time, you can get you own domain for som around 10$. The you do:
blablab1.myserver.com:3000
blablab2.myserver.com:4000
blablab3.myserver.com:5000

But I would never open many RDP session to the internet.
Open only one RDP server and from that server connect to all other.
The less the better.

And since you do not use 3389, this is just for your admin use and not a generic solution so you with ease handle many dns name as you would handle different ports.

Edit:
People use meth to escape their shitty lives. People speed in their cars because they can't manage their time well. People don't pick their dogs shit up because they're lazy. This is similar - people that have no idea what they're doing have created a solution to a problem they don't understand. This was made worse for a long time by shitty router manufacturers that included (and still do include) options to implement this specifically, because it quickly satisfies, as you said, a common problem. That does not mean it's correct. It isn't. You have literally everything you need on any ROS device to handle this problem correctly, without ever using hairpin NAT.

So, no. Just because it doesn't fit Your use case it doesn't mean that it is wrong to use.

• cloud servers connecting to server through VPN need stable addressing
• road warriors
• teleworking
• VPN accesses

...
Also found this good comment by thirdstreetzero on reddit:

It breaks all kinds of fundamental standards and norms, not to mention statistics, security, things like fasttrack, etc. It makes transitions away from your current configuration more difficult. It's impossible for future people to interpret, as it shouldn't be done and without adequate explanation can often require a confusing mess of other work, especially if you've got any queues or packet mangling.

Imagine wanting to go into your living room, but to do so you need to go out the back door, around the block, and in through your front door. If that seems too much of an exaggeration, draw out what you are planning on doing using networking nomenclature. It's equally silly. Your problem, if you state it properly, is that you are not addressing the resource in a way that allows you the shortest path to it. So the problem is how you address it, not how you access it. Once you have accepted that, you can move to the next problem, which is ubiquitous access methods. You don't want to think about where you are, or what network you're on, in order to access the resource. Clearly using the local IP won't work, since that won't work outside the network. Luckily, we have a solution in DNS. Now all that's left is to configure a local DNS server to handle requests from within and around the local network, and configure your external DNS to do the same.

Edit:
People use meth to escape their shitty lives. People speed in their cars because they can't manage their time well. People don't pick their dogs shit up because they're lazy. This is similar - people that have no idea what they're doing have created a solution to a problem they don't understand. This was made worse for a long time by shitty router manufacturers that included (and still do include) options to implement this specifically, because it quickly satisfies, as you said, a common problem. That does not mean it's correct. It isn't. You have literally everything you need on any ROS device to handle this problem correctly, without ever using hairpin NAT.

...

So I missed this thread when it was new, but it's not too late to disagree now - hairpin NAT is awesome!

Ok, that was just to even things out a little. Reality is that haipin NAT should be unnecessary and by long time obsolete hack from old IPv4 + NAT times that were supposed to end years ago. Unfortunately, since the world is clearly not as excited by IPv6 as I've been for last ~18 years (well, I'm not sure if I'm still excited, but that's another matter), we're still living in IPv4 + NAT times and things got only worse.

Hairpin NAT, even though it's still hack, is simple, foolproof and elegant way how to solve many problems. It's one single srcnat rule. You set it once and you can forget about it. It will transparently work with anything, any hostname, even without DNS, no future changes necessary. How can anyone not like it?

There's one downside, packets from LAN to public address on router, from which ports are forwarded to internal server in same LAN, will take unnecessary trip there and back to LAN. So if you expect heavy traffic, you better go with internal DNS. But that's it.

There's one downside, packets from LAN to public address on router, from which ports are forwarded to internal server in same LAN, will take unnecessary trip there and back to LAN. So if you expect heavy traffic, you better go with internal DNS. But that's it.

Why hairpin NAT is the best thing in the world (only slightly biased comparison with local DNS override )

• common: nothing
• dns: nothing
• hairpin: add one srcnat rule

• common: add one dstnat rule to forward ports 80 and 443 to internal server; in public dns, point two hostnames to router's public address
• dns: add two hostnames in local dns
• haipin: nothing to do, everything works

• common: in public dns, point one hostname to router's public address
• dns: add one hostname in local dns (it won't work for local users until you do)
• haipin: nothing to do, everything works

• common: in public dns, point eshop hostname to different public address
• dns: remove eshop hostname from local dns (if you don't, local users will keep connecting to local server, which either doesn't run the virtual host anymore or in worse case it has stale version, so it seemingly works, but has old data, e.g. new orders don't show up)
• haipin: nothing to do, everything works

• common: change to-addresses in dstnat rule
• dns: in local dns, change all hostnames to new address
• haipin: nothing to do, everything works

• common: split dstnat rule for port 25 from the rest and set its to-addresses to another server
• dns: "Houston, we have a problem..."
• haipin: nothing to do, everything works

• common: nothing
• dns: "oh no, not again..."
• haipin: nothing to do, everything works

• common: add one dstnat rule to forward control and passive data ports to internal server
• dns: "that's it, I quit!"
• haipin: nothing to do, everything works

Another issue I have with hairpin NAT'ing is when you have many different LANs. Either you have to make a very wide hairpin NAT rule, or keep adding a new hairpin NAT rule every time a new LAN is created. This is further complicated if your servers are also not all on one dedicated server LAN/DMZ, having to again make a wide hairpin NAT rule that covers all of them or keep adding new hairpin NAT rules as servers get setup on new LANs/DMZs. Mix those two and you need a lot of hairpin NAT rules or one very wide hairpin NAT rule that covers everything from your whole network to your whole network.

Personally i use Hair pin nat in the following cases (just an example)
I have a dns name which with the help of a script i update it with my public IP address and at the same time there is a static dns entry in my router with the same Dns name which points to my rourers IP...

This way i can access from a public place any device i wish in my Lan with the appropriate port forward...And at the same time when i am inside my Lan i can still do the same...

for example i can see my Dvr cameras from outside and inside the lan by using the exact same Dns name with no changes at all... so when i am outside the lan it resolves to my public IP, but when i am inside the Lan it resolves to the routers IP and with the help of hair pin nat, (masquerade and dst nat) i can access my Dvr...

And what is the role of hairpin nat in this scheme? Why can't you just point the inside DNS directly to the resource?!