Page 1 of 1

NAT with Multi-Gateway problems

Posted: Wed Mar 08, 2017 6:55 pm
by Cyb3r
I'm having some issue using a CCR1036 with software release 6.38.3, I'm trying to nat some LAN IP classes on specific public IP addresses

Example configuration:
ip route print
0 A S  0.0.0.0/0                          1.1.1.254            1
1   S  0.0.0.0/0                          2.2.2.254            1
2 ADC  1.1.1.0/24    1.1.1.1    Vlan1111               0
3 ADC  2.2.2.0/24    2.2.2.1    Vlan2222               0
4 ADC  192.168.1.0/24    192.168.1.254  vlan11                   0
5 ADC  192.168.2.0/24    192.168.2.254  vlan22                   0
[/color]

ip firewall nat print
chain=srcnat action=src-nat to-addresses=1.1.1.1 src-address=192.168.1.1-192.168.1.10
chain=srcnat action=src-nat to-addresses=1.1.1.2 src-address=192.168.1.11-192.168.1.20
...
chain=srcnat action=src-nat to-addresses=2.2.2.1 src-address=192.168.2.1-192.168.2.10
chain=srcnat action=src-nat to-addresses=2.2.2.2 src-address=192.168.2.11-192.168.2.20
...
[/color]

ip address print
 0   1.1.1.1/24    1.1.1.0     Vlan1111
 1  1.1.1.2/24    1.1.1.0     Vlan1111
 [...]
 6  2.2.2.1/24    2.2.2.0     Vlan2222
 7  2.2.2.2/24    2.2.2.0     Vlan2222
 [...]
 8   192.168.1.254/24  192.168.1.0    vlan11
 9   192.168.2.254/24  192.168.2.0    vlan22
[/color]

With this configuration only the NAT using IPs 192.168.1.0/24 works, but the other class (192.168.2.0/24) not.
I've done some debugging using packet sniffer/tcpdump, if I try to ping a remote server on other network (OVH Server), on the server I've this dump:
17:36:53.940616 IP 2.2.2.1 > $my_remote_server: ICMP echo request, id 34981, seq 106, length 64
17:36:53.940624 IP $my_remote_server >  2.2.2.1: ICMP echo reply, id 34981, seq 106, length 64
17:36:54.951407 IP  2.2.2.1 > $my_remote_server: ICMP echo request, id 34981, seq 107, length 64
17:36:54.951444 IP  $my_remote_server: >  2.2.2.1: ICMP echo reply, id 34981, seq 107, length 64
17:36:55.956550 IP  2.2.2.1 >  $my_remote_server:: ICMP echo request, id 34981, seq 108, length 64
17:36:55.956559 IP  $my_remote_server: > 2.2.2.1: ICMP echo reply, id 34981, seq 108, length 64
17:36:56.964876 IP  2.2.2.1 >  $my_remote_server: ICMP echo request, id 34981, seq 109, length 64
17:36:56.964889 IP  $my_remote_server: >  2.2.2.1: ICMP echo reply, id 34981, seq 109, length 64
Here it seems all ok, but if we take a look at the packet sniffer on the CCR (filtered by the $my_remote_server):
00:00:00.000000 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: 192.168.2.1 > $my_remote_server: ICMP echo request, id 34981, seq 400, length 64
00:00:00.000038 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: 2.2.2.1 > $my_remote_server: ICMP echo request, id 34981, seq 400, length 64
00:00:00.000007 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 102: 129.0.0.104 > 2.2.2.1: ICMP type-#188, length 64
00:00:00.022632 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: $my_remote_server > 2.2.2.1: ICMP echo reply, id 34981, seq 400, length 64
00:00:00.980164 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: 192.168.2.1 > $my_remote_server: ICMP echo request, id 34981, seq 401, length 64
00:00:00.000045 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 98: 2.2.2.1 > $my_remote_server: ICMP echo request, id 34981, seq 401, length 64
00:00:00.000005 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 102: 129.0.0.104 > 2.2.2.1: ICMP type-#188, length 64
The following string is weird :? I don't know what is this IP address and it appears only using a device with an IP address in the subnet 192.168.2.0/24
00:00:00.000007 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 102: 129.0.0.104 > 2.2.2.1: ICMP type-#188, length 64
With a telnet it generates an entry like the code below (src port and dst port are ALWAYS the same)
00:00:00.000005 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 82: 129.0.0.104.48293 > 2.2.2.1.1089:  tcp 44 [bad hdr length 0 - too short, < 20]

Any ideas? :D

Re: NAT with Multi-Gateway problems

Posted: Mon May 22, 2017 12:46 pm
by Cyb3r
Bump!

Re: NAT with Multi-Gateway problems

Posted: Mon May 22, 2017 5:22 pm
by almdandi
Your second default route (2.2.2.254) is not active because you already have a default route in your main routing table (1.1.1.254).

The key word is Policy Based Routing. Just google it. In short. You create 2 extra routing tables. One with the default gateway points to 1.1.1.254 and one with the default gateway set to 2.2.2.254. In the Firewall Mangle table you mark the packets with a "routing mark", so this packets will be routed independently.

Re: NAT with Multi-Gateway problems

Posted: Tue May 23, 2017 10:54 am
by Cyb3r
Your second default route (2.2.2.254) is not active because you already have a default route in your main routing table (1.1.1.254).

The key word is Policy Based Routing. Just google it. In short. You create 2 extra routing tables. One with the default gateway points to 1.1.1.254 and one with the default gateway set to 2.2.2.254. In the Firewall Mangle table you mark the packets with a "routing mark", so this packets will be routed independently.
Thank you for your reply.
I've already tryed to add Routing Mark (following this example https://wiki.mikrotik.com/wiki/Policy_Base_Routing) for the second group of addresses, but it doesn't work
I've added the following rules:
ip firewall Mangle add chain=prerouting src-address=192.168.2.0/24 action=mark-routing new-routing-mark=To_VLAN2222
ip route Add dst-address=0.0.0.0/0 gateway="2.2.2.254" routing-mark=To_VLAN2222
Now the default route to 2.2.2.254 shows "active" but the client on the LAN does not work, it cannot ping gateway. If I disable the mangle rules it can ping gateway again (but it does not work).

Re: NAT with Multi-Gateway problems

Posted: Sat May 27, 2017 12:02 pm
by almdandi
I tested it with the following and it worked. And you will run into a private address leak because you only nat ip address up to 20. To avoid this, you could for example, add a rule in your forwarding chain that allows only traffic from your 40 addresses.
/interface ethernet
set [ find default-name=ether1 ] name=ether1-wan
set [ find default-name=ether2 ] name=ether2-wan
set [ find default-name=ether3 ] name=ether3-lan
set [ find default-name=ether4 ] name=ether4-lan
set [ find default-name=ether5 ] name=ether5-mang
/ip address
add address=1.1.1.1/24 interface=ether1-wan network=1.1.1.0
add address=1.1.1.2/24 interface=ether1-wan network=1.1.1.0
add address=2.2.2.1/24 interface=ether2-wan network=2.2.2.0
add address=2.2.2.2/24 interface=ether2-wan network=2.2.2.0
add address=192.168.1.254/24 interface=ether3-lan network=192.168.1.0
add address=192.168.2.254/24 interface=ether4-lan network=192.168.2.0
/ip firewall mangle
add action=mark-routing chain=prerouting in-interface=ether3-lan log=yes new-routing-mark=inet1 passthrough=yes src-address=192.168.1.0/24
add action=mark-routing chain=prerouting in-interface=ether4-lan new-routing-mark=inet2 passthrough=yes src-address=192.168.2.0/24
/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether1-wan src-address=192.168.1.1-192.168.1.10 to-addresses=1.1.1.1
add action=src-nat chain=srcnat out-interface=ether1-wan src-address=192.168.1.11-192.168.1.20 to-addresses=1.1.1.2
add action=src-nat chain=srcnat out-interface=ether2-wan src-address=192.168.2.1-192.168.2.10 to-addresses=2.2.2.1
add action=src-nat chain=srcnat out-interface=ether2-wan src-address=192.168.2.11-192.168.2.20 to-addresses=2.2.2.2
/ip route
add check-gateway=ping distance=1 gateway=1.1.1.254 routing-mark=inet1
add check-gateway=ping distance=1 gateway=2.2.2.254 routing-mark=inet2
add check-gateway=ping distance=1 gateway=1.1.1.254
add check-gateway=ping distance=10 gateway=2.2.2.254