Problems with Policy Based NAT - cannot get it right
hi out there
I need to be able to nat a DMZ-zone on a router to circumwent some routing problems - we have a new dmz which has to be isolated from the main Network but has to be natted into the same ip Space
I expected that this was a simple task by defining a route-map and assig this route-map to the incoming interface which then would take the traffic from that vlan and loop around a loopback-interface to get it through a nat-outside interface.
This Work also to some extend - when I ping I can see that my nat-statement Works as expected - but when the reply is send back it is drpped in the router somewhere.
I ping from R1 to R3 with source ip from lo0 (192.168.10.1) and try to get it natted around lo2 on R2 where F0/0 is inside of nat and lo2 is outside - I expected this to be fairly simple because the concept is used in f.ex "lollipop" or "router on a stick" - but I cannot get it right - it is being correct natted as far as I can see but the reply packet from R3 doesn't hit the correct return path - it is dropped somewhere in R2
the config of my nat-router is fairly simple:
version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname R2 ! boot-start-marker boot-end-marker ! ! no aaa new-model memory-size iomem 5 ip cef ! ! ! ! no ip domain lookup ip domain name lab.local ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 ! ! ! ! ! interface Loopback2 ip address 192.168.20.1 255.255.255.0 ip nat outside ip virtual-reassembly ! interface FastEthernet0/0 ip address 188.8.131.52 255.255.255.0 ip nat inside ip virtual-reassembly ip policy route-map To_loop2 duplex auto speed auto ! interface FastEthernet0/1 ip address 184.108.40.206 255.255.255.0 duplex auto speed auto ! ip forward-protocol nd ip route 192.168.10.0 255.255.255.0 220.127.116.11 ! ! no ip http server no ip http secure-server ip nat inside source list 1 interface Loopback2 overload ! access-list 1 permit 192.168.10.0 0.0.0.255 access-list 100 permit icmp any any time-exceeded ! route-map To_loop2 permit 10 match ip address 1 set interface Loopback2 ! !
When a do a ping with source ip 192.168.10.1 - entering the router on f 0/0 the following happens:
yes - had it just been that simple - but - I had i default route pointing to R2 so this should bot be the problem - why it claims that it is non-routeable I cannot say but if we go to R3 and issue a ping from there:
R3#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 18.104.22.168 to network 0.0.0.0
192.168.30.0/32 is subnetted, 1 subnets C 192.168.30.1 is directly connected, Loopback3 22.214.171.124/30 is subnetted, 1 subnets C 126.96.36.199 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 [1/0] via 188.8.131.52 R3#sh ip int bri Interface IP-Address OK? Method Status Protocol FastEthernet0/0 184.108.40.206 YES NVRAM up up FastEthernet0/1 unassigned YES NVRAM administratively down down Loopback3 192.168.30.1 YES NVRAM up up R3#ping 192.168.20.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 32/47/76 ms R3#
so - hmm - anyone tried to re-create the setup and seen same problems? I can post the actual configs from GNS3 if anyone want to try - should be a fairly simple setup - which seen from my point of view should work.
Tried it with Ios 12.4.something and 15.1 just to verify if there has been something odd changed - but no difference.
best regards /Ti
ps: just tried to disable cef on R2 just to be sure that it wasn't related to this - no difference
btw - the previous test might not be so useable at all - more interesting would be to ping from R2 Agains R3 with source ip of the loopback interface used for NAT:
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 24/31/44 ms R2#ping 18.104.22.168 so lo 2
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 22.214.171.124, timeout is 2 seconds: Packet sent with a source address of 192.168.20.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/23/36 ms R2#
See this Works fine - why doesn't my PBR NAT then not Work?
When I ping from R1 with source of loop1 against R3 126.96.36.199 adresse the packet is correct translated as far as I can see in wireshark but it is not translated back on the nat interface
If I debug on R2 and look on nat I get this when I ping from R1 to R3 R2# *Mar 1 00:15:31.731: NAT:  Allocated Port for 192.168.10.1 -> 192.168.20.1: wanted 5 got 5 *Mar 1 00:15:31.735: NAT: i: icmp (192.168.10.1, 5) -> (188.8.131.52, 5)  *Mar 1 00:15:31.735: NAT: s=192.168.10.1->192.168.20.1, d=184.108.40.206  R2# *Mar 1 00:15:33.775: NAT: i: icmp (192.168.10.1, 5) -> (220.127.116.11, 5)  *Mar 1 00:15:33.775: NAT: s=192.168.10.1->192.168.20.1, d=18.104.22.168  R2# *Mar 1 00:15:35.731: NAT: i: icmp (192.168.10.1, 5) -> (22.214.171.124, 5)  *Mar 1 00:15:35.735: NAT: s=192.168.10.1->192.168.20.1, d=126.96.36.199  R2# *Mar 1 00:15:37.747: NAT: i: icmp (192.168.10.1, 5) -> (188.8.131.52, 5)  *Mar 1 00:15:37.751: NAT: s=192.168.10.1->192.168.20.1, d=184.108.40.206  R2#sh ip nat t *Mar 1 00:15:39.775: NAT: i: icmp (192.168.10.1, 5) -> (220.127.116.11, 5)  *Mar 1 00:15:39.779: NAT: s=192.168.10.1->192.168.20.1, d=18.104.22.168  R2#sh ip nat tra R2#sh ip nat translations Pro Inside global Inside local Outside local Outside global icmp 192.168.20.1:5 192.168.10.1:5 22.214.171.124:5 126.96.36.199:5 R2# *Mar 1 00:16:40.199: NAT: expiring 192.168.20.1 (192.168.10.1) icmp 5 (5) R2# R3 is correctly replying on it:
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...