cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
612
Views
0
Helpful
3
Replies

Nat with route-maps

brett.curtis
Level 1
Level 1

I had a nat configuration that worked under 12.4-15T, and now it doesn't seem to be working under 15.0(1)M8.  I needed to translate an inside address to two different global static addresses depending on the route-map.  This worked bidirectionally.  In the config below, if  I telnet to 192.168.48.6, I get the router.  The access-list and route-map have no hits, and the nat translation table is blank for the 10.10.10.10 192.168.48.6 entry.  I'm not getting any nat with traffic source of 192.168.50.5 destination 192.168.48.6.  Is there some reason why this wouldn't work in 15.0? That's the main question.  I struggled with this a lot to get it to work initially.  Is there a better alternative?

Here is a simplified summary of the relevant config:

interface loop 0

ip address 192.168.48.6 255.255.255.255

int faste 0

ip address 192.168.49.6 255.255.255.0

ip nat outside

int faste 1

ip address 192.168.15.1 255.255.255.0

ip nat outside

int faste 2

ip address 10.10.10.1 255.255.255.0

ip nat inside

ip route 0.0.0.0 0.0.0.0 192.168.15.2

ip route 192.168.50.0 255.255.255.0 192.168.49.254

ip nat inside source static tcp 10.10.10.10 80 interface FastEthernet1 80

ip nat inside source list inside-NAT-list interface FastEthernet1 overload

ip nat inside source static 10.10.10.10 192.168.48.6 route-map tunnel-map

ip access-list extended inside-NAT-list

deny   ip any 192.168.50.0 0.0.0.255

permit ip 10.10.10.0 0.0.0.255 any

ip access-list extended tunnel-map

permit ip host 10.10.10.10 192.168.50.0  0.0.0.255

!

route-map tunnel-map permit 10

match ip address tunnel-map

3 Replies 3

Richard Burts
Hall of Fame
Hall of Fame

It looks to me that the problem is in the access lists used. The ACL used to control translation through FA1 is

ip access-list extended inside-NAT-list

deny   ip any 192.168.50.0 0.0.0.255

permit ip 10.10.10.0 0.0.0.255 any

and the access list used by the route map is

ip access-list extended tunnel-map

permit ip host 10.10.10.10 192.168.50.0  0.0.0.255

So the host address permitted in the second ACL is included in the subnet permitted in the first ACL. If the translate checks the first ACL and gets a match then it will not look at the second ACL. Perhaps changing the first ACL would solve your issue

ip access-list extended inside-NAT-list

deny   ip any 192.168.50.0 0.0.0.255

deny  ip host 10.10.10.10 192.168.50.0  0.0.0.255

permit ip 10.10.10.0 0.0.0.255 any

HTH

Rick

HTH

Rick

A source of 10.10.10.10 destination 192.168.50.x is denied in the inside-NAT-list before it ever gets to the permit.  Once it's denied, the acl look up is over.  It never gets to the permit. That's why I put that in there.  Without that, you're right.  It won't work.  

This worked before in 12.4.  I think it has to do with the outside to inside features and NAT reversible key word that appear to have been added in 15.0.  For example I see in the documentation that outside to inside may not even work for a static nat entry, even though it will accept the reversible keyword.

I also tried this by putting the loop interface address into a nat pool and re-writing the nat referencing the pool with the reversible key word.  It still didn't work. 

It definitely fails outside to inside, and it used to work bi-directionally.  I need to do a test here in the lab to see whether it works inside to outside, and then to verify that the software version is really the culpret.

You are correct that the source 10.10.10.10 destination 192.168.50.0 is denied in inside-NAT-list. I missed that. My apologies. I do not see other obvious issues. If it worked on an earlier version of code and does not work on the more recent version of code then it does sound like a behavior change in the code.

HTH

Rick

HTH

Rick