Enter the virtual private network. With a VPN, you can reduce long-distance charges while increasing the security of your data transport. But a VPN won't lighten your support load. VPNs are similar to dial-up lines in terms of user administration, troubleshooting and accounting. In fact, a VPN server commonly interfaces with a RADIUS server. Because many users are going to connect via modem, you still need to support modems and deal with the associated problems.

Of course, some organizations don't need VPNs. If all your applications are Web-enabled via SSL or can be contained in an SSH tunnel, you can do without one. However, if you're hankering for more general-purpose use, more complex software or finer access control to the internals of your network, a VPN may be the way to go.

We set out to test large-scale remote VPNs for the latter scenario. We required that devices be able to handle 1,000 simultaneous connections and offer some form of HA (high availability) at the head end. We identified six possible players. Four of them, Avaya, Check Point Software Technologies, Cisco Systems and Nortel Networks, accepted; Enterasys Networks and Lucent Technologies declined, both saying they were in between product versions.

Reach Out and Touch Someone

While the underlying protocols for IPsec VPNs are complex, setting up a secure connection was a cakewalk on all the devices we tested. VPNs work at Layer 3. An IP packet from a client node is encrypted, forwarded to a VPN gateway, decrypted and sent to its destination. Remote users dial into a local ISP and send their encrypted data across the Internet to your LAN. IPsec VPNs have numerous configuration options, but the products we tested use sane and secure default values.

Today's too-hard-to-brute-force-except-for-small-countries encryption standard is 3DES. However, 3DES also is one of the more computationally expensive algorithms. This causes performance to suffer, limiting the bandwidth capabilities of the encryption device. A single round of DES is also an option, but even consumer-level PCs can brute-force the DES keyspace.

A new standard, AES (Advanced Encryption Standard), is less computationally expensive, but only Check Point and Nortel support it. AES has a bigger keyspace, making it harder to crack, and we expect a shift from 3DES to AES in the near future. For most organizations, 3DES or AES is the way to go. A lot of the products' other magic elements -- such as IKE (Internet Key Exchange) sessions, encryption keys, tunneling protocols and security associations -- are simple to set up, and the default values usually are good enough.

The real heartache with remote-access VPNs comes not from security but from managing and supporting end users. In fact, end-user support will be your biggest source of pain when deploying a VPN. Troubleshooting a remote connection can be a real nuisance, and asking end users to read off tunnel-status information is messy. Assuming that the user can access the Internet but not the VPN, you have a variety of options at your disposal. A user can e-mail or upload configuration and log information. Remote-control software, such as Symantec Corp.'s pcAnywhere, may help, too. If the user can't connect to the Internet, he or she has bigger problems than not being able to use the VPN.

You also may need to support third-party client software, which will introduce its own set of bugs and incompatibilities. Microsoft Windows 2000 and XP have a VPN client built in, but it supports only L2TP (Layer 2 Transport Protocol) and PPTP (Point-to-Point Tunneling Protocol), not IPsec. Among the participants in our tests, only Cisco and Nortel support L2TP and PPTP. (For an analysis of when and why you might use L2TP instead of a third-party IPsec client, see "PGPvpn Keeps IPsec Simple.")

With most of the products, we found creating a package installation for end users more difficult than it should have been. Check Point is the only vendor to get this right -- with its VPN-1 we simply selected a group or user and clicked a button, and the device created an installer with embedded configuration information. The other solutions required us to edit a text file and include it with the distribution.

For administrators, two important factors to consider are the mechanisms for locking down the client configuration and handling client updates for policy and software revision. All the vendors offer lock-down features -- a user enters only his or her user name and password -- and all the vendors support updating the client policy on the next login.

Updating software is trickier. Nortel and Cisco provide information on where to download the newest versions of their software. Avaya does not offer any way to update clients centrally. Instead, it supplies a link in the client GUI to the Avaya support Web site. From there, a user can see if a new version is available, but there is no automatic version checking or notification. Check Point lets the server check and requires a certain version of the client. When the server detects a new version, the user is prompted and asked if he or she wishes to upgrade.

Equally important with remote users is NAT traversal and routing (see "Why Can't IPsec and NAT Just Get Along?"). The easy way to do NAT traversal is via UDP encapsulation. Surprisingly, Avaya didn't support this feature, but the company claims it will do so by the summer.

Routing is a bit more complex. The VPN gateway will have a default router to which it sends data. However, you may want your clients to send data to a different default router. All the participants in our tests let you set a different default gateway for the clients. If the VPN gateway is sitting in parallel to the primary firewall, you may want to route client data through the LAN and past your content monitoring or IDSes (intrusion-detection systems).

Are You Available?

Our tests of high-availability features didn't reveal too many surprises. We were pleased with Check Point's HA support -- it has the only product that performs stateful failover. When we downed the master gateway, the client kept downloading data without aborting. The other solutions we tested require the clients to reconnect. (For more on HA and failover, see "Cisco Cures the Chicago Blues".)

The solutions from Nortel and Avaya are the only ones to offer a time delay before the master takes over again. If you have a powerful box and a smaller backup machine, you may want to wait a few minutes or, with Nortel, specify a time of day, before the master resumes. This is because the Nortel and Avaya solutions perform stateless failover -- your clients need to reconnect after each failover. You may want to switch back to the master during low-traffic hours or at least wait a few minutes to make sure the master is stable.

VPN Performance Click here to enlarge

On the management side, we assessed how easy it is to define groups and multiple policies. The look and feel of the Nortel and Cisco solutions are similar, but Nortel's has a cleaner, more straightforward interface. Check Point and Avaya offer centralized management as well as network maps. The map feature makes it easy to see your network layout and tunnels. For Cisco's and Nortel's products, you'll need to make configuration changes, including adding users, on each device individually. This is a nonissue for end users, but it might give administrators a bit of a headache, especially those admins not using RADIUS or LDAP servers for user authentication.

We wanted to see antivirus software and a good personal firewall centrally managed with the VPN client, all with seamless integration. Check Point's solution comes the closest. It supports stateful inspection by putting the company's FireWall-1 inspection module on the desktop, complete with the ability to create inbound and outbound rules on a per-user or per-group basis. However, application control is not supported (see our last desktop firewall review "No Desktop Is an Island" to find out why we like application control). All the products we tested can do packet filtering within the tunnel as well.