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

Answered Question
May 9th, 2007

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?

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 9 years 7 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

Hi

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

Jon

Correct Answer
Jon Marshall Thu, 05/10/2007 - 05:33

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

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

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

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: 

Actions

This Discussion