To successfully troubleshoot and resolve VPN issues, you must be organized, methodical, and prepared. Like anything else on your network, the VPN will experience an issue at some point. The preparations you undertake during installation and maintenance will prove to be critical components of your troubleshooting process.

Before you start troubleshooting your VPN issue, have access to the following information:

• A network diagram showing the placement of the VPN and other key network components like firewalls, routers, and switches
• A copy of the current VPN configuration
• Any error, system, or alert logs
• An operations guide
• Maintenance logs and change management records

Now that you have your basic information, you can start troubleshooting. There is no one way to troubleshoot an issue, particularly a VPN issue. What you can do is determine what works best for you, and stick with that process. Some people like to start at the far end and work back to the local VPN server. Others will start at the network level and work their way up to the application. The actual process is not as critical as having an established procedure and sticking with it. Here is one way to tackle this process:

1. Identify the symptoms—Frequently, when dealing with a user-reported issue, the reported item will bear little resemblance to the actual problem. Users tend to generalize with statements like “No one can get on the VPN” or “The intranet is down from the VPN.” You need more specifics before you start correcting an issue. Ideally, you will receive an automated alert from your monitoring system, which generally permits you to track down issues much more quickly than a help desk ticket.
2. Determine the scope of the problem—Know whether your problem is isolated to a single user or system, a workgroup, or the entire network. Do you have one user who cannot connect, 100 users, or the entire company? Not only will this help you get a handle on the urgency of the issue, but it also gives you valuable clues to what the problem might be. If it is one user, the odds are pretty good that it is a client issue, or possibly a network issue on the user’s end, and the help desk can probably assist with the issue. If a large group—but not everyone—is affected, you can look for commonalities. Do all the users belong to the same VPN group? Do they all connect from the same part of the country (indicating that it could be an ISP issue)? If you have multiple VPNs, are the problems all on one VPN?
3. Look for changes—Before you assume something is broken, see if anything has changed. If the issue is with a single user, did the user install a new application like Skype or Tor that could interfere with the VPN? If the VPN is unreachable from the Internet, was someone working on your Internet connection? Did you upgrade any software over the weekend? The importance of formal change management is critical to successfully maintaining a production computing environment. When you are troubleshooting, determine what has changed. Be aware that sometimes the toughest part of chasing down change-related issues in a complex environment is figuring out which of the 20 or 30 changes performed during a weekend change window is causing your problem.
4. Call the vendor—It is never a bad idea to call the vendor to see if it is a known issue. If you do not have phone support with the vendor, visit its website and check its knowledge base. The Internet is an invaluable tool for helping with troubleshooting.
5. Try the most likely solution—As the resident expert, once you have gathered all the information and reviewed the likely issues, try a fix. Record these fixes in your operations guide and in your change control process.
6. Test it—You made a change; test to see if it worked. If not, back out of the change you made and repeat the previous step with the next most likely fix. Repeat the process until the problem is solved. Do not keep trying fix after fix without backing out previous fixes; you could end up making so many changes that you will not be able to easily get back to a stable configuration.
7. Check to see if you broke anything else—This is a critical step. Changes to the environment—even if you are trying to fix something—can have unpredictable effects. The last thing you want is to assume the problem is solved, just to get a call later saying no one can get to the Internet.
8. Document, document, document—This is probably the most important part of the process. If you do not write processes and procedures down, it is as if those procedures were not followed. When the next expert comes along to troubleshoot and your changes are not documented, they will start with incorrect information or guesswork. If you encounter the same problem 12 months later, you will be glad you can refer to your previous process to speed up the second recovery. Create a section in your operations guide just for this kind of documentation.
9. Remember to make a backup—While included in the documentation, be sure to capture any changes to configurations in a backup. A network upgrade or fix for another problem could cause the issue to reoccur. It is much faster to reinstall than to perform a second level of troubleshooting once one item is corrected.

Now that you have a general troubleshooting process, consider some other things when troubleshooting a situation:

• Do not panic—During a major outage, people tend to panic. They will start sending emails to large distribution lists, sending alerts, escalating issues, and doing a variety of other things that are not particularly helpful to you while you are troubleshooting an issue. Keep your cool, work on the problem at hand, and keep management informed of the progress you make.
• Do not overcommit or make promises you cannot keep—If you do not know what the issue is, do not tell your manager or users that the network will be back up in an hour.
• Focus on the problem at hand—Getting sidetracked when troubleshooting a complex issue is easy. Be sure that the problem at hand is the one you are working to address. If you identify other potential issues unrelated to the current outage, document each and plan to correct under your change control process when the outage is over. But do not go off on a tangent and delay addressing the immediate issue.

You can do a few quick and easy tests if you are having a major VPN outage and you just want to be sure that your VPN is still on the network. Generally, your VPN will have two interfaces. One will be accessible from the Internet, and the other will be the connection to your internal network (possibly through a firewall). In the event of a major outage, start by verifying that both of those ports are functioning.

To verify the internal port is available, you can use the ping command from the Windows command prompt or from a UNIX command line. See FIGURE 10-4 for an example of a successful ping response.

Once you have validated the internal port, also validate the external port. This is frequently a challenge because in most organizations, a direct connection to outside the network is not readily available. In some larger organizations, you may have a digital subscriber line (DSL) Internet connection dedicated for testing, but if you do not have that type of access, a number of Internet sites will let you run network diagnostics from their websites. See FIGURE 10-5 for a sample Internet traceroute command from www.network-tools.com. If you do an Internet search on “network tools,” you can find a number of sites that offer a similar capability.

You now have the tools to create your own troubleshooting process for your VPN, using some or all of the steps and tips discussed. You just need to determine what works best in your environment. Be methodical, do not panic, keep focused on the issue, and you will be very successful in quickly addressing VPN issues in your environment.