As with all things IT, you will eventually run into problems that you need to correct. In the case of the Cisco VPN, this can be a true challenge since Cisco has so many different ways to handle VPN connectivity, ranging from VPN capabilities included in some routers, to the VPN services offered by PIX firewalls up to the Cisco VPN Concentrator, each has its own quirks. As such, not all of these tips will necessarily pertain to every VPN configuration available from Cisco. However, they will give you a place to start as you work on fixing problems with your VPN.
A user running Internet Connection Sharing is having trouble installing the Cisco 3000 VPN client
This is an easy one to fix. The user needs to disable ICS on his machine before installing the VPN client. I recommend that the user replace ICS with a decent home router with a firewall. Note that this is not necessary if the VPN machine simply connects through another machine that is using ICS. To disable ICS, go to Start | Control Panel | Administrative Tools | Services | Internet Connection Sharing and disable the "Load on Startup" option. In a somewhat unrelated note, make sure users are also aware that the VPN client disables the XP welcome screen and Fast User Switching, which are commonly used on multiuser home machines.
The old standby, [Ctrl][Alt][Del], still works, though, and users will need to type their usernames and passwords instead of clicking a picture of a cat. (Note: Fast User Switching can be enabled by disabling the client's "Start Before Login" feature. This could have its own problems, though, so I wouldn't recommend it unless you really, really need Fast User Switching.)
One more thing regarding the client install – Cisco does not recommend installing multiple VPN clients on the same PC. If you have a problem and need to call support, uninstall other clients and test before making that call.
If you are using shared keys, make sure they match
If you're getting errors in your logs related to preshared keys, you may have mismatched keys on either end of the VPN connection. If this is the case, your logs may indicate that exchanges between the client and VPN server are fine well into the IKE main mode security associations. Some time after this part of the exchange, logs will indicate a problem with keys. On the concentrator, go to the Configuration | System | Tunneling Protocols | IPSec LAN-to-LAN option and select your IPsec configuration. In the preshared key field, enter your preshared key. On a Cisco PIX firewall used in conjunction with the concentrator, use the command isakmp key password address xx.xx.xx.xx netmask 255.255.255.255 where password is your preshared key. The key used in your concentrator and on your PIX should match exactly.
Users running some firewall software are reporting errors when trying to connect to the VPN
Some ports need to be open in firewall software, such as BlackIce (BlackIce has other problems with regard to the Cisco VPN client, too. Refer to the client's release notes for more information), Zone Alarm, Symantec, and other Internet security programs for Windows and ipchains or iptables on Linux machines. In general, if your users open the following ports in their software, you should see a stop to the complaints:
- UDP ports 500, 1000 and 10000
- IP protocol 50 (ESP)
- TCP port configured for IPSec/TCP
- NAT-T port 4500
You may also have custom configured ports for IPSec/UDP and IPSec/TCP. Make sure the ports you configured are also open on the client software.
Home VPN users complain that they cannot access other resources on their home network when the VPN connection is established
This generally happens as a result of split-tunneling being disabled. While split-tunneling can pose security risks, these risks can be mitigated to a point by having strong, enforced security policies in place and automatically pushed to the client upon connection (for example, a policy could require that current antivirus software be installed, or that a firewall be present). On a PIX, use this command to enable split tunneling:
vpngroup vpngroupname split-tunnel split_tunnel_acl
You should have a corresponding access-list command that defines what will come through the encrypted tunnel and what will be sent out in the clear. For example, access-list split_tunnel_acl permit ip 10.0.0.0 255.255.0.0 any, or whatever your IP range is.
On a Cisco Series 3000 VPN Concentrator, you need to tell the device what networks should be included over the encrypted tunnel. Go to Configuration | User Management | Base Group and, from the Client Config tab, choose the Only Tunnel Networks In The List option and create a network list of all of the networks at your site that should be covered by the VPN and choose this network list from the Split Tunneling Network List drop down box.
The user's remote network is using the same IP address range as the VPN server's local network (Client VPN release 4.6 with virtual adapter, Windows 2000/XP)
This is somewhat specific to these particular operating systems, but could be quite frustrating to troubleshoot! Version 4.6 of the Cisco VPN client tries to handle these kinds of IP address conflicts, but isn't always able to do so. In these cases, traffic that is supposed to be traversing the VPN tunnel stays local, due to the conflict.
On the affected client, go to Start | Control Panel | Network and Dialup Connections | local adapter. Right-click the adapter and choose Properties. From the Properties page, choose TCP/IP and click the Properties button. Now, click the Advanced option, find the Interface Metric option and increase the number in the box by 1.This effectively tells your computer to use the local adapter second. The VPN adapter will probably have a metric of 1 (lower than this new metric), making it the first choice as a traffic destination.
Certain router/firmware combinations introduce client VPN connection problems
The Cisco VPN client has problems with some older (and sometimes newer) home routers, usually with specific firmware versions. If you have users with consistent connection problems, ask that they upgrade the firmware in their router, particularly if they have an older unit. Among the router models that are known to have problems with the Cisco client are:
- Linksys BEFW11S4 with firmware releases lower than 1.44
- Asante FR3004 Cable/DSL Routers with firmware releases lower than 2.15
- Nexland Cable/DSL Routers model ISB2LAN
If all else fails, have a spare router on hand to lend to a user to help narrow down the potential problems. Ultimately, the router may need to be replaced.
Users report that the client is terminating when they try to establish a connection
In this situation, users will see an error message is similar to VPN Connection terminated locally by the Client. Reason 403: Unable to contact the security gateway. This error can be caused by a couple of different things:
- The user might have entered an incorrect group password
- The user may not have typed the right name or IP address for the remote VPN endpoint.
- The user may be having other problems with his Internet connection.
Basically, for some reason, the IKE negotiation failed. Check the client logs, enabled by going to Log | Enable, and try to find errors that have Hash Verification Failed to try to further narrow down the problem.
You are having trouble establishing a VPN connection from behind a NAT device or to a VPN server behind a NAT device
This problem can run across all of Cisco's VPN hardware since it's inherent in the way that IPSec worked before the introduction of standards that allowed modification of packet headers during transmission. To correct this problem, enable NAT-Traversal (NAT-T) on your hardware, and allow UDP port 4500 to go through your firewall.
If you're using a PIX firewall as both your firewall and VPN endpoint, make sure to open port 4500, and enable nat-traversal in your configuration with the command isakmp nat-traversal 20, where 20 is the NAT keepalive time period. If you have a separate firewall and a Cisco VPN Concentrator, make sure to open up UDP port 4500 on your firewall with a destination of the concentrator. Then, on the concentrator, go to Configuration | Tunneling and Security | IPSec | NAT Transparency and check the 'IPSec over NAT-T' option.
Further, make sure that any client that is in use on the user end also supports NAT-T. For more information about configuring your series 3000 Concentrator to use NAT-T, click here.
Users successfully establish a VPN connection, but the connection periodically drops
Again, there are a number of places you can check to try to nail down this problem. First, verify that the user's computer did not go into standby mode, hibernate, and that a screen saver did not pop up. Stand by and hibernation can interrupt your network connection when the VPN client expects a constant link to a VPN server. Your user may also have configured their machine to shut down a network adapter after a certain amount of time in order to save power.
If wireless is in use, your user may have wandered to a location with a low (or no) wireless signal, and the VPN might have dropped as a result. Further, your user might have a bad network cable, problem with their router or Internet connection, or any number of other physical connection problems.
There have also been some reports that a VPN endpoint (PIX or 3000 concentrator) that has exhausted its pool of IP addresses may also result in this error on the client, although I have personally never seen this.
A user reports that his machine is no longer "visible" on his local network, even when the VPN client is disabled
Other symptoms may include an inability for any other machines on the user's network to ping the VPN machine even though that machine is perfectly capable of seeing all other machines on the network. If this is the case, the user may have enabled the VPN client's built-in firewall. If this firewall is enabled, it will stay running, even when the client is not running. To change, open the client, and, from the options page, uncheck the box next to the stateful firewall option.