After you understand the entire architecture of a VPN and the services that architecture can provide, your next step is troubleshooting the environment. Networking consultants can use this systematic approach, originally from SearchNetworking.com, to troubleshoot their customers' VPNs.
In my last article, I discussed the 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.
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.
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.
About the author
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 tip originally appeared on SearchNetworking.com.
