Community discussions

MikroTik App
 
HairyOne
just joined
Topic Author
Posts: 12
Joined: Thu May 10, 2018 5:39 pm

Weird NAT issue on v6.42.1

Thu May 24, 2018 11:25 am

Good day people!
Maybe someone had encountered weird SRC/DST NAT issue on 6.42.1 (upgrade), here are the details:
Two network on LAN:
10.0.0.0/24 - workstations with IPs 10.0.0.2 and 10.0.0.3 (Mikrotik is on 10.0.0.1)
10.0.1.0/24 - DMZ servers with IPs 10.0.1.2, 10.0.1.3, 10.0.1.4 (Mikrotik is on 10.0.1.1)
Two IP addresses assigned to WAN interface: 172.16.1.2, 172.16.1.3, 172.16.1.4 (Mikrotik is on 172.16.1.1)

There is a DST\SRC NAT (without in-out interfaces) for:
10.0.1.2 <-> 172.16.1.2
10.0.1.3 <-> 172.16.1.3
10.0.1.4 <-> 172.16.1.4
There is a SRC NAT > 172.16.1.1 for 10.0.0.0/24 with out interface WAN

Now here is ping from workstation 10.0.0.2
ping www.somehostname.lv
Pinging www.somehostname.lv [172.16.1.2] (!!!) with 32 bytes of data:
Reply from 10.0.1.2 (!!!): bytes=32 time<1ms TTL=64
Reply from 10.0.1.2 bytes=32 time<1ms TTL=64

ping www.somehostname2.lv
Pinging www.somehostname2.lv [172.16.1.3] (!!!) with 32 bytes of data:
Reply from 172.16.1.3 (!!!): bytes=32 time<1ms TTL=64
Reply from 172.16.1.3 bytes=32 time<1ms TTL=64

And now here is ping from workstation 10.0.0.3
ping www.somehostname.lv
Pinging www.somehostname.lv [172.16.1.2] (!!!) with 32 bytes of data:
Reply from 172.16.1.2 (!!!): bytes=32 time<1ms TTL=64
Reply from 172.16.1.2 bytes=32 time<1ms TTL=64

ping www.somehostname2.lv
Pinging www.somehostname2.lv [172.16.1.3] (!!!) with 32 bytes of data:
Reply from 172.16.1.3 (!!!): bytes=32 time<1ms TTL=64
Reply from 172.16.1.3 bytes=32 time<1ms TTL=64

Below is NAT export
add action=src-nat chain=srcnat comment="OFFICE.NAT -> 1.1" out-interface=ether1_WAN src-address=10.0.0.0/24 to-addresses=172.16.1.1
add action=dst-nat chain=dstnat comment="DST NAT 1.2 -> 1.2 Host1" dst-address=172.16.1.2 to-addresses=10.0.1.2
add action=src-nat chain=srcnat comment="SRC NAT 1.2 -> 1.2 Host1" src-address=10.0.1.2 to-addresses=172.16.1.2
add action=dst-nat chain=dstnat comment="DST NAT 1.3 -> 1.3 Host2" dst-address=172.16.1.3 to-addresses=10.0.1.3
add action=src-nat chain=srcnat comment="SRC NAT 1.3 -> 1.3 Host2" src-address=10.0.1.3 to-addresses=172.16.1.3

So in a nutshell: two identical hosts on LAN ping two identical hosts in DMZ. One gets replies from external IP, another get replies from internal IP (guess, how accessible serves is to that workstation). After a day or two, problem disappears and then reappears.
Started after migration to 6.42.1
Please advice!
 
User avatar
Anumrak
Forum Guru
Forum Guru
Posts: 1174
Joined: Fri Jul 28, 2017 2:53 pm

Re: Weird NAT issue on v6.42.1

Thu May 24, 2018 1:05 pm

You better assign input and output interfaces in rules.
 
HairyOne
just joined
Topic Author
Posts: 12
Joined: Thu May 10, 2018 5:39 pm

Re: Weird NAT issue on v6.42.1

Thu May 24, 2018 1:58 pm

You better assign input and output interfaces in rules.
That will require to create multiple rules - one for in interface LAN, one for in interface WAN, another for possible IPIP interfaces.
By omitting interface, and leaving only DST\SRC address, I can have one rule for any interface that comes in (including PPTPs etc).

What is interesting, entries in connection tracking table are correct for both cases (the one when ping replies are coming from DMZ server ip, and the one where replies are coming from NATted IP).
 
pe1chl
Forum Guru
Forum Guru
Posts: 10575
Joined: Mon Jun 08, 2015 12:09 pm

Re: Weird NAT issue on v6.42.1

Thu May 24, 2018 2:39 pm

You can make interface lists LAN and WAN, put the appropriate interfaces in them, and use interface lists for input and output.
In fact when you have setup the router under a recent version those interface lists are already there.
When you have started in the past on an old version and upgraded it all the time, that isn't true.
Depending on your skills and configuration it could be a good idea to reset the router to defaults als work from the settings
you have then (different firewall, usage of interface lists).
 
HairyOne
just joined
Topic Author
Posts: 12
Joined: Thu May 10, 2018 5:39 pm

Re: Weird NAT issue on v6.42.1

Thu May 24, 2018 4:31 pm

You can make interface lists LAN and WAN, put the appropriate interfaces in them, and use interface lists for input and output.
In fact when you have setup the router under a recent version those interface lists are already there.
When you have started in the past on an old version and upgraded it all the time, that isn't true.
Depending on your skills and configuration it could be a good idea to reset the router to defaults als work from the settings
you have then (different firewall, usage of interface lists).
That is what I will probably end up doing in the end.
0) scrapping all configuration
1) splitting DMZ into two parts - one with public IP addresses, second with NATted IP addresses for servers that must have split DNS (like MS Exchange servers with webaccess).

Interface lists, yes.My case was transition from Master-Slave to Bridge with two interfaces during migration. I have a feeling that this, actually might be a reason.
Ping from one of the servers (route is 10.0.1.4>10.0.1.1|10.0.0.1>10.0.0.147)

# ping 10.0.0.147
PING 10.0.0.147 (10.0.0.147) 56(84) bytes of data.
64 bytes from 10.0.0.147: icmp_req=1 ttl=127 time=0.510 ms
From 10.0.1.1: icmp_seq=2 Redirect Host(New nexthop: 10.0.0.147)
64 bytes from 10.0.0.147: icmp_req=2 ttl=127 time=0.285 ms
64 bytes from 10.0.0.147: icmp_req=3 ttl=127 time=0.252 ms

Traceroute from that server:
traceroute to 10.0.0.147 (10.0.0.147), 30 hops max, 60 byte packets
1 somehost4 (10.0.0.147) 0.133 ms * *

traceroute to 10.0.0.11 (10.0.0.11), 30 hops max, 60 byte packets
1 10.0.1.1 (10.0.1.1) 0.195 ms 0.176 ms 0.164 ms
2 somehost5 (10.0.0.11) 0.423 ms 0.510 ms 0.502 ms

Something got so FUBARed during upgrade that even simple routing without NAT misbehaves.

Edit: fixed redirect messages by blocking output from router, at least tracert works fine now:
/ip firewall filter
add action=drop chain=output disabled=no icmp-options=5:0-255 out-interface=bridge1 protocol=icmp
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 22582
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Weird NAT issue on v6.42.1

Thu May 24, 2018 7:44 pm

Hi Hairyone, just trying to follow the thread, is the wan setup as follows.
Block of IPs from provider given to you.
USING 172.168.1.1 as the one assigned to the mikrotik (for the purposes of a private LAN behind and administration) (many to one NAT)
Using 172.168.1.2 - 172.168.1.4 as 3 public IP addresses from the provider (in a one to one nat scenario )

I have no clue on how to setup what can be stated as
LAN X with one IP (the server) mated to one public IP
LAN Y etc. (next server)
LAN Z etc...... (third server)

What I find confusing is putting these one to one mappings with one LAN (10.0.1.0 network).
To keep things straight I would have probably used
172....1.2 mapped to 10.0.2.2 (Server1 LAN 10.0.2.0 network, mask of 255.255.255.252)
172....1.3 mapped to 10.0.3.2 (Server2 LAN 10.0.3.0 network, mask of 255.255.255.252
172....1.4 mapped to 10.0.4.2 (Server3 LAN 10.0.4.0 network, mask of 255.255.255.252)

That way the servers are truly separate in terms of everything.
Each would have its own DSTNAT rule and SRCNAT RULE.
Probably need a forward rule to allow the DSTNAT connections.
Not sure on the Routing as I have not applied more than one WANIP to a single interface so i dont know if one gets a separate DHCP client option for each ISP provided IP connection (where one selects default route).

Example of NAT mappings for one to one
ip firewall nat add chain=dstnat dst-address=172.......1.2 action=dst-nat to-addresses=10.2.2.2
ip firewall nat add chain=srcnat src-address=10.2.2.2 action=src-nat to-addresses=172.....1.2
Last edited by anav on Fri May 25, 2018 5:00 am, edited 1 time in total.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 13364
Joined: Thu Mar 03, 2016 10:23 pm

Re: Weird NAT issue on v6.42.1

Fri May 25, 2018 12:30 am

Ping from one of the servers (route is 10.0.1.4>10.0.1.1|10.0.0.1>10.0.0.147)

# ping 10.0.0.147
PING 10.0.0.147 (10.0.0.147) 56(84) bytes of data.
64 bytes from 10.0.0.147: icmp_req=1 ttl=127 time=0.510 ms
From 10.0.1.1: icmp_seq=2 Redirect Host(New nexthop: 10.0.0.147)
64 bytes from 10.0.0.147: icmp_req=2 ttl=127 time=0.285 ms
64 bytes from 10.0.0.147: icmp_req=3 ttl=127 time=0.252 ms
This redirect makes me think that router somehow considers 10.0.1.4 and 10.0.0.147 to be part of same subnet? Are router's addresses set with correct netmask? It seems like /24 was the correct one.
 
HairyOne
just joined
Topic Author
Posts: 12
Joined: Thu May 10, 2018 5:39 pm

Re: Weird NAT issue on v6.42.1

Fri May 25, 2018 10:17 am

This redirect makes me think that router somehow considers 10.0.1.4 and 10.0.0.147 to be part of same subnet? Are router's addresses set with correct netmask? It seems like /24 was the correct one.
Exactly - both networks are on same physical interface, but on separate subnets. Netmasks are /24 for each network (that was my first thought too - that one of the servers might have /8 mask). I found in separate thread that solution is to block icmp output, so the router does not advertise redirects.
 
HairyOne
just joined
Topic Author
Posts: 12
Joined: Thu May 10, 2018 5:39 pm

Re: Weird NAT issue on v6.42.1

Fri May 25, 2018 10:25 am

Hi Hairyone, just trying to follow the thread, is the wan setup as follows.
Block of IPs from provider given to you.
USING 172.168.1.1 as the one assigned to the mikrotik (for the purposes of a private LAN behind and administration) (many to one NAT)
Using 172.168.1.2 - 172.168.1.4 as 3 public IP addresses from the provider (in a one to one nat scenario )
Correct
What I find confusing is putting these one to one mappings with one LAN (10.0.1.0 network).
To keep things straight I would have probably used
172....1.2 mapped to 10.0.2.2 (Server1 LAN 10.0.2.0 network, mask of 255.255.255.252)
172....1.3 mapped to 10.0.3.2 (Server2 LAN 10.0.3.0 network, mask of 255.255.255.252
172....1.4 mapped to 10.0.4.2 (Server3 LAN 10.0.4.0 network, mask of 255.255.255.252)
That is not so much different from simple one-to-one nat, with the difference that now each server has a separate subnet, just a routing table gets a bit bigger.
That way the servers are truly separate in terms of everything.
Each would have its own DSTNAT rule and SRCNAT RULE.
Probably need a forward rule to allow the DSTNAT connections.
I already have separate SRC\DST NAT rules for each server... The problem as I see it, that it works\doesn't work in unpredictable way. Two copied SRC/DST rules pointing to different LAN IP addresses perform in a different way.
Example of NAT mappings for one to one
ip firewall nat add chain=dstnat dst-address=172.......1.2 action=dst-nat to-addresses=10.2.2.2
ip firewall nat add chain=srcnat src-address=10.2.2.2 action=src-nat to-addresses=172.....1.2
Yep. Now in my case, one rule will work, another will reply with internal IP address.