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 were as follows:
- Understand the requirements: What is the solution intended to provide, and to what users, where?
- 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.
- 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.
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.
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.