Community discussions

MikroTik App
 
jollytall
just joined
Topic Author
Posts: 19
Joined: Sun Apr 11, 2021 4:29 pm

NAT from inside the LAN

Mon May 03, 2021 10:19 pm

(To be honest, it is the fifth time, I start to write this question, as I noticed so many unpredictable behaviors around NAT, but could not reproduce most of them. They have mainly gone after playing a lot with different settings, but there is one I cannot solve, but can reproduce.)

I set-up a NAT rule:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address-list=Home dst-port=8081 protocol=\
tcp to-addresses=192.168.64.64 to-ports=8081,
where Home is my fixed IP (actually I tried it even without this, but to make sure that any outbound communication to port 8081 can get through, it was safer to set it).

I also added a firewall filter to accept this traffic:
/ip firewall filter
add action=accept chain=forward connection-nat-state=dstnat log=yes

On 192.168.64.64:8081 I have a webserver.

What happens: When I load http://192.168.64.64:8081 from within the network, it works. When I load http://myownip.com:8081 from outside the LAN it also works. But when I try http://myownip.com:8081 from within the network, the request never reaches the server. I monitor the traffic (tx/rx volumes) on the NAT and I see the 60 byte packets all right. I also put a log on the filter rule, and I can see that the dst-nat happens and it reaches the firewall filter as well, where it is accepted. What I see in the log is:

forward: in:ether1 out:vlan1, src-mac xx:xx:xx:xx:xx:xx, proto TCP (SYN), externalip:3198->192.168.64.64:8081, NAT externalip:3198->(myownip:8081->192.168.64.64:8081), len 60, when used from outside and

forward: in:vlan1 out:vlan1, src-mac xx:xx:xx:xx:xx:xx, proto TCP (SYN), 192.168.64.96:40268->192.168.64.64:8081, NAT 192.168.64.96:40268->(myownip:8081->192.168.64.64:8081), len 60, when used from inside.

So in both cases it seems OK, but the first one works, the second does not.

I would appreciate any though, what can be wrong.

(As mentioned above, i had some other NAT rules, that also worked in strange ways. My feeling was that it is some sort of timing issue, or address pollution, conflict, or something like that, but could not figure it out.)
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: NAT from inside the LAN

Mon May 03, 2021 10:22 pm

You need hairpin NAT
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18961
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: NAT from inside the LAN

Tue May 04, 2021 2:26 am

Just add another sourcenat rule in this format
add chain=srcnat action=masquerade src-address=192.168.64.0/24 dst-address=192.168.64.0/24

Another solution is to put the server on a different subnet from users trying to access the server by public IP.
 
jollytall
just joined
Topic Author
Posts: 19
Joined: Sun Apr 11, 2021 4:29 pm

Re: NAT from inside the LAN

Tue May 04, 2021 10:15 am

Thank you both. It works. The description liked is also very clear.

Now a subsequent observation: If I try from 192.168.64.65 to reach 192.168.64.64:8081 it does not work. I guess it is because the request goes directly from .65 to .64, but the reply goes through masquerade and arrives back from .1 to .65, i.e. invalid. I can do a workaround (e.g. using 8082 to 8081 NAT on the public IP and set narrower NAT rules to masquerade the reply.

However, if I remember well, when I used a cheap router (only option was "port forwarding"), it worked in both cases (I might remember incorrectly). Is it because those are basically a router and a switch after each other, and if I do .65 to .64 then it turns back in the switch and if I use .65 to the public IP then it goes "up" to the router and turns back there both ways? Or something else? Or I remember incorrectly? Can RouterOS be configured in a way to make both working without any limitation on port or IP usage?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: NAT from inside the LAN

Tue May 04, 2021 2:22 pm

Local traffic between 192.168.64.65 and 192.168.64.64 should go directly without going via router unless there's some weird configuration on either of hosts involved. Hard to tell without seeing actual network configuration of both. Your example would indicate misconfiguration on 192.168.64.65 because it should not force local traffic through router.
Another possibility is to configure hairpin NAT only to masquerade traffic targeting public IP address and only route traffic targeting local addresses (in this case connection tracking should be disabled for local traffic as well). This, however, would only mask away configuration error on LAN hosts.

Indeed if traffic goes via router one way and directly the other way, then router will likely interfere (it'll see only packets traveling in one direction and these will be flagged as invalid). Which is usually problem of missing hairpin NAT (router only performs dst-nat, but not src-nat, which means return traffic goes directly which confuses client because it expects return traffic to come back from public IP address).

Many cheap routers, which have very limited set of possible settings, enable hairpin NAT together with usual dst-nat ... in MT world, everything has to be done explicitly because of immense versatility of devices running ROS.
 
jollytall
just joined
Topic Author
Posts: 19
Joined: Sun Apr 11, 2021 4:29 pm

Re: NAT from inside the LAN

Tue May 04, 2021 7:09 pm

Thanks,

You are right. Although I could not get my content from .65 to .64:8081 directly, it seems it was not because it went through the router, NAT, etc.. I made some checks, and indeed it never reached the firewall.
What the problem was/is, I still don't know. I tried many times from Firefox, no success. I tried pinging .64 from .65 and no success. Then I pinged .65 from .64 and it worked. So I tried wget from .65 to .64:8081 and it also worked. So I tried again with Firefox and it also worked. Still no idea, what was wrong. It is the same "unreliable behavior" I mentioned at the beginning.
So I tried to localize the problem. Disconnected .65 from the network and tried again. No web access, no ping from .65 to .64 (Destination Host Unreachable). Then a very slow ping from .64 to .65 (first packets in 2022 ms, second in 998 ms, the rest normal (<5m ms). After that the ping from .65 to .64 also works, but still slow, between 17 and 109 ms. So it is rather asymmetric, but then it works.
I tried it multiple times and always the same. After .65 is disconnected/connected, it cannot reach .64, but once .64 pings .65 it makes the .65 to .64 direction also OK, but much slower than the .64 to .65 direction. At least now I can reproduce the unreliable behavior.

The network is rather complex, but the relevant parts are simple. .65 is connected to ether 2 with cable. .64 is connected to the main wlan of MT. I have only one bridge. The bridge has ether 2 as PVID 64 admit all. The bridge also has wlanprivate also as PVID 64 admit all. I think the relevant config lines are as follows:

/interface ethernet
set [ find default-name=ether2 ] comment=\
"Direct port to the \"main\" PC (VLAN 64)"
/interface vlan
add comment="VLAN 64 for the Private network" interface=bridge name=\
vlan64private vlan-id=64
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
comment="The main WLAN for the Private network" disabled=no distance=\
indoors frequency=auto installation=indoor mode=ap-bridge name=\
wlanprivate security-profile=profileprivate ssid=Private \
wireless-protocol=802.11 wps-mode=disabled
/interface wireless manual-tx-power-table
set wlanprivate comment="The main WLAN for the Private network"
/interface wireless nstreme
set wlanprivate comment="The main WLAN for the Private network"
/ip dhcp-server
add address-pool=pool64private disabled=no interface=vlan64private name=\
server64private
/interface bridge port
add bridge=bridge interface=ether2 pvid=64
add bridge=bridge interface=wlanpinetree pvid=64
/ip neighbor discovery-settings
set discover-interface-list=none
/interface bridge vlan
add bridge=bridge tagged=bridge,ether5,ether4 vlan-ids=64
/ip address
add address=192.168.64.1/24 interface=vlan64private network=192.168.64.0
/ip dhcp-server lease
add address=192.168.64.64 comment="PC64 WiFi" mac-address=\
xx:xx:xx:xx:xx:xx server=server64private
add address=192.168.64.65 comment="PC65 Cable" mac-address=xx:xx:xx:xx:xx:xx \
server=server64private
/ip dhcp-server network
add address=192.168.64.0/24 gateway=192.168.64.1

I would welcome any idea what can be wrong.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: NAT from inside the LAN

Tue May 04, 2021 9:26 pm

So one of PCs is wireless client. I'd say you should check wireless: is there much of interference (other APs nearby), is the connection with decent signal strength, etc.
 
jollytall
just joined
Topic Author
Posts: 19
Joined: Sun Apr 11, 2021 4:29 pm

Re: NAT from inside the LAN

Wed May 05, 2021 1:12 pm

Thank you.
I made more checks and you were right (again). When I connected the .64 to ether3, the problem disappeared.
I also noticed that the .64 had used a WiFi AP far in the house, instead of the MT just next to the PC. I wonder why?
Anyway, I stopped the other, so the PC was forced to connect to the MT WiFi. Since then it is more reliable, but still far from perfect. The ping is totally asymmetrical. From WiFi to LAN the ping time is very stable between 4-5 ms. From the LAN to the WiFi it is much higher, often above 100 ms (average 60ms). I do not think there is much interference (I am in a rural area with very little WiFi noise) and my WiFi connection is otherwise very stable (cca. 80Mb/s up and download, 19 ms ping to speedtest.net servers). Is that normal that I see such asymmetrical behavior?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: NAT from inside the LAN

Wed May 05, 2021 6:23 pm

Some wireless clients (mobile phones specifically, others might as well) perform "mini sleeps" of wifi module to save power. During sleeps AP has to buffer frames until client wakes up and accepts packets. The same behaviour affects broadcasts as well, mikrotik by default just sends broadcast frames and if client is in sleep mode it misses them (which explains problem with initial connection establishment, broadcast is used by connection initiator to find out target's MAC address).
When doing outbound connections (pings), the problem is not there because wireless client can exit sleep mode sooner (OS interrupts the sleep) and transmits frame in due time. Delay before entering sleep mode is long enough to handle the reply in real time.

There are two ways to tackle the problem, neither guarantees full success: 1) enable multicast helper on AP (this feature converts broadcast frames into unicast frames for all connected wireless clients which allows buffering them so clients don't miss them) and 2) disable power saving features on client's wireless interface (normal laptops should be fine with it, smart phones usually don't have such a setting at all)
 
jollytall
just joined
Topic Author
Posts: 19
Joined: Sun Apr 11, 2021 4:29 pm

Re: NAT from inside the LAN

Wed May 05, 2021 9:05 pm

Thank you for the clear explanation. I will play a bit with it.

Who is online

Users browsing this forum: FlowerShopGuy, nepotu, tangent and 54 guests