Wednesday, December 24, 2008

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.



No comments: