Page 1 of 1

NAT bug after bakcup channel activity

Posted: Mon Nov 12, 2012 2:04 pm
by warez
I have NAT trouble after jump to backup ISP channel.

I have two ISP channels by ether1 & ether2 interfaces with static IP. IF first main channel - down, traffic must go to second interface.
ether1 = x1.x2.x3.x4
ether2 = y1.y2.y3.y4

I write two IP addresses to Mikrotik Router and two SRC-NAT rule for each interface:
/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1 src-address=192.168.1.0/24
add action=masquerade chain=srcnat disabled=no out-interface=ether2 src-address=192.168.1.0/24
192.168.1.0/24 - this is LAN network

I write two Route strings with check gateways:
/ip route
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=<ip gw1> pref-src=<ISP1 ip address> scope=30 target-scope=10
add check-gateway=ping disabled=no distance=5 dst-address=0.0.0.0/0 gateway=<ip gw2> pref-src=<ISP2 ip address> scope=30 target-scope=10
I do endless ping from lan computer to external internet
ping 8.8.8.8 -t
Unplug ether1 cable from RouterBoard and see:
ping from computer is failed... and no up! Some moment ago ping from router itself go on. but ping from computer not go:
ping 8.8.8.8 -t - failed, BUT NEW ping other external IP go successfull. Sniffer show than ICMP ping packet to destanation IP=8.8.8.8 go from ether2 with IP address of ether1 (x1.x2.x3.x4)! What the f*ck?

If one channel is PPPoE - no this problem with NAT!

Re: NAT bug after bakcup channel activity

Posted: Tue Nov 13, 2012 7:07 am
by warez
please help! :( It's seems as bug of ROS NAT. I test it on v.5.21 and 4.17 versions.

Re: NAT bug after bakcup channel activity

Posted: Wed Nov 14, 2012 11:27 am
by janisk
having 2 ISPs usually users go with connection marks -> routing marks in mangle so that incoming connections are sent out same interface they came in, PCC configuration to load ballance traffic over both links. You can find examples here on the forums or on the wiki.mikrotik.com

Re: NAT bug after bakcup channel activity

Posted: Wed Nov 14, 2012 2:27 pm
by Chupaka
the 'problem' is because only initial packet of connection is affected by NAT, next packets are NATted automagically. so when you disable one WAN, packets go to another uplink, but they are still masqueraded by old public address, that's why it's not working

when you restart ping, Connection Tracking detects is as new 'connection' and masquerades it with correct address