cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
360
Views
4
Helpful
5
Replies

NAT being bypassed? no translations showing

jeffrey.girard
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

lamav
Level 8
Level 8

"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)

View solution in original post

5 Replies 5

cisco24x7
Level 6
Level 6

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

lamav
Level 8
Level 8

"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)

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.

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

"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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco