First, familiarize yourself with the recommendations, guidelines, and procedures that will allow you to manage your VPN securely, efficiently, and as cost effectively as possible. These techniques and recommendations are known collectively as "best practices" and are generally developed and published or shared by experts in the field. VPNs have been around since the late 1990s. That means a significant amount of "real world" experience is available in the industry for your reference.

A "best practice" is generally not a tool, but rather the collected wisdom of fellow security practitioners sharing what they have learned. One of the great things about working in the information security field is that a large pool of experts are generally willing to share their experience. Be warned, however: Security experts tend to have very strong opinions, so any time you are reviewing a best practice, be sure to keep the needs and requirements of your own environment in mind. A process that works great in a 25,000-person global manufacturing company may not work nearly as well in a 50-employee medical records processing company.

That said, you might well be able to adapt a process from another company to fit your environment. The key to getting the most out of best practices is to consider them with your specific environment and requirements in mind. Keep what works, modify what you can adapt, and ignore what doesn't make sense. After some time in the business, you will be the person other people come to for advice.

Provide redundancy, because everything, including VPNs, can break. If your organization will be relying on your VPN for remote access, encrypting, and securing data, or for providing a business partner access to your extranet, you will find out quickly how critical your VPN has become on the day it breaks. Most commercial VPN products offer a fail-over or load-balancing capability, so that in the event one device fails, the other will pick up the traffic.

Alternatively, keep a spare VPN product on your shelf, configured and ready to go live in the event of a failure. Generally, waiting for tech support or ordering a spare part can take more time than your organization is willing to wait for restored service. You'll learn more on this later in the chapter.

Choosing the right VPN product is critical to the long-term success of your VPN deployment. Take your time, document your requirements, carefully evaluate the capabilities of each VPN product you review, check with peers if available, and review appropriate industry literature. A security magazine review of VPN products is a valuable tool for starting your search—or even narrowing the field once you have your requirements documented—but don't select your solution solely based on who won last year's Editor's Choice Award from your favorite industry magazine. While the editors and reviewers at most industry magazines, Web sites, and blogs are technically capable and spend a lot of time looking at products, they don't have to support the product in your environment. Ultimately, you will be responsible for meeting your organization's requirements and maintaining support.

Beware the vendor with the slick PowerPoint presentation offering a free lunch. "Slideware" is not reality; avoid purchasing products based on promises rather than proven capabilities. Slideware, also sometimes known as "vaporware," is any product that appears in a vendor's PowerPoint presentation, but is not yet available as one of their products. When possible, road-test a product in your environment before purchasing. It's always a good idea to see what a product can do first hand.

Finally, when looking for a product, consider using resellers and consultants. A good reseller can do some of the legwork for you by narrowing the search to a smaller pool of products. While some resellers work much like a standard department store, selling whatever is on the shelves, many will go the extra mile to ensure you get a product that will work in your environment. This saves them the challenge of trying to support a poor product after they've sold it, and if you like the solution, they have the opportunity to sell you additional products in the future.

A VPN policy (often referred to as a Remote Access Policy) documents your organization's rules for using the VPN. We will discuss creating a VPN policy at length later in the chapter; recognize, however, that proper policy framework is a key best practice when dealing with security technologies, especially one offering remote access to your computing environment.

The client is a critical component of your VPN solution. For the most part, VPN technology is both mature and secure. VPNs are subject to Denial of Service (DoS) attacks, but VPN servers are rarely hacked. Nevertheless, VPNs remain a viable vector for someone who wants to attack your network. The target of these attacks is typically the weakest link of the VPN chain—the client. A typical VPN client runs an operating system that needs to be patched at least once a month, runs applications that may need to be patched almost as often, and is vulnerable to viruses, spyware, and other attacks. Be sure to install antivirus software, anti-malware software, and a software firewall on every client that will be connecting to your network through the VPN.

Split tunneling is a configuration setting that allows simultaneous access to both an untrustworthy network (like the Internet) and a secured VPN network connection. This may not sound like a bad idea at first—after all, why wouldn't you want someone connected to the VPN to access the Internet or their home network (or another network) at the same time? The reason split tunneling is a bad idea is that it potentially opens a door into your network that you can't control.

If the client machine is compromised by a virus that permits remote control of the system by an attacker, and that client machine connects to the VPN, the attacker now has access to your internal network from anywhere on the Internet. If you prohibit split tunneling, then, even if the attacker can compromise the client, as soon as the VPN connects, the external connections terminate, ensuring your network is secure, even if the client is not.

If it doesn't belong to the company, it shouldn't connect to the company's network. One of the challenges of working with Remote Access VPNs is making sure that the client at the other end of the connection is secure. Remote Access VPNs permit access to a secure network from a remote location across an untrustworthy network. If the client system is not secure, you run the risk of compromising your secure network.

Fortunately, you have some control over your organization's computers. You can require antivirus, anti-malware, IDS, and firewall software on any computers your company owns. With systems not owned by the organization, you cannot require anything. As a result, if you don't prohibit non-company systems from connecting to the network, you cannot control whether those systems are secure, meaning you can't ensure that your network remains secure. It's very easy for an end user to load a VPN client on a home PC and connect to your network. While some VPN solutions offer techniques to prevent uncontrolled systems from successfully connecting, it's important that you lay the groundwork by prohibiting the practice.

Effective vulnerability management can help manage your remote clients. These are the technology and business processes used to identify, track, and mitigate known weaknesses on hosts within a computing environment.

Remember, everything is vulnerable to attack. UNIX, Windows, routers, network printers, and even your VPN solution will have vulnerabilities. Examples of vulnerabilities include software coding errors, improper configurations, and poor password choices. The danger with a VPN is that it expands your network from systems you can closely control to include systems in a home office, a branch office, a hotel, a Starbucks, or even a business partner's network.

Vulnerability management is a combination of tools and processes that allow you to reduce risk in your computing environment, including VPN-connected systems and networks. Use tools that periodically test your environment, including the VPN systems, for missing patches, configuration issues, known exploits, and other vulnerabilities. This will ensure that your remote systems as well as your local systems are secure. Scan often and address issues when you find them.

Your VPN is only as secure as your authentication method. One of the easiest ways to compromise a VPN is by compromising the authentication credentials. All it takes is one user with a password of "password" to open a direct connection to your network. A best practice is to use two-factor authentication for VPN access. This is a method of proving identity using two different authentication factors. Authentication factors are something you know, something you have, or something you are. Examples include a smart card (something you have) with a PIN (something you know); a biometric device (something you are) coupled with a password (something you know); or a proximity card (something you have) that activates a fingerprint reader (something you are).

If you fail to plan, you plan to fail. Document your implementation plan! You can't simply find an open rack in the data center, run a cable, plug in a device and keep your fingers crossed that it will work. Document your implementation and support plans. You'll learn more on this later in the chapter.

Monitoring the availability of the VPN can be a lifesaver. The typical (and worst) method to discover issues with your VPN is when users start calling for help. This can be particularly challenging when the callers include members of your organization's senior management team. A corollary of Murphy's Law may be, "The likelihood that a senior management team member will be trying to access the network over the VPN is directly proportional to the likelihood that the VPN will fail." Better to alert senior management of temporary problems than to be informed by them that something isn't working. Since VPNs are network components, you can generally use the same monitoring equipment that you use to monitor routers, switches, and other network gear.

Once you have your VPN deployed, regularly review usage. When you notice employees who are not using the VPN, you may want to remove their access. If you see employees who have multiple concurrent connections, you may have a security issue, and should investigate further.

Backup your VPN configuration regularly. This is a good practice for any network equipment, but in the event your VPN hardware fails and needs replacement, you'll want to be able to restore your known working configuration quickly. Rebuilding a VPN configuration from the default settings can be a long and challenging task—not to mention making post-incident review meetings an unpleasant experience.

Patch regularly. Vendors typically release patches and updates to VPN code throughout the life of the product. These patches address security issues, fix bugs, or provide additional functionality. In an ideal environment, you will have a development VPN that you can use to test patches and updates. In most environments, you will not have the luxury of a development VPN and will have to test when you implement in production. In either circumstance, work closely with your vendor to make sure you receive prompt notice of patches and updates, and establish an operational process and maintenance window to apply patches and updates in a timely fashion.

Your VPN solution may end up being a critical component of the organization's business continuity planning and disaster recovery planning. In the event of an incident that prevents employees from getting to their work location, a VPN that provides work-from-home is a key component of many recovery plans. Events such as earthquakes, snowstorms, tornadoes, flooding, and other natural disasters can make working remotely a viable alternative to standard operations.

This collection of VPN management best practices is meant to serve as the starting point for your successful VPN deployment. It's not meant to be comprehensive, but instead to offer some common practices and processes to help you with your VPN deployment. Depending on your VPN solution, your environment, your business requirements, and your experiences, you may find that you will use every one of these—or use only a few. The key is to ensure that you are doing what works in your environment. If you need help, don't be afraid to reach out to your peers for advice and suggestions. You will find, over time, that you will develop your own set of best practices as you gain more experience as a security practitioner, and soon others may be asking you for advice.

If you are implementing or supporting a VPN solution, use a VPN policy to ensure your users understand the requirements for computing on the VPN. A VPN policy is sometimes called a Remote Access policy, a term used when dial-up lines and modems were the primary means to access the network remotely. Keep in mind that a VPN policy should be a part of your overall policy framework, and not a standalone. If you try to develop your VPN policy in isolation from the overall policy framework, you may find that you are duplicating information, or potentially writing VPN policy that conflicts with other aspects of your overall policy framework. For example, if you put a requirement in your VPN policy that user passwords must be 10 characters long and the password policy says they have to be eight characters long, you will confuse end users.

The components of a solid VPN policy include:

Some specific topics to include in your VPN policy are:

Have your policy reviewed and approved by your Communications, Legal, and Human Resources Departments before release. Document the appropriate approvals in the document status portion of the policy, then communicate the policy to your employees. Posting the policy to an information security or security policy intranet Web site is a common practice. Once it's available on the intranet, you can use standard communications methods to make employees aware of the policy requirements. These methods can include e-mail, a structured awareness program, inclusion in new-hire training, or even Web-based or in-person policy training. The method you select will be based on your organizational size, locations, and requirements. They key with any type of awareness training is to structure your communications to the correct audience. A group of engineers will require a very different introduction to a technical policy than a sales team might.

These are just some of the factors in developing a VPN policy for your organization. While they should form the basis for the development of your organization's policy, be sure to cover all applicable requirements. One sure way to alienate your employees is by releasing a policy that either makes no sense to them, or that you have to revise too soon to cover things you didn't think of the first time through. Take your time, consider all the requirements, and you will end up with a usable VPN Policy.

Now that you have an understanding of best practices and VPN policy, you'll look at how to select, place, and use a VPN.

The pros and cons of the different types of VPNs will be discussed in more detail in Chapter 12.

Consider these criteria during your search:

Once you have gathered this information, you can start to narrow your selection based on how well these features meet your criteria.

Next, consider where you will deploy the VPN on your network. Three common architectures typically accompany VPN solution deployments.

Bypass Deployment

A bypass architecture (see Figure 11-1) deploys the VPN so that traffic to the VPN and from the VPN to the internal network is not firewalled in any way.

This was a common architecture when VPNs were first introduced to the market. The logic behind this deployment architecture is that the since the VPN will accept only encrypted connections on a specific port, the security is adequate without additional firewalling. An additional consideration is that the since the traffic is encrypted, it doesn't require additional protection. Even if you did place a firewall on the Internet-facing VPN connection, the firewall would not be able to analyze the encrypted VPN traffic. This architecture also considers anyone connected to the VPN as a trusted host. Finally, passing traffic across a firewall always causes concerns about performance impacts and justifiably so..

Two significant issues arise with this implementation model. First, VPNs are like any network device—they can have a variety of vulnerabilities. As a result, they are still vulnerable to an attack against the device itself. The second issue is that the uses for VPN have expanded greatly since the technology first appeared, and it's not uncommon in today's environment to leverage a VPN to provide untrustworthy hosts access to portions of the network. These could be customers accessing an order management portal, vendors supporting systems on the internal network, or suppliers who are transferring invoices to your internal systems. While some controls (usually routing table-related) are available in most VPN solutions, terminating a VPN directly on your internal network is a very dangerous practice. As a result, the circumstances where a bypass VPN architecture is still a viable solution are limited, unless your risk tolerance is pretty high.

Figure 11-1.  A bypass VPN implementation.

Figure 11-2.  An internally connected VPN.

Consider the threats and attacks against your VPN, and how to mitigate them. A VPN can be a critical component of your information security infrastructure. A properly implemented VPN addresses a number of common attacks against your infrastructure, including eavesdropping, man-in-the-middle, replay, and others. However, while your VPN can mitigate attacks, it can also opens up an entirely new set of security issues.

Remember VPNs are essentially network devices and subject to many of the same security issues you would find in a router or a switch. If you are running a software VPN, then your VPN can have many of the issues you find on your network's servers.

A hardware VPN solution can suffer from a number of security vulnerabilities, including:

One of the most common and easily exploited vulnerabilities on any hardware network device is the default password. Vendors set an initial password on their equipment and usually all it takes to discover this password is a quick search on the Internet. Usually it's not even particularly hard to guess. Try the vendor name, "admin," or "password," and your odds are good that you'll be able to login. It seems like a sensible mechanism—the vendor doesn't want to distribute their equipment without a password, so they set a standard password that's easy for the installer to remember.

The potential problem occurs when the installer forgets to change that password. It's not uncommon for an installer to leave the password in place for the duration of the installation. Typing in "admin" after each reboot is much easier than typing in "$$Th!s!sAS3cur3P@ssw0rd!!" every time after making a change requiring a reboot. The problem occurs when either the installer forgets to change the password when the work is done, or an attack occurs while the installer is in the middle of the installation.

Imagine the installer has a couple of additional settings to change, but it's 6:00 p.m. on a Friday and he's ready for the weekend. He decides to come in early Monday to finish up the configuration. So for the entire weekend, the VPN you're counting on to provide secure access to your network is on the Internet with the password "admin." The best way to address this type of vulnerability is through stringent system configuration procedures and strong awareness training for your support staff or contractors. Disciplinary action when an installer fails to follow the instructions is remarkably effective at getting the message across.

The second common issue with hardware VPNs is a device that is installed in the default configuration. Very few network devices will come out of the box in a fully secure configuration. For example, important configuration setting we discussed was disabling split-tunneling. A default VPN configuration might not disable that setting without modifying the configuration. If you are completing your first install, it's very tempting to just change enough of the configuration to get the VPN up and running and stay away from any unfamiliar settings.

A related issue occurs when an inexperienced installer modifies the configuration without understanding the impact of the changes. For example, an installer with a limited understanding of encryption protocols might decide that using the DES algorithm for VPN encryption would be "good enough" and would improve performance over a higher encryption algorithm like 3DES. The installer probably read somewhere that the longer the key length used for encryption, the higher the impact on performance. This is often true, but longer key lengths usually mean more secure communications. Installer-induced security threats are some of the hardest to track down. Since they were caused by someone with a limited understanding of what he or she is doing, the installer's ability to help you track down the issues is equally limited.

To mitigate the risk of these issues, make sure that you train your installer (or yourself) before installing the VPN. If you do not have the time or justification for training on the product, then engage a vendor or systems integrator to either assist with the install, or even complete it for you. Once the installation goes online, it pays to have an expert perform a vulnerability or penetration test against your VPN. It never hurts to have an expert check your work.

A software VPN solution can suffer from the following vulnerabilities:

While software VPN solutions are not typical in corporate environments, they are not uncommon in smaller organizations, academic environments, and other areas where a hardware VPN did not meet the business requirements. The main threats to software VPN solutions arise in the operating system. Operating systems like UNIX or Microsoft Windows consist of highly complex coding. They are designed to support a number of business-related tasks, and are more highly complex than the operating systems found on hardware-based VPNs. As a result, the software-related threats can also be much more complex.

Operating systems contain millions of lines of software code, and as with anything written by people, they always contain mistakes. Those mistakes are what attackers seek to exploit when attacking an operating system. Exploits may include buffer overflows, privilege escalation, or any number of other issues. As a result, if you run your VPN on a general-purpose operating system, your VPN becomes susceptible to the same software vulnerabilities as your operating system. In addition, software VPNs have many more possible operating system configuration errors than hardware VPNs.

Some organizations run VPN software on a server that supports multiple applications. For example, the VPN server might also be a SQL server, a Web server, or a file server. If this is the case in your environment, be aware of potential vulnerabilities created by application conflicts. This could be a matter of two applications that contend for resources on the servers causing issues, but it could also be the chance that one of the applications opens a new vulnerability in the VPN software. Think about a VPN server that is also a Web server. If the Web server is configured incorrectly, you could expose VPN configuration files to an attacker through the Web server interface. In that event, you could configure your VPN server securely just to have an attacker pull a copy of your configuration files out of a Web directory, bypassing your security.

Another potential threat associated with software VPNs is stability. Many information security professionals are reluctant to run software VPNs due to the challenges of the operating system crashing and taking the VPN with it. Many security professionals wouldn't ever want to run a VPN that could be taken out by a "Blue Screen of Death"—the nickname for the Microsoft server crash screen.

Finally, operating systems are vulnerable to viruses and other forms of malware. These would include Trojan horses, rootkits, or any of the other destructive malware currently active on the Internet. Any of these infections could compromise the security of your VPN, as well as your internal network.

If you are planning to run a software VPN, be sure to run it on a dedicated server, double-check both the operating system configuration, as well as the VPN configuration, and keep the operating system fully patched and up-to-date. When your VPN is fully configured, run a vulnerability management tool against it, or have a professional come in and conduct a penetration test. Moreover, be sure to install and maintain current antivirus and anti-malware software on the server. It's a good idea to install a firewall application and an intrusion detection/prevention application to ensure that your VPN remains secure.

Vulnerabilities common to both hardware and software VPN implementations include:

In a Denial of Service (DoS) attack, the attacker is trying to crash or overload the VPN, essentially, to deny access to the VPN service. Attackers use specially crafted packets designed to crash the VPN, or more likely, direct a flood of traffic at the VPN in an attempt to overload it. This is not a very common attack because of the large amounts of traffic required to overload most companies' network infrastructures. Generally, you will not see a VPN targeted with a DoS, as attacks against VPNs are typically designed to allow the attacker access to the internal network. DoS is more common is against popular Web sites like Twitter or Facebook, where there is significant publicity, or against online merchants, who are subject to blackmail. When your Web site is a significant source of revenue, a DoS attack can be very expensive.

Any hardware or software platform that can run VPN software is vulnerable. That's the nature of any computer technology. When these vulnerabilities are discovered, the vendor will typically develop a patch or an update to address the issue. If you do not keep your VPN current, you leave your network open to these issues, and attackers will try to exploit known vulnerabilities with your VPN.

A backdoor account attack is pretty rare, but can happen in some instances. An example of the traditional backdoor attack was featured in the movie War Games, where the system developer left a user account and password on a secure system in case he needed to get back in. This account was exploited by an attacker (in the movie, a kid just looking to play games)—nearly causing the end of the world. Needless to say, the issues in your environment will not be quite as dramatic, but they are still of concern. Code running on VPNs and operating systems is closely scrutinized, so system developers are less likely to be a threat, but what about a system administrator who thinks he's about to be fired? Or a vendor who comes in to support your VPN and creates an account for support that he or she forgets to delete before leaving? The best way to mitigate this type of attack is through scheduled auditing of all accounts on your VPN, as well as strong, documented procedures for how and when accounts are created and deleted. This particularly applies to accounts with elevated privileges or on systems accessible from the Internet.

One of the trickiest (and fortunately rarest) security threats is an unpublished vulnerability in the VPN code. Researchers or potential attackers can discover an unpublished vulnerability. If it's unpublished, it means the vendor is not yet aware of it, and thus has not yet developed a patch or an update. These are probably the most difficult threats you will face because there isn't a lot you can do beyond following security best practices, creating a layered security environment, and monitoring the behavior of your environment for anomalies. Should you encounter this issue, be sure to follow your incident response process and work with the vendor to identify the issue and create a patch.

Another vulnerability is not directly on the VPN, but is vulnerability in the devices connecting to the VPN. VPNs offer significant security advantages, but if the client at the other end of the connection is not secure, then your network is at risk. To mitigate this risk, have a standard client configuration, which includes antivirus, anti-malware, firewall, and maybe even intrusion-detection software. Also make sure that the only clients connecting to the VPN are company-owned. Permitting personal assets to connect to your network opens a number of additional issues, since you are not able to supervise the configuration of those systems. All it takes is one employee whose daughter clicks on the video link that her friend sent her (generally with a comment like "check out this video I took of you") and you could end up with a virus on your network when Dad connects to the VPN using the same system.

A final vulnerability to consider is the challenge of weak authentication. Your VPN is really only as secure as your authentication mechanism. If you are authenticating with user ID and password, you run the risk of someone guessing or stealing those credentials and accessing your network without permission. To mitigate this risk, rely on either token-based or biometric authentication methods instead of—or in addition to—a user ID and password. If you must use user ID and password for authentication, be sure to coach users in the use of strong passwords.

A familiarity with the various threats, attacks, and mitigations is critical to the long-term support of your VPN and your total network. Be aware that no list of threats and attacks can be all-inclusive, because the attackers are constantly contriving for new methods for compromising your network. In the absence of specific threats and attacks, rely on good security practices to keep things safe.

When looking at VPN solutions, decide if you want to include the option to leverage open-source VPNs. If so, be aware of some of the tradeoffs you will encounter when leveraging an open-source VPN product.

A commercial solution offers the following benefits:

The benefits of an open-source solution include the following:

Both commercial and open-source solutions pose some challenges. Commercial solutions are typically easier to implement, but that ease of installation comes at a cost. Not only are commercial solutions more expensive than open-source solutions, but also they are typically less flexible. Open-source solutions like OpenVPN (www.openvpn.net) offer significant flexibility, but generally require significantly higher skill in installation and support of the product. You rarely have access to vendor support, as open-source solutions usually rely on the knowledge of the user and the development community. When you have an issue, you can normally post it on a discussion board, and the community will assist you in resolution of your issue.

While weighing the pros and cons of open-source VPN solutions, take into account a couple of other factors. First, many organizations have policies about the use of open-source software. These policies derive from the company's tolerance for risk, the open-source licensing agreements, and intellectual property implications of open source. If your organization embraces open source, an open-source VPN is probably worth considering.

The best VPN application still comes down to identifying your requirements and finding the best solution for your organization. If you're on a low budget or have access to solid technical resources, an open-source solution could be the best choice for your needs.

Much of the information in this chapter has dealt with VPNs deployed in support of an enterprise or at least a moderate-to-large network. Another class of VPN applications—the personal or individual VPN—is sometimes referred to as the small-office or home-office VPN solution. Many home routers will include support for VPN connections, and open-source VPNs are also very popular in this space. Shrew Soft (www.shrew.net) offers an open-source VPN client that will connect to many of the standards-based VPN gateways like OpenSWAN (www.openswan.org). The value of these personal VPNs is twofold. First, implementing a personal VPN provides you secure access to your home network. Even better, implementing a personal VPN provides you with some valuable experience with VPNs that you can then transfer to your organization's enterprise VPN.

A key concept to understand about VPN technologies is the difference between anonymity and privacy. Anonymity is the ability for a network or system user to remain unknown. Some tools that support anonymous access include Tor (www.torproject.org), an open software and network to anonymously surf the Web. A hardware solution that leverages the Tor network for anonymity is JanusVM (www.janusvm.com). The problem with solutions for anonymity is that they don't always protect your privacy. In many cases, the traffic carried anonymously by these applications is unencrypted, which means an attacker can read it with access to the right part of the network. If you are passing user IDs and passwords, credit card numbers, or other information that you would like to keep private, these are not the correct solutions for you.

Privacy, on the other hand, is keeping information about a network or system user from being disclosed to unauthorized people. If you want to protect your information, a VPN connection does an excellent job of this by encrypting the data that it carries. Leverage VPNs whenever you are connected to an untrustworthy network and want to send sensitive information. Wireless networks are a particularly ripe environment for attackers trying to get private information from a public network. VPNs do not offer any anonymity, however, as you are always able to track the endpoints of a VPN connection—that information is needed to maintain the VPN connection.

One of the design decisions you made when selecting your VPN was whether you needed a highly available solution. Once your users expect to access the network from a hotel, a customer location, or Starbucks, or from home when they have a sick child, you will find they have little tolerance for outages. A VPN down means none of your remote workers can do much work, and in some organizations that can mean a majority of the company could be off the network until the VPN is back up and running. A highly available solution makes a lot of sense.

The most common method for implementing a highly available VPN is pretty simple. You buy two VPN hardware units (or implement two open-source VPNs) and then configure them as a highly available pair using the vendor's high-availability mechanisms. Cisco offers the Hot Standby Router Protocol (HSRP) for example, which allows configuration of a pair of Cisco VPNs so that in the event that the primary VPN fails, the backup takes over seamlessly. If configured correctly, end users don't even notice the cutover. A more industry-standard protocol that offers similar functionality is the Virtual Router Redundancy Protocol (VRRP). You also have the option to use a third-party solution. Many of today's load balancers offer the ability to load-balance VPNs. When one VPN fails, the load balancer automatically directs all traffic to the remaining gateway.

In addition to ensuring your VPN is highly available, also ensure that your Internet circuits have similar redundancy. You don't want to end up with your VPN up, and your one Internet connection down. The net result is still unhappy users who cannot access the network. In the event of circuit outages, the user will typically need to reconnect to the VPN. This is still better than not being able to connect at all.

When you are considering a highly available VPN solution, be sure to consider not only the acquisition costs, but also the ongoing maintenance costs over the following three to five years. It's important to capture the full cost of the solution, rather than just the purchase price.

Now that your VPN is up and running, train your users on how to use the VPN. One of the most common challenges with IT infrastructure deployments, especially with security infrastructure like a VPN, is for the IT team to assume that, since they understand how the solution works, their end users understand it as well. That's almost always a bad assumption. It can turn a successful rollout into an unsuccessful one.

To develop good user training, start by setting appropriate training goals. One of the first mistakes security practitioners make when developing training is jumping past any planning and starting with taking screen shots, typing up documentation, and scheduling meetings. However, much like a successful VPN deployment, the first part of successful training is planning. Determine the following before designing your user training:

Once you gather the appropriate information, determine the best mechanism for delivering the training. You may distribute some written instructions, have a conference call, or even a Web conference. For high-profile users, or users who require significant support, hold classroom training. If you decide to go with live training, definitely plan to do additional information security training. After all, you have their attention for the period of the training—maximize the benefit not only to your users, but also to your company. Remember that well-trained employees tend to be the most secure computer network users.

Other things to keep in mind as you do user training: Make sure your training plan includes how you will train new employees. Will your training post to an intranet Web site, or load onto a DVD that new hires can watch? Will you offer new-hire training at a regular interval to ensure everyone understands how to use the VPN?

Finally, don't forget your support staff. If a user with VPN issues is supposed to call the Help Desk, make sure the Help Desk knows how to help.

To successfully troubleshoot and resolve VPN issues, be organized, methodical, and prepared. Like anything else on your network, your VPN at some point will experience an issue. 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:

Now that you have your basic information, you can start troubleshooting. There's 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 layer and work their way up to the application. The actual process is not as critical as having an established process and sticking with it. One way to tackle this process is the following:

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

You can do a couple of 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 11-4 for a sample successful PING response.

Figure 11-4.  Troubleshooting a VPN issue using PING.

Figure 11-5.  Using Internet-based Traceroute tools to determine if your VPN is accessible from the Internet.

Once you've validated the internal port, also validate the external port. This is frequently a challenge because in most organizations a direct connection to the outside of the network is not readily available. In some larger organizations you may have a DSL Internet connection dedicated for testing, but if you don't have that type of access, a number of Internet sites will let you run network diagnostics from their Web sites. See Figure 11.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, don't panic, keep focused on the issue, and you will be very successful in quickly addressing VPN issues in your environment.

VPN management is a complex activity that requires attention to detail and good documentation. A variety of best practices may assist you in your VPN deployment and ongoing support. Selecting and deploying a VPN solution that meets your business requirements is essential. This includes deciding between open-source and commercial VPN solutions when selecting your product. Understanding the threats, attacks, and mitigations, and ensuring your VPN is available are key components of success. In addition, understand the difference between privacy and anonymity, know the difference between personal/individual and enterprise/network solutions and, finally, be able to train your users well. Once you have mastered all these facets of successful VPN rollout and support, you'll be ready to move on to other security topics.