Troubleshooting Cisco IPsec VPN

This is the third post in the Cisco IPsec series. You can find the first and second here and here. In this post, I will reveal one of the causes of the problems network administrators run into when a new network is to be added to a Cisco IPsec vpn gateway. In my previous post in this series, I shared with us on how to add new networks to an already established Cisco IPsec vpn tunnel. What most of my readers encountered implementing the procedures specified in that post inspired this post. I will like to say however, that the response was highly anticipated. Having added the new subnets as specified, readers discovered that the new subnets could not be reached over the vpn connection. The cause of this is what I want to share with us in this post.

Cisco Ipsec VPN
Image showing sites connected via VPN


I need to emphasize that as good as the intentions of the originators of network address translatio (NAT) were, a good understanding of its workings is required for one to successfully configure IPsec vpn on network devices, especially on Cisco security routers.Since NAT translates private addresses, which coincidentally could be the addresses of hosts to be reached through the vpn tunnel, those addresses have to be exempted from the NAT translation process in a way that it does not affect their connections to the internet. Really? I thought denying these IPs from being translated will automatically stop them from browsing the internet since private addresses are not permitted on the internet? Read on.
The problem: the network admin innocently uses NAT to permit internet access for privately addressed network hosts. While this is the standard procedure, it poses a problem to the working of IPsec vpn.
The solution: use a deny statement in the NAT access list to except end-to-end traffic from the NAT translation process. For example, there are two networks and that need to communicate through IPsec VPN tunnel. A typical NAT statement to allow internet access for hosts on network will be as written below:
R1(config)#ip access-list ext NAT
R1(config-ext-nacl)#permit ip any
R1(config)#ip nat pool R1 netmask
R1(config)#ip nat inside source list NAT pool R1 overload
R1(config)#int f0/0
R1(config-if)#ip nat outside
R1(config-if)#int f0/1
R1(config-if)#ip nat inside
The statements above will translate all IP addresses matched in the access-list called NAT to the IP address specified in the pool called R1. Technically, all IPs from will be translated to as they exit interface f0/0. The problem with this is that interface f0/0 is the same exit interface for vpn traffic going to R3. Since R3 has a policy that instructs it to allow only traffic from going to and vice verse  to pass through the vpn tunnel, this becomes a problem because all traffic from R1 will come with source address of instead of the network. Remember that NAT?
To solve this problem, we must except traffic from the to from the NAT access-list. This way, traffic from the network to other locations, including the internet, will be translated, making sure the users have internet access. See below:
R1(config)#ip access-list ext NAT
R1(config-ext-nacl)#deny ip
R1(config-ext-nacl)#permit ip any
Spread the love

Leave a Comment