My lab environment runs on GNS3 and I noticed a behavior that wasn't mentioned anywhere else, so I decided to post my findings here
We have the following topology.
No routing protocols running between the routers. We need to ping R3 router from R2 and the opposite, only by using NAT on R1.
Initial Configurations
R2 interface Ethernet0/0 ip address 20.0.0.2 255.255.255.0 R3 interface Ethernet1/1 ip address 30.0.0.3 255.255.255.0 R1 interface Ethernet0/0 ip address 20.0.0.1 255.255.255.0 ip nat inside interface Ethernet1/1 ip address 30.0.0.1 255.255.255.0 ip nat outside ip nat inside source static 20.0.0.2 30.0.0.2 ip nat outside source static 30.0.0.3 20.0.0.3
R1#sh ip nat tran Pro Inside global Inside local Outside local Outside global --- --- --- 20.0.0.3 30.0.0.3 --- 30.0.0.2 20.0.0.2 --- ---We start by pinging R3 from R2, so R1 performs Inside to Outside NAT translation. As we expected, ping is successful and correct addresses are displayed in the console of each router
R2#ping 30.0.0.3 rep 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 30.0.0.3, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 6/6/6 ms R2#
R3# *Feb 28 14:39:58.928: ICMP: echo reply sent, src 30.0.0.3, dst 30.0.0.2, topology BASE, dscp 0 topoid 0 R3#
R2# *Feb 28 14:39:58.931: ICMP: echo reply rcvd, src 30.0.0.3, dst 20.0.0.2, topology BASE, dscp 0 topoid 0 R2#
Now let's try the opposite. We ping R2 from R3, so R1 performs Outside to Inside NAT translation.
R3#ping 20.0.0.2 rep 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds: . Success rate is 0 percent (0/1)
R2# *Feb 28 14:40:34.232: ICMP: echo reply sent, src 20.0.0.2, dst 20.0.0.3, topology BASE, dscp 0 topoid 0 R2#
We see that ping fails, although the packet can reach R2. That means there must me an error in the return path. We enable "debug ip nat" and "debug ip packet" on R1 and retry pinging R2 from R3, trying to find the cause of the failure.
R1# *Feb 28 14:46:40.686: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, Virtual Fragment Reassembly(33), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.686: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, Virtual Fragment Reassembly After IPSec Decryption(49), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.686: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, NAT Outside(76), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.686: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, MCI Check(90), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.687: NAT: s=30.0.0.3->20.0.0.3, d=20.0.0.2 [24] *Feb 28 14:46:40.687: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), len 100, output feature, NAT Inside(8), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.687: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), len 100, output feature, NAT ALG proxy(59), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.687: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), g=20.0.0.2, len 100, forward *Feb 28 14:46:40.688: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), len 100, sending full packet *Feb 28 14:46:40.692: IP: s=20.0.0.2 (Ethernet0/0), d=20.0.0.3, len 100, input feature, Virtual Fragment Reassembly(33), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.692: IP: s=20.0.0.2 (Ethernet0/0), d=20.0.0.3, len 100, input feature, Virtual Fragment Reassembly After IPSec Decryption(49), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.692: IP: s=20.0.0.2 (Ethernet0/0), d=20.0.0.3, len 100, input feature, MCI Check(90), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.692: IP: tableid=0, s=20.0.0.2 (Ethernet0/0), d=20.0.0.3 (Ethernet0/0), routed via RIB *Feb 28 14:46:40.692: IP: s=20.0.0.2 (Ethernet0/0), d=20.0.0.3 (Ethernet0/0), len 100, output feature, NAT Inside(8), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 14:46:40.693: IP: s=20.0.0.2 (Ethernet0/0), d=20.0.0.3 (Ethernet0/0), len 100, rcvd 3 *Feb 28 14:46:40.693: IP: s=20.0.0.2 (Ethernet0/0), d=20.0.0.3, len 100, stop process pak for forus packet R1#
If we check the debugs carefully, we notice that there is only one line mentioning NAT. We see NAT info only in line #5. It triggers only in the direction from R3 to R2 and there is no trigger in the return direction. That leads us to research for the reason. Looking toward the bottom of the debug output we notice line #13
*Feb 28 14:46:40.692: IP: tableid=0, s=20.0.0.2 (Ethernet0/0), d=20.0.0.3 (Ethernet0/0), routed via RIB
We see that R1 believes 20.0.0.2 and 20.0.0.3 are on the same interface/segment, so there is no reason to perform any NAT action
And what is the solution? As mentioned in several blogs and docs, it is a matter of order of operations and you can solve it by adding a static route for 20.0.0.3 pointing toward R3 and R1. There are two possible ways to add that static route. Of course you can add the static route yourself, or you can use the "add-route" knob in the "ip nat outside" command. Any of these should have the same result.
So, let's pick the "add-route" option and see what happens
R1# conf t
R1(config)# ip nat outside source static 30.0.0.3 20.0.0.3 add-route
R1(config)# do sh ip route | b Gateway
Gateway of last resort is not set
20.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 20.0.0.0/24 is directly connected, Ethernet0/0
L 20.0.0.1/32 is directly connected, Ethernet0/0
L 20.0.0.3/32 is directly connected, Ethernet0/0 <========
30.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 30.0.0.0/24 is directly connected, Ethernet1/1
L 30.0.0.1/32 is directly connected, Ethernet1/1
L 30.0.0.2/32 is directly connected, Ethernet1/1
As you can see above there is no static route for 20.0.0.3. But we notice a connected route, which probably overwhelms our static route.
And this is where things are getting different from anything I've read online. I started thinking where could this static route come from and I remembered the alias option of the "ip nat inside/outside" command.
Whenever you perform NAT, the device by default installs aliases for the involved IP addresses and you can verify that with the command "sh ip alias"
R1#sh ip alias Address Type IP Address Port Interface 20.0.0.1 Dynamic 20.0.0.3 <======== Interface 30.0.0.1 Dynamic 30.0.0.2 <========So, why not use the "no-alias" knob to see what happens? We modify out NAT statements on R1 to include the "no-alias" option and check the result.
R1# conf t
R1(config)# ip nat inside source static 20.0.0.2 30.0.0.2 no-alias
R1(config)# ip nat outside source static 30.0.0.3 20.0.0.3 no-alias add-route
R1(config)# do sh ip alias
Address Type IP Address Port
Interface 20.0.0.1
Interface 30.0.0.1
R1(config)# do sh ip route | b Gateway
Gateway of last resort is not set
20.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 20.0.0.0/24 is directly connected, Ethernet0/0
L 20.0.0.1/32 is directly connected, Ethernet0/0
S 20.0.0.3/32 [1/0] via 30.0.0.3
30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 30.0.0.0/24 is directly connected, Ethernet1/1
L 30.0.0.1/32 is directly connected, Ethernet1/1
Now our routing table seems ok, so let's retry pinging R2 from R3
R3#ping 20.0.0.2 rep 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds: ! Success rate is 100 percent (1/1), round-trip min/avg/max = 7/7/7 ms
R2# *Feb 28 15:19:09.776: ICMP: echo reply sent, src 20.0.0.2, dst 20.0.0.3, topology BASE, dscp 0 topoid 0
R3# *Feb 28 15:19:09.778: ICMP: echo reply rcvd, src 20.0.0.2, dst 30.0.0.3, topology BASE, dscp 0 topoid 0As you can see, the ping is successful and the debug output depicts the NAT operation in both directions.
R1# *Feb 28 15:19:09.772: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, Virtual Fragment Reassembly(33), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 15:19:09.772: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, Virtual Fragment Reassembly After IPSec Decryption(49), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 15:19:09.772: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, NAT Outside(76), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 15:19:09.773: IP: s=30.0.0.3 (Ethernet1/1), d=20.0.0.2, len 100, input feature, MCI Check(90), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 15:19:09.773: NAT: s=30.0.0.3->20.0.0.3, d=20.0.0.2 [39] *Feb 28 15:19:09.773: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), len 100, output feature, NAT Inside(8), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 15:19:09.773: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), len 100, output feature, NAT ALG proxy(59), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE *Feb 28 15:19:09.774: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), g=20.0.0.2, len 100, forward *Feb 28 15:19:09.774: IP: s=20.0.0.3 (Ethernet1/1), d=20.0.0.2 (Ethernet0/0), len 100, sending full packet *Feb 28 15:19:09.777: NAT*: s=20.0.0.2, d=20.0.0.3->30.0.0.3 [39]After all this research I'm not sure if all this is normal behavior or it appears only in the IOS release/platform I'm running. If anyone can verify my findings are correct, I'd be more than happy to know..
No comments:
Post a Comment