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.
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 192.168.10.0/24 and 192.168.20.0/24 that need to communicate through IPsec VPN tunnel. A typical NAT statement to allow internet access for hosts on network 192.168.10.0/24 will be as written below:
R1(config)#ip access-list ext NAT
R1(config-ext-nacl)#permit ip 192.168.10.0 0.0.0.255 any
R1(config-ext-nacl)#exit
R1(config)#ip nat pool R1 192.168.1.1 192.168.1.1 netmask 255.255.255.252
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
R1(config-if)#
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 192.168.10.0/24 will be translated to 192.168.1.1 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 192.168.10.0/24 going to 192.168.20.0/24 and vice verse to pass through the vpn tunnel, this becomes a problem because all traffic from R1 will come with source address of 192.168.1.1 instead of the 192.168.10.0 network. Remember that NAT?
To solve this problem, we must except traffic from the 192.168.10.0/24 to 192.168.20.0/24 from the NAT access-list. This way, traffic from the 192.168.10.0/24 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 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
R1(config-ext-nacl)#permit ip 192.168.10.0 0.0.0.255 any
