VPN troubleshooting 102

In my last article, I discussed the very basics of VPN troubleshooting by setting forth what I consider to be a best-practices approach to troubleshooting any technology. The three main points I made

    Requires Free Membership to View

were as follows:
  1. Understand the requirements: What is the solution intended to provide, and to what users, where?
  2. Understand the deployed solution -- component level: This step allows you to understand what components make up the solution and how those components integrate with other parts of the environment.
  3. Understand the services supported: This is the process of understanding what components (from the above step) provide what services.

I emphasized that this approach should be taken prior to troubleshooting an environment that is outside your expertise (or that you have had limited exposure to). Once you have discovered all of this information, you can then educate yourself on the technology itself. This is a building block approach that provides an excellent foundation for understanding the entire architecture of a VPN, as well as the services that architecture can provide. Your next step is troubleshooting the environment.

Check these items first and foremost on any VPN issue, and nine times out of 10 you'll find your problem.
,
From a troubleshooting perspective, there are three major aspects of a VPN that must be considered: The server or VPN session-termination component, the VPN client and the network infrastructure itself. In most cases the VPN client is software that has to be loaded onto your personal computer, PDA or phone; however, with Secure Socket Layer (SSL), a secure VPN session can be initiated with Web browsers. The network provides the pathway between client and server.

When troubleshooting VPN connections, always ping from the server to the client (or to a device on the same network as the client) in order to insure that there is network connectivity between the client and server. If there is no network connectivity, it doesn't matter what the configurations are. Also, ensure that DNS names are being resolved properly by pinging to the name (e.g. ping www.crisco.com). The name should resolve to an IP address. Please note that the server hands out IP addresses to the client in some cases; if there are not enough IP addresses in the client pool, the client will be denied an IP address. Without an IP address, there is no network connectivity. Now for all intents and purposes, the client and server are configured in order to set up a communication session between the client and the server, prior to the end user being allowed onto the network.

The first thing the server does is prompt the client for authentication credentials. There are many different ways of authenticating between a client and server, but the fact that the credentials on each side must match does not vary. They must always be the same.

The client and server will also need to set up a session using some form of tunneling protocol. This can be SSL, Layer Two Tunneling Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP) or another. Regardless, the client and server must be configured to properly set these up.

More on this topic

VPN troubleshooting 101

Lisa Phifer discusses tunneling protocols in her tip on VPN client alternatives

Chapter download: Troubleshooting Virtual Private Networks, Chapter 6

More VPN tips

Once a tunnel is set up, there may be additional security/encryption capabilities layered on top such as IPsec or a certificate-based encryption. Again, the client and server must be configured identically on each end.

Attention to the details within these areas will solve 99% of VPN problems. Just remember that the client and server are connected over the network, and the client and server have to communicate directly in order for the VPN to work. Keys to the network are IP address allocation, DNS name resolution and IP reachability. Keys to the client /server piece are authentication, tunneling and encryption. Check these items first and foremost on any VPN issue, and nine times out of 10 you'll find your problem.


Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has over ten years of experience providing strategic, business and technical consulting services. Robbie resides in Atlanta, and is a graduate of Clemson University. His background includes positions as a Principal Architect at International Network Services, Lucent, Frontway and Callisma.

This was first published in February 2006

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.