They say a picture is worth a thousand words, and I can think of no better example in IT where a screenshot can help troubleshoot an issue with VPN client connectivity. For something so crucial to remote users, it is sad that vendors still make troubleshooting VPN issues something that requires an admin to work with, and familiarity with arcane error messages. It’s a chicken vs. egg scenario, since for an admin to troubleshoot client VPN they need access to the client, which they cannot get until VPN is working! Relying on users to do the heavy lifting guarantees exasperation for both user and admin, but it’s the situation we’re all in. To help troubleshoot VPN client connectivity, here are some pointers that may save you some time.

Outbound connectivity

If a remote user doesn’t have Internet connectivity they are not going to be able to use the VPN. That sounds like an obvious thing, but far too often it is missed. Hotels’ captive portals are often the issue here. Ask the user to open a web browser and go to a website that you know they won’t have cached, like http://www.whattimeisit.com and have them tell you what time it is. If they are prompted to accept the T&Cs or enter their room number, then you know they haven’t Internet access yet.

Depending on the type of VPN you use, there may be a problem getting through the firewall on the required outbound ports and/or protocols. SSL VPNs just need outbound TCP 443. If your user can surf HTTPS websites then they can get out on the required ports for VPN. But PPTP VPNs need both TCP 1723 and IP GRE. Many IPSEC VPNs need UDP 1701 along with IP AH and ESP. Other VPN solutions may need UDP 10000, or other outbound connectivity that the hotel or coffee shop just won’t support. Even with Internet access, not all VPNs will work on all networks. Some guest networks permit web surfing and email protocols, but block everything else, or charge extra for full connectivity. They may be using a simple NAT solution that your VPN cannot work with.

Look for error messages that indicate connectivity issues (see below) and if that’s the problem, work on an alternate network connection.

Permissions

Not all companies provide users with VPN access. Don’t assume that your user is allowed to use VPN unless that is open to all users, and even then you may want to make sure they belong to the right group for access. A quick check of AD can save you a lot of troubleshooting later.

Name resolution

A very wise SysAdmin once said “If DNS ain’t happy, nothing’s going to be happy” and that’s a fact. Make sure that DNS is working, that the client is able to resolve names, and is using the “right” name for your VPN endpoint. Permit ping to that VPN endpoint so that you can easily talk the user through “ping vpn.example.com” both to validate name resolution and some basic connectivity. Just remember some captive portals will still permit ping and DNS while blocking the rest until you accept or pay up.

Client software

VPN client software needs installing, updating and patching just like any other software. If you’re using Microsoft’s built-in client software, Windows Updates will take care of that, and all clients should have VPN capabilities by default. If you are using a third-party solution though, you may need to install the client, or update it if it is already installed.

Username/password

Don’t automatically jump into capturing diagnostic logs and other advanced troubleshooting without first verifying the basics. That includes the user’s credentials. Are they omitting the domain name in their SAM, or using SAM instead of UPN? Do they have their password correct, or is Caps Lock on? It takes 10 seconds to verify that… do so before you spend an hour on a wild goose chase.

Pro tip

Make sure every remote user tests the VPN at least once a month to be sure it is working. For any user hitting the road for the first time, have them confirm VPN before they leave the office, because you don’t want them to find out something is wrong after they depart.

Reference table

Here is a handy table of client VPN error codes for Microsoft’s operating systems. Many of these will be displayed with third party VPN solutions.

Error code	Description	Possible explanation
628/629	The port was disconnected (by the remote machine).	Typically, this is because outbound TCP 1723 is permitted by the client network, but GRE is not. The client starts to make the VPN connection on 1723, outbound GRE is dropped silently, and the server disconnects the client’s TCP session when the LCP negotiation times out. Requires local LAN support to confirm, and to open IP type 47 outbound.
633	The modem (or other connecting device) is already in use or is not configured properly.	You will see this message if you already have one VPN connection active, and try to start another. Ensure that another VPN connection is not already established, and verify network connectivity.
678	There is no answer.	Commonly encountered in hotels and hotspots when a user tries to make a VPN connection but hasn’t agreed to the portal TOS yet, or when only HTTP and HTTPS traffic is allowed out. First, verify user can access websites on the Internet. Then ping the VPN FQDN. Telnet to the VPN FQDN on 1723 or use portqryui to verify connectivity.
692	Hardware failure in port or attached device.	TCP 1723 is blocked, and the firewall sends back a RST/ACK. Consult local network support or switch to SSTP/SSL VPN if available.
711	RasMan initialization failure.	Check for third party software such as IDS/IPS, antivirus software, etc. killing the connection and not notifying the user.
721	Remote PPP peer is not responding.	Check client location firewall… connection was made on TCP 1723 but PPP could not negotiate LCP. Outbound GRE is either dropped silently, or is permitted but the responses are being blocked.
722	The PPP packet is invalid.	Consult network support at client’s location. Fixup PPTP may be enabled on router and killing connections by borking data.
739	The remote server cannot use the Windows NT encrypted password.	Configure client to use MS-CHAPv2 (uncheck SPAP, PAP).
741	The local computer does not support encryption.	Check the client configuration for incorrect settings.
768	The connection attempt failed because of a failure to encrypt data.	Data encryption is required; check settings of manually configured client.
785-793, 798	Various L2TP errors including Smart Cards.	Check client configuration, especially if you are using a preshared key. IPSec encapsulated within UDP requires proper encapsulation setting (remember to reboot if changed).
800	Generic error.	This is the client’s way of saying “Dude, eh?” when something fails but the operating system cannot determine what. Check for third-party software that could interfere with connection attempts.
806	A connection between your computer and the VPN server has been started, but the VPN connection cannot be completed.	The most common cause is a firewall or IPS closing the GRE connection mid-way through negotiation. Check with local LAN support, especially if they are using an IPS, or Checkpoint firewall with smartdefense enabled.
807	The network connection between your computer and the VPN server was interrupted.	Your client got a RST ACK when it tried to connect. Check to see if the firewall is blocking outbound VPN connections.
809	The network connection between your computer and the VPN server could not be established because the remote server is not responding.	Assuming you didn’t just crash the VPN server, nothing is allowed outbound. Contact local network support for the client’s location.
868	The remote connection was not made because the name of the remote access server did not resolve.	Check your DNS. If it is correct, then there is something wrong on the client’s network.

Troubleshooting VPN client connectivity doesn’t have to be a crap shoot. Follow a methodical approach, confirm the basics are in place, and you will usually find, and resolve, the issue in short order.