cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
429
Views
0
Helpful
2
Replies

NAT behavior in 12.4 - Is this something new or a bug ?

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

2 Replies 2

gmarogi
Level 5
Level 5

NAT doesn't work reliably with extended access lists, try same with a standard access list.

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

Review Cisco Networking for a $25 gift card