Cisco Static NAT with route-maps

Question

Update:

Seems that route maps only match on IP addresses, not on the ports. Had another situation this week on a different device, model and software version. Ended up changing the NAT statements to:

ip nat inside source static tcp 192.168.1.20 3389 x.x.x.x 3389

I then restricted access based on an ACL rather than a route map. Would have been nice to define conditional NATing, but it seems it just doesn't work.

---

So we have a pretty standard NAT box setup to offer a hosted NAT solution for a number of customers.

Here is the basic topology:

Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)

The issue I have is to do with the route-map section of the NAT statements.

ip nat inside source static tcp 10.1.10.201 22 x.x.x.x 22 vrf Customer1-vrf route-map Customer1-portforwarding extendable

ip access-list extended Customer1-forwarding-acl
 permit tcp host 10.1.10.201 host a.a.a.a eq 22
 permit tcp host 10.1.10.201 host b.b.b.b eq 22

route-map Customer1-portforwarding permit 10
 match ip address Customer1-forwarding-acl

I believe I have the understanding of the route-map correct. It is meant to designate what is allowed to NAT and what isn't. I am basically trying to set it up to allow only translations from specific public source addresses. It doesn't seem to be doing that. It seems to be permitting translations from any public address.

I changed the ACL completely to a 'deny ip any any' statement and it still permits. I'm at a bit of a loss. It appears the route-map isn't doing anything.

Any help would be greatly appreciated!

Cheers,

H

Answer 1

i believe that the problem is in the VRF configuration itself , so please check the next
1. configure 'ip vrf forwarding Customer1-portforwarding' under interfaces involved in NAT (nat inside,nat outside interfaces)
2. if your access list will use the VRF routing table so you need to add 'set vrf Customer1-portforwarding' command under route-map configuration to make use of theVRF routing table
3. make your route-map more specific by set next hop
4. verify NATing by use 'sh ip nat translation' command

make use of those URLs
NAT over VRF
Route-map over VRF

Answer 2

I realize this post is old but I wanted to follow up on this one, just in case you have this issue hanging out there.

Just curious if the IP address you are trying this NAT on, outside global, is also on the same VRF as the client. If so, you may want to try: match-in-vrf

ip nat inside source static tcp 10.1.10.201 22 x.x.x.x 22 vrf Customer1-vrf route-map Customer1-portforwarding match-in-vrf

I would also try two other methods: 1.) modify your ACL for the route-map, to have the same source as the IP you want to NAT them too. If we read left to right on the NAT rules it may not analyze this until after the translation occurs. 2.) try ip nat outside source static tcp... I'm not sure which one would work but it'd be good to see a debug like the following:

access-list 99 permit host 10.1.10.201
access-list 99 permit host x.x.x.x
!
debug ip nat 99
!
terminal length 0
!
show log

Answer 3

Try removing port 22 from:

ip nat inside source static tcp 10.1.10.201 22 x.x.x.x 22 vrf Customer1-vrf route-map Customer1-portforwarding extendable

Answer 4

In the NAT statement you are indicating the SOURCE port is 22 on the internal address, yet on your ACL you put the "eq 22" on the DESTINATION side. Try either removing "eq 22" from your routemap ACL entirely, or put it on the correct side (source) to match your NAT statement.

Answer 5

It appears that the route map has some issues. I wasn't able to troubleshoot further.