Cisco IOS (2901) - Nat pool overload not working on VPN tunnel

[jim.downie2]

Hello,

I am trying to make a VPN tunnel work as if all traffic sent down it is coming from a single IP address (the external address of the router).

This is working correctly for the first connection (nat pool is utilised and traffic flows down tunnel correctly), however all subsequent connections fail - it looks like the nat pool overload is not working correctly.

I have attached my config file (sensitive details removed) - the VPN tunnel is on access-list 141 and the nat pool overload uses access-list 140.

As far as I can see all is setup correctly - where have I gone wrong or will this setup just not work correctly and I need to setup a range of IP addresses for the nat pool?

Thanks,

Jim.

[Jon Marshall]

Jim

I can't see anything obviously wrong and you have blanked out some IPs but some of the configuration is a little confusing so perhaps I am not seeing the full picture ie. -

1) acl 140 has a remark "External_NoNAT_VPN" and there is a corresponding route map as well but the route map doesn't seem to be used and the acl is actually used in a NAT statement.

Just makes me wonder if there are any typos or missing information ?

2) if you want to translate all the 192.168.x.x IPs to the outside interface IP for this tunnel why are you using a NAT pool using that IP when this line -

ip nat inside source route-map VPNs interface GigabitEthernet0/1 overload

should do the job for you as long as the acl the route map references doesn't exclude the VPN traffic ie. just make sure the VPN traffic is matched by the following line in that acl -

permit ip 192.168.12.0 0.0.3.255 any

No criticism intended, just trying to get the full picture and to be honest even if you left the NAT as is it should work, but I was just wondering if using the same IP for both the pool and the general overload was somehow conflicting.

If I have misunderstood then please clarify.

Jon

[jim.downie2]

Thanks Jon for getting back to me

Originally I was using a route map to activate the nat pool overload - this was changed to an access-list directly (route map was not removed but is now redundant).

The other change is that for the VPN tunnel traffic I am now using access-list 142 (not 141 as stated in the opening discussion) - sorry for confusion.

So the manipulation of traffic should be:

Access-list 140 modifies source IP address to 1.1.3.197 for traffic with destination 10.10.16.0/24

Access-list 142 tunnels traffic down VPN tunnel.

relevant lines listed below:

crypto map VPNS 141 ipsec-isakmp
 set peer <removed>
 set transform-set AES-SHA
 set pfs group2
 match address 142

ip nat pool VPN_External_Nat 1.1.3.197 1.1.3.197 prefix-length 30
ip nat inside source list 140 pool VPN_External_Nat overload
ip nat inside source route-map VPNs interface GigabitEthernet0/1 overload
!
ip access-list extended vpn_nonat
 deny   ip 192.168.12.0 0.0.3.255 10.10.16.0 0.0.0.255
 permit ip 192.168.12.0 0.0.3.255 any
!
access-list 140 remark External_NoNat_VPN
access-list 140 permit ip 192.168.12.0 0.0.3.255 10.10.16.0 0.0.0.255
access-list 142 permit ip host 1.1.3.197 10.10.16.0 0.0.0.255

route-map VPNs permit 20
 match ip address vpn_nonat

[Jon Marshall · Accepted solution]

Jim

My point was that your NAT pool is using the interface IP address which is the same as your general internet access traffic.

So could you not just remove this from your vpn_nonat acl -

deny   ip 192.168.12.0 0.0.3.255 10.10.16.0 0.0.0.255

then the VPN traffic would match this line from the same acl -

permit ip 192.168.12.0 0.0.3.255 any

which is what you want ie. you want your source IPs for the VPN traffic to be translated.

Then you wouldn't need the NAT pool configuration

You usually do need to exclude VPN traffic from NAT but you don't want to do that for this specific VPN.

I'm not saying it will fix the issue but I can't see anything else wrong with your configuration and I was just wondering if having a NAT pool using the same IP as the outside interface was perhaps causing a problem.

Jon

[jim.downie2]

Jon,

Naming may be confusing but this route map is used to control what internal traffic is nat'd for access to the internet - all deny entries are used to force traffic down a VPN tunnel.

The permit ip 192.168.12.0 0.0.3.255 any is used to access the internet.

Removing the deny clause would cause the traffic to traverse to the internet and not down the VPN tunnel (based on my understanding).

Jim.

[Jon Marshall]

Jim

Removing the deny clause would cause the traffic to traverse to the internet and not down the VPN tunnel (based on my understanding).

No it wouldn't.

All that route map is doing is deciding which traffic to NAT or not, it doesn't dictate the destination of the traffic.

Once the source IPs are translated to the outside interface IP then the route table is consulted as to the destination IP and you have a default route pointing via the outside interface.

You also have a crypto map applied to the outside interface.

So for this specific VPN the source IPs are translated to the outside interface then they are routed to the outside interface using the default route and then the packets match the crypto map and are sent down the VPN tunnel.

If you were not translating the source IPs for this VPN what you say is right but you are in this case.

Jon

[jim.downie2]

Jon,

I removed the deny statements in the "ip access-list extended vpn_nonat" and you were correct - the traffic went down the VPN tunnel.

Unfortunately I am still experiencing the same issue - first connection works all subsequent attempts on the overload fail (they are marked as misses on the ip nat statistics and the allocation sticks at 100% - would have expected the allocation to increase if it was working). See ip nat statistics below.

Jim.

ciscoS7#show ip nat statistics
Total active translations: 2337 (0 static, 2337 dynamic; 2337 extended) Peak translations: 11147, occurred 09:06:52 ago Outside interfaces:
  GigabitEthernet0/1
Inside interfaces:
  GigabitEthernet0/0
Hits: 1514584951  Misses: 0
CEF Translated packets: 1501288920, CEF Punted packets: 9477971 Expired translations: 20914629 Dynamic mappings:
-- Inside Source
[Id: 15] access-list 140 pool VPN_External_Nat refcount 1  pool VPN_External_Nat: netmask 255.255.255.252
    start 80.71.3.197 end 80.71.3.197
    type generic, total addresses 1, allocated 1 (100%), misses 391
[Id: 16] route-map VPNs interface GigabitEthernet0/1 refcount 2245

Total doors: 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

[Jon Marshall · Accepted solution]

Jim

I think it's still using the NAT pool from the output above.

When you removed the acl entry did you also remove the NAT pool configuration ?

Jon

[jim.downie2]

Bingo - removal of the nat pool from the setup allowed all traffic to go down the VPN tunnel with the external IP address.

Many thanks,

Jim