Static NAT subnets with route-map

diondohmen · ‎09-02-2008

Hi there,

I am having a problem implementing the route-map argument with the static nat statement:

ip access-list extended COSMIC-MATCH

permit ip 10.0.0.0 0.255.255.255 18.0.0.0 0.255.255.255

route-map COSMIC permit 10 match ip address COSMIC-MATCH

ip nat inside source static network 10.0.0.0 53.0.0.0 /8 route-map COSMIC

Basically, what I want to accomplish is a static subnet nat translation from between 10.0.0.0 and 53.0.0.0

But I only want some specific conversations to be NATted, so I added a ACL in combination with a route-map, to specifiy the traffic to be NATted.

When I test the conversations specified in the ACL, the NAT process does add the translation, but only as fasr as the classufll bits count, 10.0.0.0 in this case. Show ip nat translations shows us the following:

R019#show ip nat translations

Pro Inside global Inside local Outside local Outside global

icmp 53.x.x.1:1024 10.0.0.0:1024 18.0.0.2:1024 18.0.0.2:1024

--- 53.0.0.0 10.0.0.0 --- ---

Apparently it translates 53.61.35.1 to 10.0.0.0 instead of 10.61.35.1

When I leave the route-map out of the ip nat inside statement, all works just fine:

R019#show ip nat translations

Pro Inside global Inside local Outside local Outside global

icmp 53.61.35.1:1024 10.61.35.1:1024 18.0.0.2:1024 18.0.0.2:1024

--- 53.0.0.0 10.0.0.0 --- ---

But now, all traffic gets NATted. Using ip nat pools is also no solutions, because the conversation must be able to be initiated from both sides, not dynamically.

Does anyone have any experience in using route-maps with static subnet translations?

Thanks!

Marwan ALshawi · ‎09-08-2008

ur config generally looks good

except the ACL ithink ur problem with the ACL

ip access-list extended COSMIC-MATCH

permit ip 10.0.0.0 0.255.255.255 18.0.0.0 0.255.255.255

make it more spisific like

10.61.35.0 0.0.0.255

good luck

if helpful Rate

diondohmen · ‎09-08-2008

thanks for your reply.

I have investigated this a bit more in the past few days, and It appears to me, that this specific static nat with route-maps feature, is behaving differently in some IOS releases.

The last succesfull test i did, was with the use of the "extendable" keyword in the NAT statement:

ip nat inside source static network 10.0.0.0 53.0.0.0 /8 route-map COSMIC-NAT extendable

after implementing this in my config, the specific ip connections, did get NATted the correct way, and not just the first 8 bits. All this sounds not clear to me, and I think they have to further investigate this issue.

Marwan ALshawi · ‎09-09-2008

hi Dion

u have done it right and this is 5 points :)

and this is the answer for the config u have done:

Typically, the ip nat inside source static command is used to translate a small number of entries between your network and two other networks. However, this command provides one interesting parameter: extendable. This parameter causes the Cisco IOS to create an extended translation entry in the translation table instead of a simple entry

example, internal has two Internet connections for redundancy. ISP1 has assigned an IP address space of 192.1.1.0/24. ISP2, which does not support ISP1's address space, has assigned 193.1.1.0/24 to this network. This poses a problem because you need to set up a static translation for the internal web server. Normally, a static statement allows only one translation. In this example, you must choose between 192.1.1.1 translated to 10.0.0.1, or 193.1.1.1 translated to 10.0.0.1 for the web server translation.

Using the extendable parameter, however, you can associate more than one global address with a local address

if helpful Rate