04-12-2007 03:18 AM - edited 03-05-2019 03:25 PM
I have observed a new behavior of NAT in 12.4.10b; for packets coming infrom outside to inside and if a dynamic NAT entry exists in the nat translation table for the destination address (inside local) of packets coming into the router from outside, the communication does not work. If there is no NAT entry in the NAT translation table, the communication from outside to inside works fine.
Here is sample config;
Router with NAT configured
Serail 1/0
ip nat inside
ip address 10.1.12.2 255.255.255.0
Serial 1/1
ip nat outside
ip address 10.1.23.2 255.255.255.0
ip nat pool test 100.1.1.1 100.1.1.254 netmask 255.255.255.0
ip nat inside list 101 pool test
ip access-list 101 permit ip host 11.11.11.11 host 22.22.22.22
ip route 22.22.22.22 255.255.255.255 10.1.23.3
ip route 11.11.11.11 255.255.255.255 10.1.12.1
ip route 0.0.0.0 0.0.0.0 10.1.23.3
(Outside world is aware of 11.11.11.11 ip address that outside world is aware of inside local ip address as well)
symptoms
- 11.11.11.11 can connect to 22.22.22.22 without any problem and NAT inside to outside happens fine and translates 11.11.11.11 to 100.1.1.1
-Above connectivity create NAT table entries
-With the presence of NAT table entries in NAT Cache, if some other IP address from outside tries to connect to the inside local iP address 11.11.11.11, the communication does not work and I see that NAT is kicking in and translation 11.11.11.11 to 100.1.1.1; I do not understand as why this is happening because the configuration of NAT and access list 101 are not applicable to the session initiated from outside to inside.
Further I simulated the similar scenario using 12.2 IOS and no issues at all. Outsider are able to talk to talk to inside local ip without any problem.
Does anyone knows if this is a new NAT beahivor after 12.2 or does this sounds like a BUG
04-18-2007 05:58 AM
NAT doesn't work reliably with extended access lists, try same with a standard access list.
04-18-2007 06:31 AM
Thanks for your response, I agree and found out that the issue is because of using ACL Further I found out following very good CISCO document which outlines very clearly as why I observed this issue. Once a NAT entry is created in the NAT table using Access list, packets are not matched against Access list for Nating, they are Nated right away using NAT entry in the NAT cache and this is eaxctly what I saw happening there. The solution is to use a route-map which causes creation of extended NAT entries and avoid such issues; here the link
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080093fca.shtml
Thanks a lot
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide