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.
