Building VPN
By following these 10 simple guidelines, it's possible to build a VPN that addresses the needs of virtually any organization.
The first step is to find out what kind of WAN connections are needed. Do users reach the corporate network over LAN/WAN or dial-up links? Are remote users part of the same organization?
WAN connections fall into two categories: intranet links and extranet links. Intranets connect trusted locations and users within the same organization. Typical examples here are links from headquarters to branch offices, telecommuters, and users on the road.
For intranet links, the VPN should furnish the same access to the corporate net as if the user or branch office were physically connected. The security policy enforced by an intranet VPN is usually the standard corporate policy, at least once the remote user has been authenticated.
A key consideration for VPNs that encompass branch offices is the physical secur ity of those offices. "Physical security" covers everything from keys and locks at the branch office and network access to computing equipment and the number of nonemployees with access to the facility. If none of these issues presents a problem, it's probably safe to create an "open pipe" VPN—a LAN-to-LAN style connection with no VPN-based user authentication—between headquarters and the branch office.
But if there are problems in those areas, then network designers need to consider more restrictive security measures. For example, a VPN design for insecure installations might require stronger authentication, or it might limit access to an isolated subnet on the headquarters network.
Extranet security requirements, on the other hand, are usually more stringent. Access to confidential information is granted only when required, and sensitive network resources are off-limits. Since extranet connections may involve personnel outside an organization, there are special challenges when it c omes to managing changes in the user population. This is fundamentally a political rather than a technological issue, but it's one that needs to be addressed when determining user requirements.
Corporate networks make tempting targets for attackers, and management obviously will want to be assured about protection against remote intrusion. An organization's security policy should define what forms of remote access are (and aren't) allowed. The policy also determines appropriate VPN gear and implementation choices. If there is no written policy for remote authentication in place, VPN implementation is an ideal reason to create one.
The policy should address several issues specific to VPNs: eligibility for remote access, executive accountability, responsibility for extranet connections, and monitoring of VPN usage. It also should cover procedures for giving Internet access to traveling and remote employees. The policy might also cover such technic al details as the lengths of encryption keys used in relation to time-sensitivity of the data handled. Legal assistance will be needed if export authorization is required for the VPN's encryption algorithms, and it's a good idea to have a lawyer review the policy even if export requirements aren't an issue.
For extranets, the policy should specify a procedure for rapid notification of changes in the remote user population. Those who are terminated must be removed from the authentication database as quickly as possible, and this requires coordination between the external user's organization and the VPN administrator. Human resources departments may already have procedures for managing consultant access, and these may be appropriate for VPN users.
With so many VPN products to choose from, picking one isn't easy. But all fall into three broad categories: hardware-based systems, standalone software packages, and firewall-based systems. And most sup port both LAN-to-LAN and remote dial-up connections.
Hardware VPN products are typically encrypting routers. Because they store encryption keys in silicon inside the device, they're harder to crack than their software-based counterparts. And encrypting routers are fast—in fact, they should be the first choice where links operate at rates above T1 (1.544 Mbit/s). If there's a downside, it's that some require custom hardware (often a PC Card or dongle) for each end-station. Worse, some early products required manual changes to each end-station every time the network topology changed or a user's key was revoked.
Fortunately, more and more hardware-based products include client software for each desktop. The client software automatically processes change information, and as a result functional differences have begun to diminish between hardware- and software-based products.
Still, softwa re-based VPNs may offer more flexibility. Many permit tunneling according to address or protocol, unlike hardware devices, which generally tunnel all traffic they handle, regardless of protocol. Tunneling specific traffic types is advantageous in situations where remote sites may see a mix of traffic—some that needs transport over a VPN (entries to a database at headquarters) and some that doesn't (Web surfing). In situations where performance requirements are modest (such as users connecting over dial-up links), software may be the best choice.
The trouble with software systems is that they're generally harder to manage. They require familiarity with the host operating system, the application itself, and appropriate security mechanisms. And some software packages require changes to routing tables and network addressing schemes.
Firewall-based VPNs, on the other hand, take advantage of the firewall's security mechanisms, including restriction of access to the internal network. They also p erform address translation; satisfy requirements for strong authentication; serve up real-time alarms; and offer extensive logging capabilities. Most commercial firewalls also "harden" the host operating system kernel by stripping out dangerous or unnecessary services. OS protection is a major plus, since very few VPN vendors supply guidance on OS security.
When might firewall-based VPNs be the best choice? When remote users or networks are potentially hostile. Net managers can set up a so-called demilitarized zone (DMZ) segment, which typically uses a third interface on the firewall with its own access control rules. Attackers may be able to reach the DMZ, but they won't be able to damage internal segments. Firewall-based VPNs also are cost-efficient for intranet-only implementations, and they're the easiest of the software-based options to secure and manage.
For all three of these VPN types, net managers also need to check into four areas: protocols handled, IPsec support, authentication ser ver support, and exportability of encryption keys.
For example, while most corporate nets are multiprotocol, most VPN products focus on IP only. Where other protocols like IPX or SNA need to be transported, look for products that either encrypt these protocols natively or tunnel them into IP for handling by an IP-based VPN system. Obviously, the latter choice may degrade performance.
IPsec is an effort by the IETF (Internet Engineering Task Force) to add standards-based authentication and encryption to the TCP/IP protocol suite . Vendors of all three VPN types trumpet its benefits, but in fact it's still evolving. At this point, only a few vendors have demonstrated interoperability, and then only for basic connectivity. As IPsec becomes more stable and more broadly implemented, VPN end-points will no longer have to use products from the same vendor to work reliably. At thi s point, however, implementing a successful VPN usually means buying all equipment from one vendor.
Although most VPNs can maintain their own authentication databases, net managers may want to leverage existing authentication servers. For example, many RAS (remote access server) setups use an external system based on one of two protocols to authenticate users: Radius (Remote Authentication Dial-In User Server) or Tacacs (Terminal Access Controller Access System). The advantage of standalone authentication servers is scalability: Only one is needed, regardless of how many access devices are added.
Net managers also will have to address export issues if the VPN extends overseas. Current U.S. law forbids the export of 128-bit encryption, though pending legislation may ease restrictions somewhat. Organizations with both U.S. and overseas operations may need to deploy two VPN systems: one with weak encryption for the international crowd and one with strong encryption for domestic users.
The fourth step is to run two or three VPN products through extensive tests. Decide on a small group of pilot partners among remote users, and have them try the system out. Be sure to include employees covering a wide range of technical ability in initial trials. This is critical in ensuring a fair test of the VPN—and in assessing the troubleshooting skills of the people managing it.
A successful VPN test will cover six areas. First, it will show that the VPN can be configured in accordance with the organization's remote access policy. Second, it will show whether the VPN supports all the authentication and authorization mec hanisms in use. Third, it will prove the VPN can produce and distribute keys efficiently. Fourth, it will allow remote users and locations to participate on the corporate network as if they were physically connected. Fifth, it should demonstrate the system's ability to provide obvious clues for troubleshooting. Finally, it should prove the VPN can be used easily by technical and non-technical staff alike.
When it's time to determine the right type of hardware for a production system, try to estimate the total number of users; the typical number of concurrent sessions; and the typical time-sensitivity of the data (which determines the key length required). For software-based VPNs, a 200-MHz Pentium processor will be able to handle T1 network connections. (This figure assumes triple DES [data encryption standard] encryption using 128-bit keys, data compression, and message authentication.) Specify as much RAM as possible on the server, since more memory allows more simu ltaneous connections. As noted, network connections faster than T1 will probably require hardware-based VPNs.
If vendors supply performance benchmarks, be sure to get details on how the testing was performed. To get a truly even comparison among different vendors' claims, net managers need to consider issues like frame length, encryption algorithm and key length, use of compression, and the presence or absence of message authentication algorithms.
Net managers also need to consider backup and redundancy issues in designing a production system. Large organizations (or those with high volumes of traffic) may also want to consider load balancing across multiple servers.
The affiliation of remote users helps determine where the VPN devices belong. For employees expecting remote access to replicate their office environment, the VPN server may belong directly on the private network. But this approach also serves up a tempting target to attackers.
If the majority of remote users belong to outside organizations, it makes more sense to put the VPN devices on a DMZ network—since it's more secure than the internal network. This also is safer than placing the VPN devices completely outside the security perimeter, since the firewall that screens the DMZ will help safeguard machines on that segment.
If an authentication server is deployed, it belongs on the DMZ subnet. Here, it can be carefully managed and protected from both internal and external threats.
Placing VPN and authentication servers is a critical issue in designing secure intranets and extranets . It's easiest to set up links with branch offices: A pair of VPN servers simply creates an encrypted tunnel between sites. Traveling employees or telecommuters need to be authenticated. Therefore, they establish a link with the VPN server, which passes an authentication request to an authentication server on a DMZ segment outside the corporate firewall. Outside consultants don't need authentication; they can simply connect with another VPN server, although this should be on a second DMZ to protect the company's authentication server. The trickiest configuration is for business partners. Here, connection requests first go to the VPN server on the second DMZ. Then requests are passed to the authentication server on the first DMZ. Requests that are accepted are then passed along to the requested resource.
Installing a VPN may mean reconfiguring other devices on the corporate network, especially when it comes to IP address management and firewalls. VPNs usually make use of NAT (network address translator ). NAT maps private addresses (usually chosen from a block of reserved addresses) to only one or a handful of addresses visible on the public Internet.
At the very least, net managers will need to configure VPN equipment to understand which addresses are reserved for internal use. Further, many firewall-based VPNs also support DHCP (dynamic host configuration protocol), a method of automatically assigning IP addresses to attached clients. Net managers need to coordinate the DHCP and VPN functions, or else clients may end up with routes only to the Internet and not the private network, or vice versa.
Some VPN devices use virtual network adapters, and these will require the assignment of valid IP addresses on the private network. (Examples of such products include the Altavista tunnel server from Digital Equipment Corp. [DEC, Maynard, Mass.] or VPNs that use PPTP [point-to-point tunneling protocol], developed by Microsoft Corp. [Redmond, Wash.].) Assign these addr esses out of an unused address range, and make the required modifications to routers and any other network equipment that needs to be updated about address changes.
Firewalls will also need reconfiguration if the VPN server is inside the firewall. Most VPNs take all traffic and encapsulate it into a stream that uses a single TCP port number. Thus the firewall will need a generic proxy or pass-through rule for the encapsulated VPN traffic, as well as an "allow" rule to transport the traffic to the VPN device.
For extranets, where the VPN device is on a DMZ segment, the firewall will need one rule for allowing encrypted traffic to travel from the Internet to the DMZ, and additional rules for application traffic traveling from the DMZ to the internal network. If the authentication server is located on the internal network, be sure to configure the firewall to allow authentication requests between the DMZ and the private network.
One place not to make changes is the private network's DNS (domain name system) server, which is responsible for resolving hostnames of private network machines to IP addresses. If it's visible on the public Internet, then attackers can learn the layout of the private network.
For software-based VPNs and those built around firewalls, it's essential to begin with a secure system. Remove all unnecessary services, applications, and user accounts from the server. Make sure the latest patches and security releases are installed. Only then is it safe to install the VPN software.
When configuring the VPN itself, net managers will need to set parameters for key length; primary and secondary authentication servers (with associated shared secrets); connection and idle timeouts; certificate generation; and key generation and distribution mechanisms. Digital certificates verify the identity of VPN end-point machines (rather than users) and are implemented by most VPN products. Some vendors use a model where all this information is entered once at a headquarters device, and then remote devices download the information as they're brought online. For remote users, it also will be necessary to set up passwords, prepare connection scripts, and establish authentication procedures.
Net managers also need to sync up authentication and authorization routines. These sound similar, but there are subtle and important differences. Authentication involves proving that a remote user is who she or he claims to be (and in extranet settings, proving the opposite—that the server is trusted). Authorization determines which network resources the remote user has rights to. If the authentication server also controls authorization by groups (for example, for marketing or engineering), be sure to verify that it communicates group information correctly to the VPN devices.
The ninth step is to create mechanisms to monitor the Internet connection (if they're not already in place). This is needed for gauging the impact of the VPN on network utilization and throughput. It's also essential to train help-desk staff in operation of VPN devices and how they interact with the authentication server and firewall.
Also, all net managers in the organization should be briefed on the VPN's basic operation. The person who installed and configured the VPN shouldn't be the only one who understands how it's managed.
End-users also may need training in the basics of Internet connectivity and how the VPN software works. It's also a good idea to train end-users in some basic troubleshooting tasks that they can perform before asking tech staff for help.
As users get more comfortable with VPNs, it's likely that mission-critical apps will be involved; for example, a company might build an electronic storefront for customers. In cases like this, backup connectivity is a must.
Net managers should plan for redundant links and equipment during the network design phase. In addition, sites with high traffic loads might look for VPNs that support load balancing across multiple devices. A few VPN vendors offer load-balancing capabilities, and virtually all support redundant paths.
And even when availability needs aren't critical, having a backup is a good way to keep end-users from complaining. Here, maintaining a few modems and phone lines for emergencies might suffice. However, this approach may be costly and irritatingly slow. For LAN-to-LAN connections, the need for backup connectivity may best be met by ISDN or other on-demand dedicated lines. And be sure to test the backup connectivity on a regular basis.