A bypass architecture (FIGURE 10-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 is referred to as bypass deployment.

This was a common architecture when VPNs were first introduced to the market. The logic behind this deployment architecture is that security is adequate without additional firewalling because the VPN accepts only encrypted connections on a specific port. The assumption is that because traffic is encrypted, it does not 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. A bypass 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; each can have a variety of vulnerabilities. As a result, VPNs are still vulnerable to an attack against the device itself. Second, the uses for VPN have expanded greatly since the technology first appeared, and it is 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. Although some controls (usually routing table–related) are available in most VPN solutions, terminating a VPN directly on your internal network is a dangerous practice. As a result, the circumstances where a bypass VPN architecture is still a viable solution are limited, unless your risk tolerance is fairly high.

An internally connected architecture (FIGURE 10-2) deploys the VPN so that traffic to the VPN and from the VPN to the internal network is not firewalled in any way.

An internally connected VPN architecture recognizes that the VPN is vulnerable to attack if placed directly on the Internet, so it places the Internet-facing VPN connection behind a firewall. Selecting the appropriate firewall for this solution is critical to a successful implementation. The VPN then connects any remote users or site-to-site connections directly to the internal network.

This is an improvement over the bypass architecture, but it still does not address the potential security issues associated with untrustworthy VPN connections. This architecture is not recommended, although it will work if the only hosts connecting are trusted hosts.

A demilitarized zone (DMZ)–based implementation (FIGURE 10-3) addresses the main shortcomings of the previous two architectures.

This architecture features a firewall in front of the VPN to protect it from Internet-based attacks, as well as a firewall behind to protect the internal network. The firewall on the inside can be configured to protect important infrastructure like finance department or research department servers, restrict business partners to only the systems to which they need access, or limit vendor access to only those systems supported.

The largest negative in this design is the cost of deploying multiple firewalls for the implementation. However, many companies already have DMZs set up in this configuration, so it may be just a matter of leveraging the existing infrastructure for your needs.

After selecting the ideal VPN and determining where you are going to place it in your infrastructure, it is time to work up your deployment plan.

Before you look at the components of a successful deployment plan, keep in mind that your environment is unique to your organization. Some elements you will read about will not apply to your deployment. These are, rather, just some common elements found in most typical VPN deployment plans. Just as with the other topics discussed here, review these while thinking of the requirements of your organization.

To deploy your VPN successfully, you need to:

• Plan the physical location of the VPN. This is commonly rack space in your data center.
• Ensure that your selected location meets power and cooling requirements. Get information on power and cooling requirements from your VPN’s technical specifications.
• Plan your Internet Protocol (IP) addressing for the external and internal network connections on the VPN, as well as a pool(s) of addresses assigned to clients when they connect to the VPN. Plan for peak usage when assigning these pools to the VPN. Although an average number of users is an excellent use benchmark, peak use determines the maximum number of IP addresses to ensure that all users can connect. If this is a site-to-site connection, your IP addressing plan will not be as complex, but it will still be important when setting up the tunnel.
• If you are using firewalls as discussed in the previous section, plan the rules you will need on the firewalls to permit the VPN to work. Generally, IPSec VPNs will require UDP port 500 for the IKE packets and TCP port 443 for the IPSec traffic. SSL VPNs use port 443 exclusively. Most VPN rule sets permit ICMP packets from the Internet. If you are experiencing issues with the VPN, it is frequently useful during troubleshooting to determine whether the user can reach the VPN server using tools like ping or traceroute.
• Configure the VPN server by setting up the IP address pools, assigning IP addresses to the interfaces, establishing your banner message, and disabling split tunneling. It is also a good idea to have the vendor review your configuration before going live to ensure that you have not missed anything in your planning. In some cases, you might want to have the vendor install the VPN for you while you concentrate on client rollouts, policy communications, and other related tasks.
• Set up the authentication mechanism. Ideally, this will be a token-based authentication solution, but it could be RADIUS-based authentication or, in some smaller environments, user accounts set up on the VPN.
• Follow your organization’s change management policies when deploying the VPN. If your organization does not have a formal change management process, be sure to inform management of your planning schedule to avoid surprises. The last thing you want is to bring the VPN online during the same weekend the accounting department is doing a major upgrade to your organization’s financial systems. If there is a problem with their upgrade, you can count on at least one person blaming it on your VPN rollout.
• Once the VPN is on the network, create a pilot group to test the deployment. Address any issues before you roll the deployment out to a larger user pool. Minimize any issues that employees might face with the new solution. The best way to sabotage a new solution is to deploy it with lots of problems. You may find that some employees have a low tolerance for issues.
• Develop your operations manual, which will document the configuration, operations procedures, change planning processes, and change history.
• Develop your user documentation. Include how to install the client (if a manual install is required), how to log on, the number to call for support, frequently asked questions, and any other information you think will make the user’s experience with the VPN easier.
• Develop your support processes. Who gets the first call when there’s an issue? What is the escalation path if the issue cannot be resolved?
• Communicate the rollout plan to management and affected employees. Let them know the timing, benefits of the new solution, and anything else that you believe will ensure a successful deployment.
• Install the VPN client for any remote access users. If this is a site-to-site deployment, configure the tunnel connection.
• If using a clientless VPN, configure the software.
• Distribute authentication credentials, tokens, and so on.
• Train your users.
• Go live—and enjoy a successful VPN rollout.

You now should be able to select, plan, and successfully deploy a VPN for your organization.