Approaching this review we had a number of questions, all boiling down to a common theme: What is the value of a third-party VPN client over Microsoft's native VPN implementation? The answer is: If your users' needs are simple, Microsoft's client works fine. However, if you need to support multiple VPNs, multiple VPN gateways or multiple operating systems, or if you have special networking requirements, you should look elsewhere.

With this in mind, we tested F-Secure Corp.'s F-Secure VPN+, Microsoft Corp.'s Windows XP, Network Associates' PGPvpn and SafeNet's SoftRemote VPN clients in our Syracuse University Real-World Labs®. SSH Communications declined to participate, saying its product wasn't ready, and RSA never returned our e-mail or calls.

We tested and evaluated the VPN clients in four key areas: management and troubleshooting, VPN configuration, interoperability, and advanced features. In evaluating these products, we set our criteria to meet the needs of a centrally deployed and managed VPN client installation base. However, we found that nearly all the advantages and shortcomings in central management are similar to what a power user would encounter managing a standalone VPN client.

IPsec Client Features (chart) Click here to enlarge

Key Points

If you are going to roll out client software for remote access, you need a way to centrally manage the security profiles and policies effectively and efficiently. VPN configurations can be complex, and when working in a multivendor environment, the slightest misconfiguration can result in failure -- you don't want your average user making configuration changes.

All the products we tested had centralized servers that let clients update security policies while connected through a push or pull update. Push updates are immediate for all connected users, while pull updates typically wait to make policy changes until users connect. Equally important to policy management is initial-system provisioning and deployment. If you're rolling out software to a few computers, a manual process isn't too painful. As the number of systems increases to the hundreds or thousands, though, some form of automation is required.

The products we tested let us create installation packages, complete with customized configurations, that could be delivered to users. Alternatively, the clients could be installed using a boot-up script. Only one product, F-Secure VPN+, surprised us during installation: We could install the package remotely without any F-Secure software installed first. Not needing to run from desktop to desktop to distribute an application saves lots of time. Software deployment is not an issue with Windows 2000's or XP's native IPsec.

Troubleshooting tools aren't worth discussing for the most part. None of the products had any decent remote-logging facilities, and the local-logging messages went from brief and useless to verbose and cryptic. You won't want end users reading you these logs over the phone.

IPsec Client Management Applications (chart) Click here to enlarge

Share the Wealth

Encrypted communications are not just for remote users. Sensitive information passing over your internal network in the clear is just as vulnerable to packet capture and corruption as is data traveling outside your borders. But while peer-to-peer VPNs enhance internal security, they are difficult and time-consuming to configure and manage because, typically, each VPN needs to be predefined.

However, two products, PGPvpn and Windows XP, let us build point-to-point VPNs dynamically. In both cases, we configured the clients to attempt to make a VPN with every host contacted, and in the event of failure, allow communication in the clear. Optionally, we could set a policy that required setting up a VPN before communications could take place. Neither SafeNet nor F-Secure could build dynamic VPNs -- each required that the VPNs be predefined.

One of the drivers for using third-party IPsec clients is the ability to connect to multiple VPN devices easily and reliably. We were surprised at the level of interoperability we found during testing, not only for basic VPN connectivity but in advanced support for digital certificates, user-based authentication, NAT (Network Address Translation) traversal and remote address assignment.

We tested these clients using common VPN scenarios and found they work just as well as vendor-supplied client software. So in cases where you need versatile VPN clients, a third-party offering is your best bet. For the most part, few or no configuration changes are required on the remote gateway -- which is good because, unless you have administrative control over the VPN gateways, making changes may well prove impossible. With one exception -- PGPvpn, which doesn't support Diffie-Hellman Modulus Group 1 -- we didn't make any changes to our VPN gateways other than adding users.

We began our testing by authenticating users via a preshared secret IKE (Internet Key Exchange), which we felt was a minimum requirement for interoperability. Preshared secret IKEs are typically used in LAN-to-LAN VPNs where VPN gateways authenticate each other. However, authenticating remote users with only preshared secret IKE poses significant security risks. The preshared secret must be distributed to each end client and VPN gateway out of band, which makes periodic key updates difficult. In addition, anyone with access to a user's desktop can launch the VPN and gain access to the remote network.

Ideally, IPsec gateways should authenticate end users via a second method, employing a user-name/password scheme or tokens, for instance. A preshared secret in this context means the software client is known to the VPN gateway and the user is known to have access to the resources protected by the gateway. There are two common methods for authenticating end users. First is a pair of IETF informational drafts that extend the functionality of IKE: Mode-Config and X-Auth. Mode-Config is used to configure remote users, and X-Auth uses Mode-Config to authenticate end users.

The second method uses PAP (Password Authentication Protocol) or CHAP (Challenge-Handshake Authentication Protocol) defined for PPP. PPP is transported in L2TP (Layer 2 Tunneling Protocol) and is secured by IPsec as defined in "Securing L2TP Using IPsec," RFC 3193, which is an IETF proposed standard. Once the IPsec VPN is negotiated, the L2TP tunnel starts and the end user authenticates within PPP. If the authentication is successful, the PPP connection continues. If it fails, the L2TP and IPsec session is torn down.

For Microsoft and vendors with existing L2TP support, this model for authentication is ready to go. Other vendors will have to build in both L2TP and PPP implementations to support Windows 2000 and XP native clients.

Bear in mind that the interoperability score we gave each vendor is limited to the gateways with which we tested. We chose gateways from Cisco Systems and Nortel Networks largely based on market share, but the selection does not reflect the depth of potentially interoperable products available.