Cisco VPN connects but cannot access inside resources

I ran into an issue recently where I was configuring a new Remote Access VPN. The Cisco VPN client would connect successfully. However, I could not access any resources on the LAN behind the firewall.

The termination point was an older PIX 515 running IOS 8.0. I was using the latest version of the Cisco VPN Client software, which was running on Windows 8.1.

In my particular case I had the following line in my config:

NO CRYPTO ISAKMP NAT-TRAVERSAL

This line was singlehandedly preventing me from accessing internal LAN resources. To fix this, I entered the following commands:

CRYPTO ISAKMP NAT-TRAVERSAL 30

What this line does is allow VPN users, who are connecting from behind their own firewall, to traverse multiple levels of NAT and reach the remote inside subnet.

The numeral of 30 is the keep-alive value and is specified in seconds. The default is 20 and can be set as much as an hour.

You may need to disconnect and reconnect your VPN client for this to take effect.

It is rare that this command will be set to NO. So, I thought I would list some other common causes for this problem.

The first thing to check is that your VPN client is receiving an IP Address. Run IPCONFIG from a command line on the problem workstation. It should be receiving an IP address and subnet mask from the IP LOCAL POOL you specified. If not check the attributes on your remote-access tunnel-group. You should see a line that says something like this.

ADDRESS-POOL <name of your IP LOCAL POOL>

If not, be sure to add it.

Note: That it is best practice to have your VPN clients receive an IP address from a subnet different than your inside subnet.

Next, make sure your NAT statements are present and correct. Your configuration should have a line that reads something like this:

NAT (inside) 0 access-list <name of access-list>

Normal NAT statements will have a numeral “1” after the interface name. These are networks that will receive network address translation. However, in our example, we have a numeral “0”. This means that everything in our access-list will not be translated.

From here, check the access-list that the NAT statement referenced. It should have a PERMIT statement, allowing VPN traffic to access the internal LAN. You should have one that reads something similar to this:

ACCESS-LIST <name of access-list> extended permit ip <internal net> <internal mask> <VPN net> <VPN mask>

For example:

ACCESS-LIST NoNAT extended permit ip 192.168.1.0 255.255.255.0 192.168.199.0 255.255.255.0

As long as you have an access-list, are applying that with a NAT statement, NAT traversal is turned on, and you are receiving an IP address, you should be able to browse resources behind the inside interfaces.

As always, would love to hear from you. So, if there is anything else that could be a common cause for Client VPN traffic not flowing be sure to leave a comment!