IP NAT OUTSIDE

Requirements
1) R1 only accepts connections from 172.30.1.0/24 network
2) R2 sees R1 only as 192.168.1.0/24 node (i.e 192.168.1.200)


First starting with basic interface configs

R2#sh run int f0/23 Building configuration... Current configuration : 89 bytes ! interface FastEthernet0/23 no switchport ip address 192.168.1.104 255.255.255.0 end R1#sh run int e0 Building configuration... Current configuration : 88 bytes ! interface Ethernet0 ip address 172.30.1.2 255.255.255.0 ip access-group 101 in end access-list 101 permit ip 172.30.1.0 0.0.0.255 any

NAT_ROUTER#sh run int e0/0 Building configuration... interface Ethernet0/0 description connection to R1 ip address 172.30.1.1 255.255.255.0 ip nat inside ip virtual-reassembly half-duplex end interface Ethernet0/1 description connection to R2 ip address 192.168.1.100 255.255.255.0 ip nat outside ip virtual-reassembly half-duplex end ip nat inside source static 172.30.1.2 192.168.1.200

As you would already noticed R2, is a Cat 3550 switch. We have finished designating the nat inside and outside interfaces. Also notice the access-list 101 on R1 E0 interface permitting only connections from 172.30.1.0/24 subnet. Also notice the static translation 172.30.1.2 ----> 192.168.1.200

Lets verify connection from R2 to R1

R2#ping 192.168.1.200 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.200, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R2#

*Mar 1 03:14:34.587: ICMP: dst (172.30.1.2) administratively prohibited unreachable sent to 192.168.1.104 R1# *Mar 1 03:14:36.587: ICMP: dst (172.30.1.2) administratively prohibited unreachable sent to 192.168.1.104 R1# *Mar 1 03:14:38.587: ICMP: dst (172.30.1.2) administratively prohibited unreachable sent to 192.168.1.104 R1# *Mar 1 03:14:40.587: ICMP: dst (172.30.1.2) administratively prohibited unreachable sent to 192.168.1.104 R1#

Thats right R3 only accepts connections from 172.30.1.0/24 subnet. So lets add the ip nat outside statement on the nat router.

NAT_ROUTER(config)#access-list 102 permit ip 192.168.1.0 0.0.0.255 any NAT_ROUTER(config)#ip nat pool poolout 172.30.1.3 172.30.1.254 netmask 255.255.255.0 NAT_ROUTER(config)#ip nat outside source list 102 pool poolout

Please note that when a source list, which specifies an access-list is used, the outside global address must be matched to an outside local pool, specified by pool keyword. Lets try the test again

R2#ping 192.168.1.200 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.200, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) R2#

Well it's still not working! Let take a closer look at R1 and NAT_ROUTER

*Mar 1 03:21:06.143: ICMP: echo reply sent, src 172.30.1.2, dst 172.30.1.6 R1# *Mar 1 03:21:08.143: ICMP: echo reply sent, src 172.30.1.2, dst 172.30.1.6 R1# *Mar 1 03:21:10.143: ICMP: echo reply sent, src 172.30.1.2, dst 172.30.1.6 R1# *Mar 1 03:21:12.143: ICMP: echo reply sent, src 172.30.1.2, dst 172.30.1.6 R1# *Mar 1 03:21:14.143: ICMP: echo reply sent, src 172.30.1.2, dst 172.30.1.6 R1#

It seems like the NAT_ROUTER translated the outside global address (192.168.1.104) orginating from R2's f0/23 interface is mapped to an outside local address 172.30.1.6 and sent to R1. R1 did reply as indicated the debug ip icmp messages on R1. Obviously the echo reply has not reached R2. Let's examine the NAT_ROUTER

NAT_ROUTER# *Mar 14 21:04:47.547: IP: tableid=0, s=172.30.1.2 (Ethernet0/0), d=172.30.1.6 (Ethernet0/0), routed via RIB *Mar 14 21:04:47.551: IP: s=172.30.1.2 (Ethernet0/0), d=172.30.1.6 (Ethernet0/0), len 100, rcvd 3 *Mar 14 21:04:47.551: ICMP: echo reply rcvd, src 172.30.1.2, dst 172.30.1.6 NAT_ROUTER# *Mar 14 21:04:49.547: IP: tableid=0, s=172.30.1.2 (Ethernet0/0), d=172.30.1.6 (Ethernet0/0), routed via RIB *Mar 14 21:04:49.551: IP: s=172.30.1.2 (Ethernet0/0), d=172.30.1.6 (Ethernet0/0), len 100, rcvd 3 *Mar 14 21:04:49.551: ICMP: echo reply rcvd, src 172.30.1.2, dst 172.30.1.6

The NAT_ROUTER also shows it correctly forwarded the icmp echo reply from 172.30.1.2 (R1) to 172.30.1.6.

NAT_ROUTER#sh ip nat translations Pro Inside global Inside local Outside local Outside global --- --- --- 172.30.1.3 192.168.1.100 --- --- --- 172.30.1.6 192.168.1.104 --- 192.168.1.200 172.30.1.2 --- --- NAT_ROUTER#

As seen from above command, there is a mapping from 172.30.1.6 --> 192.168.1.104 (R2's F0/23 int). However, the traffic was not routed to R2. This because the add-route keyword in the ip nat outside was not configured.

Let's make the change on NAT_ROUTER

NAT_ROUTER(config)#no ip nat outside source list 102 pool poolout NAT_ROUTER(config)#ip nat outside source list 102 pool poolout add-route

Lets test connectivty from R2 again

R2#ping 192.168.1.200 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.200, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/12 ms

So what did the add-route keyword on the NAT_ROUTER do. Well to answer the question, we need to examine the routing table on NAT_ROUTER

NAT_ROUTER#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 192.168.1.254 to network 0.0.0.0 172.30.0.0/16 is variably subnetted, 3 subnets, 2 masks S 172.30.1.3/32 [1/0] via 192.168.1.104 C 172.30.1.0/24 is directly connected, Ethernet0/0 S 172.30.1.7/32 [1/0] via 192.168.1.100 C 192.168.1.0/24 is directly connected, Ethernet0/1 S* 0.0.0.0/0 [1/0] via 192.168.1.254 NAT_ROUTER#sh ip nat translations Pro Inside global Inside local Outside local Outside global --- --- --- 172.30.1.3 192.168.1.104 --- --- --- 172.30.1.7 192.168.1.100 --- 192.168.1.200 172.30.1.2 --- --- NAT_ROUTER#

*The outside local --> Outside global mapping changed because we issued no ip nat pool statement in the previous, which cleared the translations. It has automatically added a host route pointing the outside local address to the outside global address, which was not present before.