NAT being bypassed? no translations showing

Answered Question
May 21st, 2008
User Badges:

Using a 2621 to try to do simple NAT from two inside interfaces to one outside interface. One interface should be permitted and the other denied. Config below:


Int E1/0

ip address 148.43.10.10 255.255.255.0

ip nat outside

no shut


int fa 0/0

ip address 192.168.110.1 255.255.255.0

ip nat inside

no shut


int fa 0/1

ip address 192.168.210.1 255.255.255.0

ip nat inside

no shut


ip nat inside source list 1 int E1/0 overload


access-list 1 permit 192.168.110.0

access-list 1 deny 192.168.210.0


this does not work. Traffic generated from the 210.0 subnet (ie pings from a laptop) make it out to a test machine on the 148.43.10 network - however Show ip nat translations does not indicate any NAT translations taking place.


I tried changing my ACL to access-list 1 deny any. Pings from both subnets still make it out with no translation being registered. If I change my ACL to access-list 1 permit any, pings make it out, and translations are registered. I tried this on two different 2621s with the same results - so obviously I am doing something wrong.


I have been staring at this for over 3 hours - its probably something really simple


Jeff

Correct Answer by lamav about 8 years 10 months ago

"this does not work. Traffic generated from the 210.0 subnet (ie pings from a laptop) make it out to a test machine on the 148.43.10 network - however Show ip nat translations does not indicate any NAT translations taking place."


Soldier, isn't this result normal? Your 'deny' statement in the NAT ACL is preventing the NAT translation for hosts on the 210 network -- and the fact that you are able to PING the host on the 148 network simply means that your router has a route to it (of course it will, since its a directly connected interface) and that host knows how to get back to the 210 network, which is also a directly connected network.



"I tried changing my ACL to access-list 1 deny any. Pings from both subnets still make it out with no translation being registered."


Same explanation as above. NAT translations prevented, yet traffic is routed to directly connected networks.



"If I change my ACL to access-list 1 permit any, pings make it out, and translations are registered."


Makes sense. The NATing will work because of the 'permit' statement, and of course, the routing is still intact for reasons already explained.


HTH


Victor (US Navy Veteran)



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
cisco24x7 Wed, 05/21/2008 - 17:58
User Badges:
  • Silver, 250 points or more

Please do this:


access-list 100 deny ip 192.168.210.0 0.0.0.255 any

access-list 100 permit ip 192.168.110.0 0.0.0.255 any

ip nat inside source list 100 interface E1/0 oerload


Good Luck!!!


CCIE Security

Correct Answer
lamav Wed, 05/21/2008 - 18:45
User Badges:
  • Blue, 1500 points or more

"this does not work. Traffic generated from the 210.0 subnet (ie pings from a laptop) make it out to a test machine on the 148.43.10 network - however Show ip nat translations does not indicate any NAT translations taking place."


Soldier, isn't this result normal? Your 'deny' statement in the NAT ACL is preventing the NAT translation for hosts on the 210 network -- and the fact that you are able to PING the host on the 148 network simply means that your router has a route to it (of course it will, since its a directly connected interface) and that host knows how to get back to the 210 network, which is also a directly connected network.



"I tried changing my ACL to access-list 1 deny any. Pings from both subnets still make it out with no translation being registered."


Same explanation as above. NAT translations prevented, yet traffic is routed to directly connected networks.



"If I change my ACL to access-list 1 permit any, pings make it out, and translations are registered."


Makes sense. The NATing will work because of the 'permit' statement, and of course, the routing is still intact for reasons already explained.


HTH


Victor (US Navy Veteran)



srue Wed, 05/21/2008 - 19:02
User Badges:
  • Blue, 1500 points or more

I think that this is the expected result also. don't confuse nat acl's with normal interface egress/ingress acl's. the packets exited the router , they just weren't nat'ed.

jeffrey.girard Thu, 05/22/2008 - 03:48
User Badges:

Victor - Thanks for the note. I was under the impression that if an interface had an ip nat inside/outside statement on it, then the packets were required to go through the nat process. In fact, they are - and are being denied. At this point, I would not have expected the routing processor to continue processing the packets as the ACL dropped them. So, under that perception, my 210 subnet should never have left my router. What you describe is different, but obviously correct, in that my 210 subnet would be denied in the NAT portion, but the routing processor would still route the packets out the interface with their original source IPs. That is interesting and something that I did not know.


Thanks!


(See, Army and Navy can get along!)


Jeff

lamav Thu, 05/22/2008 - 05:35
User Badges:
  • Blue, 1500 points or more

"I would not have expected the routing processor to continue processing the packets as the ACL dropped them."


That would be true if the ACL was applied to the interface as a filter that either allows or blocks traffic from entering the interface. If an ACL filter deines traffic, then yes, the packet would not be forwarded. This ACL, however, is only being used within the context of the NAT mechanism as a tool to mark traffic for NATing or its exclusion.


Please note that it's quite common to have a requirement that only certain subnet traffic get NATed while other traffic remain unaltered, hence the practice of leveraging the flexibility of an ACL.


Thanks for the rating.


Victor

Actions

This Discussion