Site To Site NAT issue, need one-to-one static mappings

Answered Question
May 9th, 2007
User Badges:

I have a router that NATs for internet access, but also must NAT differently through a VPN tunnel. I know I could use a "pool" of addresses for going through the tunnel, and that worked fine, but I really need "static" mapping of the addresses.


I took out these lines:

ip nat inside source list 110 interface Dialer1 overload

ip nat pool vpn-pool 192.168.4.2 192.168.4.99 netmask 255.255.255.0

ip nat inside source route-map tpi pool vpn-pool


which was assigning us each an address from this pool when routing over the VPN tunnel, and I replaced them with the following:


ip nat inside source list 110 interface Dialer1 overload

ip nat inside source static 192.168.1.5 192.168.4.5 route-map tpi

ip nat inside source static 192.168.1.6 192.168.4.6 route-map tpi

ip nat inside source static 192.168.1.7 192.168.4.7 route-map tpi

ip nat inside source static 192.168.1.8 192.168.4.8 route-map tpi


I do this for each address that is allowed access through the tunnel. Those that don't get mapped won't work.


But it turns out these don't work for some reason. Can anyone tell me why? Can I even do what I want?

Correct Answer by Jon Marshall about 10 years 2 months ago

Hi


Your crypto access-list reads


access-list 112 permit ip 192.168.4.0 0.0.0.255 10.50.200.0 0.0.0.255

access-list 112 permit ip 192.168.4.0 0.0.0.255 10.200.0.0 0.0.15.255

access-list 112 permit ip 192.168.4.0 0.0.0.255 10.53.0.0 0.0.255.255


The first entry of your route-map looks like this


route-map tpi permit 10

match ip address 110


and access-list 110 looks like


access-list 110 deny ip 192.168.1.0 0.0.0.255 10.50.200.0 0.0.0.255

access-list 110 deny ip 192.168.1.0 0.0.0.255 10.53.0.0 0.0.255.255

access-list 110 deny ip 192.168.1.0 0.0.0.255 10.200.0.0 0.0.15.255

access-list 110 permit ip 192.168.1.0 0.0.0.255 any


So what is happening is that traffic that is destined for one of the subnets at the other end of the VPN tunnel, for example 10.50.200.0 is not getting natted to 192.168.4.x because your access-list 110 says deny for this network. Deny in this context means do not do NAT.


If the traffic does not get natted to 192.168.4.x then it will not be sent down the VPN tunnel.


HTH


Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Thu, 05/10/2007 - 02:16
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Could you post the full config minus any sensitive information please.


Jon

Correct Answer
Jon Marshall Thu, 05/10/2007 - 05:33
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


Your crypto access-list reads


access-list 112 permit ip 192.168.4.0 0.0.0.255 10.50.200.0 0.0.0.255

access-list 112 permit ip 192.168.4.0 0.0.0.255 10.200.0.0 0.0.15.255

access-list 112 permit ip 192.168.4.0 0.0.0.255 10.53.0.0 0.0.255.255


The first entry of your route-map looks like this


route-map tpi permit 10

match ip address 110


and access-list 110 looks like


access-list 110 deny ip 192.168.1.0 0.0.0.255 10.50.200.0 0.0.0.255

access-list 110 deny ip 192.168.1.0 0.0.0.255 10.53.0.0 0.0.255.255

access-list 110 deny ip 192.168.1.0 0.0.0.255 10.200.0.0 0.0.15.255

access-list 110 permit ip 192.168.1.0 0.0.0.255 any


So what is happening is that traffic that is destined for one of the subnets at the other end of the VPN tunnel, for example 10.50.200.0 is not getting natted to 192.168.4.x because your access-list 110 says deny for this network. Deny in this context means do not do NAT.


If the traffic does not get natted to 192.168.4.x then it will not be sent down the VPN tunnel.


HTH


Jon

bbiales00 Thu, 05/10/2007 - 05:59
User Badges:

Jon,

Thanks for the info. I think I'm getting closer to figuring this out. I did not setup this router (and have precious little experience with IOS). Usually I just add/change some internet server NAT entries...


I do have a follow up question though...


When this router was ORIGINALLY setup, it routed through the Tunnel with our own private addresses. But due to a conflict with another agency, we are now NATing from 192.168.1 to 192.168.4. But I need to statically assign each machine to a particular address, which the person did not do when configuring the router.


When he recently setup for NAT on the tunnel, he had the following:

ip nat pool tunnel-pool 192.168.4.2 192.168.4.99 netmask 255.255.255.0

ip nat inside source list 110 interface Dialer1 overload

ip nat inside source route-map tpi pool tunnel-pool


Interestingly, with the crypto access-list and the route-map definitions as-is, this worked fine for some reason, the overloaded NAT is used when I hit the internet, and the pooled NAT was used when I hit one of the three private networks listed. But I need to statically assign the NAT addresses, not use a pool, so I expected the static NAT to work when I replaced the pool with the individual NAT statements specifying route-map tpi...


So, my question is this: Using the static NATs as in the previously attached configuration, could I simply change from


route-map tpi permit 10

match ip address 110


To:


route-map tpi permit 10

match ip address 112


?


I'm sure you've nailed where the trouble is. I'm still unsure how to fix it though...


Perhaps you could tell me how to properly setup the crypto, access lists, and route-maps to enable the Tunnel to NAT using one route-map with the commands like:

ip nat inside source static 192.168.1.5 192.168.4.5 route-map tpi


and the overload NAT to work by default for everything else...


Unfortunately it is a production router, and I cannot easily "experiment" with it. Any additional help would be most appreciated!



Jon Marshall Thu, 05/10/2007 - 06:20
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Hi


I understand your reluctance to experiment on a production router. Any changes suggested should be done out of hours just in case.


That said the easy fix would be to remove the first entry in your route-map. So at present your route-map says



route-map tpi permit 10

match ip address 110

!

route-map tpi permit 20

match ip address 111


the problem line is the first entry. Remove the entry


route-map tpi permit 10

match ip address 110


so you should just have the second entry left.


HTH, let me know how it goes


Jon


bbiales00 Thu, 05/10/2007 - 18:59
User Badges:

Well, it took a while... I mistakenly thought that performing a "copy ftp run" would REPLACE the configuration. In the end, I undid things, did them right, performed the "write mem" and suddenly it worked... The only problem I have now is that UDP messages from the other side of the tunnel are not arriving at my client for some reason. The UDP didn't work with the pool, either, perhaps it is a problem on the other router... TCP works both ways, pings work both ways. Not sure why the UDP is failing... Here is the configuration now...

Thanks again for the help!



Attachment: 
bbiales00 Fri, 05/11/2007 - 07:10
User Badges:

My mistake on the UDP, it is all set, thanks again.

Actions

This Discussion