Community discussions

MikroTik App
 
dabardabar
just joined
Topic Author
Posts: 20
Joined: Tue Sep 28, 2021 10:59 am

Working around NAT hairpin

Wed Nov 17, 2021 2:52 pm

Hello all,

A beginner here and I have been struggling for weeks now with this issue :)

Some time ago I have successfully done port forwarding to access my server from external networks using a domain - lets call it testdomain.com

I kept the default network configuration 192.168.88.1/24 and the server had a fixed IP 192.168.88.200, everything worked fine from outside when accessing the domain, but from the LAN I would always be taken to the router login page.

I read dozens of threads, articles, youtube videos over enabling hairpin NAT, but none of the examples worked for me, I really have no idea why.

Then I read in a couple of threads here that an alternative is to simply put the server on a different subnet/network so I thought I'd try that.

What I did then is assign the Eth3 to have another network setup as 192.168.90.1/24 and put the server to have static IP 192.168.90.200 and connected it to that port.

Setup the server's IPv4 to have 192.168.90.1 as gateway and 255.255.255.0 as subnet mask - the internet on the server works and it can see other computers and also other computers which have IP 192.168.88.XXX can see it.

If I try and access 192.168.90.200 from another PC browser, it correctly opens the website.

Also, I have altered the port forwarding rule in MT to point to the new IP and now when I am using external network to access testdomain.com the website is shown correctly.

Buuuut, I still cannot use testdomain.com from any computer on my internal network, for example a PC with IP 192.168.88.101, it still takes me to MT login page from any of those computers.
If I type 192.168.90.200 instead, it will correctly open the website.

Why is that so, did I miss the point completely, is the server not on separate network yet?

Here are some screenshots and the config:
Screenshot 2021-11-17 at 13.39.58.png
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.99
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
add address=192.168.90.1/24 comment=Servers interface=ether3 network=192.168.90.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="port forward for server" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200
add action=masquerade chain=srcnat comment="NAT hairpin" disabled=yes dst-address=!192.168.88.1 src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment="Hairpin NAT 2" disabled=yes dst-address=192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
/lcd interface pages
set 0 interfaces=sfp1,ether1,ether2,ether3,ether4,ether5,ether6,ether7,ether8,ether9,ether10
You do not have the required permissions to view the files attached to this post.
 
2frogs
Forum Veteran
Forum Veteran
Posts: 713
Joined: Fri Dec 03, 2010 1:38 am

Re: Working around NAT hairpin

Wed Nov 17, 2021 4:06 pm

You have used the incorrect dst-nat for local access. You have used in-interface-list=wan and local traffic does not reach the wan interface. You options to fix it by adding a static dns entry pointing towards your server, but this only works if you are using a local dns.

If you have a static public IP address, using dst-address is the recommended method.

And you came close to using one of the methods for a dynamic IP address with one of your attempted hairpin nat. You just left out the "!". (! = not)
add action=dst-nat chain=dstnat comment="Hairpin NAT 2" disabled=yes dst-address=192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
Should have been:
add action=dst-nat dst-address=!192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
Or you can put an dynamic dns in an address-list and use dst-address-list.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Wed Nov 17, 2021 4:43 pm

 
dabardabar
just joined
Topic Author
Posts: 20
Joined: Tue Sep 28, 2021 10:59 am

Re: Working around NAT hairpin

Wed Nov 17, 2021 10:25 pm

You have used the incorrect dst-nat for local access. You have used in-interface-list=wan and local traffic does not reach the wan interface. You options to fix it by adding a static dns entry pointing towards your server, but this only works if you are using a local dns.

If you have a static public IP address, using dst-address is the recommended method.

And you came close to using one of the methods for a dynamic IP address with one of your attempted hairpin nat. You just left out the "!". (! = not)
add action=dst-nat chain=dstnat comment="Hairpin NAT 2" disabled=yes dst-address=192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
Should have been:
add action=dst-nat dst-address=!192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
Or you can put an dynamic dns in an address-list and use dst-address-list.
Unfortunately I do not have a static IP adress, it is dynamic, I am using my domain registrar's dynamic DNS feature which works great, on previous router all I had to do was select "NAT loopback" and it worked without any further hassle :)

So, you suggest I create this rule, and everything should work fine?
add action=dst-nat dst-address=!192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
What about the separate network I have created which transferred the server to 192.168.90.200, should I let it like that, or roll back to .88 or it is irrelevant?
I noticed this great guide, but I must have been doing something wrong :)

That's why I decided to try and follow this guideline:

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, done!


Now I have no idea, have I done that correctly when I moved my server to 192.168.90.200 or I missed the whole thing completely?

Is there any pro/con of choosing either approach if I don't really care which network the server is on as long as I can access it locally/externally from other computers?

What do you guys suggest I do? :)
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Wed Nov 17, 2021 11:22 pm

Hi there,
If its no issue to move the server to a different subnet then you are done!
Often that is not possible and then you have to look at the alternate options laid out in the article.
So yes,

Solution A: Move subnet to different LAN (or users)
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="port forward for server" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200

Should be all that is required! All users on the primary LAN .88, should be able to reach the server using the domain address.

Solution B: In all cases (other than the DNS method) you will need this as masquerade rules
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat dst-address=192.168.88.0/24 src-address=192.168.88.0/24

Since you have a dynamic WANIP, the basic DST nat rule wont suffice, and you have three ways to modify the rule........
a. as per the youtube video (using routers ip cloud and pulling that into a firewalldress - and using that as destination to replace in-interface-list=WAN)
b. basically the same concept using a script to pull the WANIP into a firewall address - and using that as destination to replace in-interface-list=WAN
c. writing a kludge rule that tells the router to use a local router interface that is not the available LAN interface WAN (so only local interface left is the WAN one)

Solution C:
Dont need extra source nat rule and can use standard DST NAT RULE, (but need to do DNS redirect )
 
dabardabar
just joined
Topic Author
Posts: 20
Joined: Tue Sep 28, 2021 10:59 am

Re: Working around NAT hairpin

Thu Nov 18, 2021 11:24 pm

Haha unfortunately I feel so dumb, I still haven't worked it out :)

Okay, just to cover the basics, about this:
If its no issue to move the server to a different subnet then you are done!
Move subnet to different LAN (or users)
So, my primary network is 192.168.88.x, and all the client computers are there.

The server is on another network at 192.168.90.x with IP 192.168.90.200

Did I do that correctly, does that mean that the server is on another subnet - did I make the prerequisite for proceeding further?

I assumed it to be, so I tried to follow through with solution A, so, my rules are now as follows (only 2 enabled):
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Port Forward for server v2" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200
add action=dst-nat chain=dstnat comment="port forward for server" disabled=yes dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200
add action=masquerade chain=srcnat comment="NAT hairpin" disabled=yes dst-address=!192.168.88.1 src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment="Hairpin NAT 2" disabled=yes dst-address=192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
Is that all there is to do, it should have been working now or still not?

Because it isn't :)

I have just tried with a PC which has an IP 192.168.88.201 and it was unforunately still not working, I was taken to the RB login again.

Any ideas what I might be missing? :)
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Thu Nov 18, 2021 11:38 pm

Haha unfortunately I feel so dumb, I still haven't worked it out :)

Okay, just to cover the basics, about this:
If its no issue to move the server to a different subnet then you are done!
Move subnet to different LAN (or users)
So, my primary network is 192.168.88.x, and all the client computers are there.

The server is on another network at 192.168.90.x with IP 192.168.90.200

Did I do that correctly, does that mean that the server is on another subnet - did I make the prerequisite for proceeding further?

I assumed it to be, so I tried to follow through with solution A, so, my rules are now as follows (only 2 enabled):
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Port Forward for server v2" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200
add action=dst-nat chain=dstnat comment="port forward for server" disabled=yes dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200
add action=masquerade chain=srcnat comment="NAT hairpin" disabled=yes dst-address=!192.168.88.1 src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment="Hairpin NAT 2" disabled=yes dst-address=192.168.88.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=192.168.88.200 to-ports=80
Is that all there is to do, it should have been working now or still not?

Because it isn't :)

I have just tried with a PC which has an IP 192.168.88.201 and it was unforunately still not working, I was taken to the RB login again.

Any ideas what I might be missing? :)
That is weird, it is confusing as you have kept rules that you dont need but noticed they are disabled.

Suggest post your entire config for review
/export hide-sensitive file=anynameyouwish
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11440
Joined: Thu Mar 03, 2016 10:23 pm

Re: Working around NAT hairpin  [SOLVED]

Fri Nov 19, 2021 12:26 am

For connections WAN->server you need only first two NAT rules:
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Port Forward for server v2" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200

Reason that the DST-NAT rules doesn't work for LAN->server connections is use of in-interface-list=WAN. Basically you want to keep using WebFig from LAN. But LAN->server connection doesn't enter router through WAN interface. With statical WAN IP the problem is easily solved: use dst-address=WAN.IP instead. With dynamic IP address it doesn't work, some more clever stuff is needed. For example instead of second rule above use the following one:
add action=dst-nat chain=dstnat comment="Port Forward for server v3" dst-port=80 protocol=tcp dst-address-type=local dst-address=!192.168.88.1 to-addresses=192.168.90.200
The first property (dst-address-type) makes sure that this rule only affects packets targeting one of router's own addresses (either WAN, LAN or server's subnet), the second property (dst-address=!) excludes packets sent to LAN IP address of router. In case when there are multiple LAN subnets in game (and you want to offer WebFig access to router from all LANs), one would create address list, add all router's LAN addresses to it and use property dst-address-list=!LANaddressList instead of single LAN address.

BTW, the problem solved by rule above is exactly the same when server is either in separate LAN or same LAN (in later case one needs third NAT rule - src-nat for LAN->LAN connections which is the gist of hair-pin NAT), it is only solving the problem of dynamic WAN address.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 12:45 am

So MKX,
Having the server on a different subnet from the Users DOES NOT avoid hairpin nat??
Further the issue is the makeup of the normal dstnat rule and thus the real culprit is
"in-interface-list=WAN" or in-interface=WAN for a dynamic WANIP??

If so I have been working from a wrong assumption all this time. :-(
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 1:48 am

Buuuut, I still cannot use testdomain.com from any computer on my internal network, for example a PC with IP 192.168.88.101, it still takes me to MT login page from any of those computers.
If I type 192.168.90.200 instead, it will correctly open the website.

As I wrote another dozen times already, use the routerboard to resolve the internal DNS requests, (or set on your DNS server) that testdomain.com A record is 192.168.88.101

Outside all works because external DNS point testdomain.com to routerboard (natted port?),
internally all works because testdomain.com are resolved as 192.168.88.101,
and work all also legit SSL certificates.
No hairpin NAT or "different subnet" are involved.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 3:31 am

Buuuut, I still cannot use testdomain.com from any computer on my internal network, for example a PC with IP 192.168.88.101, it still takes me to MT login page from any of those computers.
If I type 192.168.90.200 instead, it will correctly open the website.

As I wrote another dozen times already, use the routerboard to resolve the internal DNS requests, (or set on your DNS server) that testdomain.com A record is 192.168.88.101

Outside all works because external DNS point testdomain.com to routerboard (natted port?),
internally all works because testdomain.com are resolved as 192.168.88.101,
and work all also legit SSL certificates.
No hairpin NAT or "different subnet" are involved.
Understood rextended and that is one of the options available and probably the best one ;-)
However, I was under the impression moving the server to a different subnet would solve it as well, no tricks required!!
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3292
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: Working around NAT hairpin

Fri Nov 19, 2021 8:38 am

1 or few servers/ports: Use internal DNS
Many servers/ports: Use Hairpin

When using Hairpin NAT traffic from local host to local server will go trough router instead of directly to the server.
Normally not a problem.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 10:21 am

However, I was under the impression moving the server to a different subnet would solve it as well, no tricks required!!
If you want use that method, why move and probably create more problems on devices than still point the server, on the right way, with correct IP?
Simple add another subnet just for this.
Last edited by rextended on Fri Nov 19, 2021 5:44 pm, edited 1 time in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 5:32 pm

My apologies dabardabar, the guide on simply moving the server to a different subnet was not complete.
Instead of this the basic default rules.
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp \
in-interface-list=WAN to-addresses=192.168.90.200

Use the following
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp \
in-interface-list=portforwarding to-addresses=192.168.90.200

So basically the extra step includes adding another interface list entry and then defining the members.
Give it a go and see if it works!!

/interface list
add name=portforwarding
/interface list members
{already existing entries plus}
add interface=ether1 list=portforwarding
add interface=bridge list=portforwarding
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11440
Joined: Thu Mar 03, 2016 10:23 pm

Re: Working around NAT hairpin

Fri Nov 19, 2021 6:34 pm

Having the server on a different subnet from the Users DOES NOT avoid hairpin nat??
It does. Hairpin-NAT is when clients are on the same subnet as server but they are not aware of it (because they think they're talking to some internet host) - the issue is return traffic (server sees clients from same subnet and bypasses NAT entity). If server is on another subnet, then server sees clients are not in same subnet and uses its gateway (the DST-NAT device).

Further the issue is the makeup of the normal dstnat rule and thus the real culprit is
"in-interface-list=WAN" or in-interface=WAN for a dynamic WANIP??
As I wrote before: rule property in-interface-list=WAN prevented the rule from performing DST-NAT for packets entering router from LAN.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3292
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: Working around NAT hairpin

Fri Nov 19, 2021 7:32 pm

It does. Hairpin-NAT is when clients are on the same subnet as server but they are not aware of it (because they think they're talking to some internet host) - the issue is return traffic (server sees clients from same subnet and bypasses NAT entity). If server is on another subnet, then server sees clients are not in same subnet and uses its gateway (the DST-NAT device).
I have not tested this, but I do not think this works.

You have a router with two VLAN.
VLAN 1:192.168.1.0/24 Client net
VLAN 2:192.168.8.0/24 Server net

Public IP 12.12.12.12
NAT www.myserver.home port 80/tcp 12.12.12.12->192.168.8.12

If a client on a VLAN 1 tries to reach the server, DNS will give IP 12.12.12.12 when you ask a public IP.
Will the router automatically redirect the data to the internal server? I do not think so.

Using Hairpin or a static internal DNS record for www.myserver.home to 192.168.8.12 will make you reach the server.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 7:53 pm

(not for @Jotne)
All this effort for not to use the easy DNS solution I suggested?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11440
Joined: Thu Mar 03, 2016 10:23 pm

Re: Working around NAT hairpin

Fri Nov 19, 2021 8:35 pm

I have not tested this, but I do not think this works.

Let me try to explain it slowly.

Consider the following example:
WAN IP 12.12.12.12
client LAN subnet: 192.168.10.0/24
server LAN subnet: 192.168.20.0/24

One has DST-NAT set up (the following one should not be used as it interferes with normal LAN->WAN connectivity because it is too simplified):
/ip firewall nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=80 to-addresses=192.168.20.0

Now the packet flow: client from internet -> router -> DST-NAT -> server . Server sees connection from internet IP address and uses router for return traffic, router undoes DST-NAT and traffic flows.
client from client LAN -> router -> DST-NAT -> server . Server sees connection from client LAN IP address and uses router for return traffic, router undoes DST-NAT and traffic flows.

And the above is straight DST-NAT, hairpin is not in the picture. It is only necessary to construct the DST-NAT rule which applies to all traffic, not only traffic ingressing through WAN interface (which was the case with OP's initial configuration).

Now another scenario:

WAN IP 12.12.12.12
LAN subnet: 192.168.10.0/24 (both server and clients are in same subnet)

Using same (very greedy) DST-NAT rule the internet access to the NATed server works just like in the previous case. Packet flow for connections from LAN clients is different: client -> router -> DST-NAT -> server . Server sees src-address from LAN (note that DST-NAT only changes dst-address and dst-port) and sends return traffic directly. Which causes two problems: 1) NAT router doesn't see return traffic and hence doesn't update connection tracking state for tjis connection and 2) client rejects return traffic because src-address of return traffic doesn't correspond with any open connection. Both problems will block connection but problem #2 is the one blocking it earlier.

Here comes the hairpin NAT part deux: additional NAT rule in form
/ip firewall nat
add chaon=srcnat action=masquerade dst-address=192.168.10.0/24 src-address=192.168.10.0/24

This alters the packet flow: client -> touter -> DST-NAT -> SRC-NAT -> server . Server sees connection to originate from router itself, hence directs return traffic towards router, router undoes both NATs and traffic between client and server flows.

I hope that above explanation makes clear when hairpin NAT is necessary and when not.

@regextended: using split DNS certainly does have certain positive sides, one is simplified firewall and NAT configuration, server sees client's real IP address instead of router's address. But at the same time comes with a few drawbacks (some of them are result of DST-NAT for public access): one has to bother with setting up local DNS server (DNS service on ROS is hardly adequate), if using service from internet and LAN when on internet port used is not standard one has to remember to change service connection setup (it's fairly easy with http/https, not so easy for other services) while taking care of actually used network access ... so sometimes it is easier to simply add the LAN-LAN SRC-NAT and slightly change the DST-NAT rule to avoid the split-DBS problems.

At the end of the day it's up to network admin to choose which solution to implement. I always go with split-DNS solution recomended by @regextended
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Working around NAT hairpin

Fri Nov 19, 2021 9:13 pm

DNS override has exactly one advantage - traffic doesn't have to unnecessarily go to router and back. Everything else speaks for hairpin NAT, see e.g.:

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

It's almost boring, fully transparent, set it & forget it. The only (small) challenge with hairpin NAT is finding out how to create proper dstnat rules for your setup, that's what people usually stuggle with. And even that is usualy simple to solve, only with NAT 1:1 it can be a little annoying.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 10:27 pm

Sob where you have been ole chum, I almost fainted when I saw you had posted!!
Is the real Sob? or some sick imposter??
You have made my day!
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Working around NAT hairpin

Fri Nov 19, 2021 10:36 pm

I'm on strike until final RouterOS v7 comes out, but I had to come and check if you behave. ;) Although thinking about it, I probably should have said something to someone, if I wanted it to have any effect. Not that I'd really think it would make any difference. Nah, I'm just kidding completely, I needed to take a break, I found out that I was spending way too much time here.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Working around NAT hairpin

Fri Nov 19, 2021 11:21 pm

I needed to take a break, I found out that I was spending way too much time here.
So it was a detox of a kind, OK. With this Covid and alike, I was scared you shifted to Juniper :)
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Working around NAT hairpin

Fri Nov 19, 2021 11:49 pm

I always go with split-DNS solution recomended by @regextended
Ah, I understand why "regextended" instead of rextended...

RegExTended:
"Incline to use Regular Expression" :lol: :lol: :lol: :lol:
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19107
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Working around NAT hairpin

Sat Nov 20, 2021 12:29 am

I needed to take a break, I found out that I was spending way too much time here.
So it was a detox of a kind, OK. With this Covid and alike, I was scared you shifted to Juniper :)
And all this time I thought he had retired seeing as I was answering all the threads satisfactorily..........

Missed you buddy SO GLAD your back!!!
 
dabardabar
just joined
Topic Author
Posts: 20
Joined: Tue Sep 28, 2021 10:59 am

Re: Working around NAT hairpin

Sat Nov 20, 2021 2:30 pm

Haha wow, I am glad have I sparked such a nice discussion :D

Thank you all for your inputs and help, unfortunately I am on a trip since 2 days ago so I will get back in the office tomorrow and try everything you guys suggested!

I must admit I am a bit overwhelmed with all the information, although I think I get the gist of it all you guys are telling me so hopefully I will make some real progress tomorrow, I will definitely report back once I have tried it! :)
 
dabardabar
just joined
Topic Author
Posts: 20
Joined: Tue Sep 28, 2021 10:59 am

Re: Working around NAT hairpin

Mon Nov 22, 2021 10:42 pm

For connections WAN->server you need only first two NAT rules:
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment="Port Forward for server v2" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=192.168.90.200

Reason that the DST-NAT rules doesn't work for LAN->server connections is use of in-interface-list=WAN. Basically you want to keep using WebFig from LAN. But LAN->server connection doesn't enter router through WAN interface. With statical WAN IP the problem is easily solved: use dst-address=WAN.IP instead. With dynamic IP address it doesn't work, some more clever stuff is needed. For example instead of second rule above use the following one:
add action=dst-nat chain=dstnat comment="Port Forward for server v3" dst-port=80 protocol=tcp dst-address-type=local dst-address=!192.168.88.1 to-addresses=192.168.90.200
The first property (dst-address-type) makes sure that this rule only affects packets targeting one of router's own addresses (either WAN, LAN or server's subnet), the second property (dst-address=!) excludes packets sent to LAN IP address of router. In case when there are multiple LAN subnets in game (and you want to offer WebFig access to router from all LANs), one would create address list, add all router's LAN addresses to it and use property dst-address-list=!LANaddressList instead of single LAN address.

BTW, the problem solved by rule above is exactly the same when server is either in separate LAN or same LAN (in later case one needs third NAT rule - src-nat for LAN->LAN connections which is the gist of hair-pin NAT), it is only solving the problem of dynamic WAN address.
@mkx, Wow, I am happy to say that fortunately this approact worked, this rule handled it!

So, to sum it up, the server remained on a separate network with the IP 192.168.90.200 and I added the second rule and now it works, thanks a thousand times!
My apologies dabardabar, the guide on simply moving the server to a different subnet was not complete.
@anav, No problem, glad that you caught it so someone else doesn't end up confused like I did :)

@all others - thank you guys a lot, there's a lot of invaluable knowledge and information here which I have no doubt will help someone else some time!

Just one more final question to satisfy my curiosity, about the current setup which I have (with the rules from mkx's post above) - is that the 'preferred' method, ie, about all that talk about 'undesired' package flow and greedy rules, does it apply to the solution I followed, or it is the correct approach?

It seems to me that @mkx mentioned the most on the subject so I guess I can assume that the solution posted earlier (and used by me) does not fall into that category of less desired solutions? :)
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11440
Joined: Thu Mar 03, 2016 10:23 pm

Re: Working around NAT hairpin

Wed Nov 24, 2021 12:43 am

The rule you quoted in preceeding post is specific enough, you're good.
 
dabardabar
just joined
Topic Author
Posts: 20
Joined: Tue Sep 28, 2021 10:59 am

Re: Working around NAT hairpin

Wed Nov 24, 2021 10:12 am

Great and thank you very much! :)

Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Vyizis and 46 guests