Cisco and Check Point earn top scores for enterprise readiness.
We invited leading IPSec-based VPN vendors to provide their best products for serving up enterprise-class remote access to thousands of users. We tested 10 products from ActiveLane, Avaya, Check Point Software running on Nokia's hardware, Cisco, Cylink, Imperito Networks, NetScreen Technologies, Secure Computing, SonicWall and Symantec. (For declining vendors, see story.)
In our evaluation, we considered deployment and support burden, management overhead, suitability for enterprise networks, flexibility, reporting capabilities and client support (see How we did it). Rather than focus on a particular model of VPN server, we encouraged VPN vendors to show us an entire set of products that address remote access VPNs, including concentrators, management applications, and hardware and software clients (see NetResults for full product listing).
Cisco and Check Point came in way ahead of the pack in our tests. While Cisco barely edged out Check Point in the overall score, we handed both products a World Class award because both companies have clearly considered the issues of enterprise remote access and built products that are easy to use, deploy and update, but are not arbitrarily limiting in terms of policy, platform or features.
Honorable mention, though, goes to NetScreen and Avaya. While neither product set offers all the features and flexibility of the winners, they've assembled systems that generally do a good job attacking the problem of large-scale remote access and offer specific product details that also might sway a decision in their favor. Avaya's specialized support for voice-over-IP (VoIP) applications is better than any other, while NetScreen's broad range of hardware lets you precisely fit resources to requirements.
VPN clients have two pieces: the client software and the abstract policy that defines how communications are encrypted. Deployment means getting the software and policy information to end users and keeping both updated as the network configuration and topology changes.
Client software installation was generally easy across products. The notable exception is ActiveLane, which is designed to work with built-in Windows VPN clients -both PPTP and IP Security (IPSec)/Layer 2 Tunneling Protocol (L2TP). Not having to do anything at all because the software is already there makes for a pretty easy installation.
On the policy side, some vendors, such as Secure Computing and Cylink, keep a policy file (often called a policy blob) sitting on each client. This is problematic because if you change your network configuration or the IPSec tunnel, you'll need to push the policy blob out to each client. In an enterprise environment where not everyone has the same VPN policy, the problem is exacerbated because you must ensure each client has the appropriate blob.
A better enterprise solution is to use a policy server that works with the client to keep the policy up to date. The client connection will take a little longer, as policy versions are checked, but, in return, end users never have to wonder if they've got the right version of the policy.
Avaya, Check Point, Cisco, Imperito, NetScreen and Symantec all handle this cleanly and elegantly through the use of policy servers, but only Avaya, Check Point, Cisco and NetScreen let you maintain multiple user policies. With Imperito, all users who connect to a VPN gateway get the same policy. Imperito says its new enterprise-focused product called SafeSecure Access Global will address multi-user policy support when it ships around the new year. Symantec supports per-user policies, but only for users who are entered individually into its internal authentication database, eliminating the possibility of using external authentication servers for multiple user policies, which makes the feature useless in any sizable deployment.
Clients also are subject to updates, upgrades and patches. Check Point, Cisco, Imperito and, to some extent, NetScreen deal with this problem in the context of the VPN policy you define. The slickest is Imperito's SafeSecure Access, which not only manages the update but also keeps track of what Imperito client version each user has on his machine.
Check Point has a generic software download and maintenance system built into its client, not just for the VPN software, but for anything you want to upgrade on remote users' systems.
For network managers who don't want to learn all the nuances of Check Point remote client management, a simplified version can keep the VPN client up to date.
The same question of deployment comes up in hardware VPN clients. Hardware VPN clients are little boxes with dual Ethernet ports that sit in front of one or more client machines and off-load the VPN connection, eliminating the need to load software or policy on the end system. Because hardware clients are generally unattended and unmanaged, getting policy updates to them is a particular problem.
While Avaya, Check Point, Cisco, NetScreen and SonicWall ship hardware clients, Cisco and Avaya offer the cleanest hardware client management.
With Cisco's hardware client, you tell it the IP address of the policy server, a username and password pair with which to authenticate, and that's it. Systems behind the hardware client are encrypted automatically when they attempt to connect to systems the VPN protects. The hardware client downloads the policy as needed. In Avaya's model, each user who passes through the hardware client needs to be authenticated individually to the policy server via a Web page.
NetScreen and SonicWall treat their low-end VPN systems as hardware clients. These hardware clients must be configured using a model different from simple remote access. The issue is that these hardware clients are managed using push techniques, rather than pushing policy from a central server. Push doesn't scale well or work well even in small installations if the hardware clients have dynamic IP addresses behind a Network Address and Port Translator (NAPT) box, which is typical in many cable modem and DSL remote deployments.
Another aspect of managing remote access clients is getting some kind of control over the affiliated pieces that have snuck into the products, specifically client-side firewalls. In Check Point's model, the optional client-side firewall is configured using an interface very similar to that used for dictating enterprise firewall rules. A miniature version of its firewall packet inspection engine is installed on the client, and the VPN and firewall configurations are packaged together as a single policy blob,which the central policy manager automatically updates and controls.
Security managers get intense and precise control on what the client can do when it's part of the VPN.
Cisco and NetScreen also do a good job managing client-side firewalls. Cisco's interface is not as elegant as Check Point's, but it lets you set primitive packet filters programmed into the client firewall and set up some ties with other centrally managed products from Zone Labs and Internet Security System.
Cisco and NetScreen also offer a posture assessment feature that lets you block VPN connections if the firewall is not currently active.
Most of the other vendors package a personal firewall with their VPN client (ActiveLane, Avaya and Cylink are exceptions), but there's no support for central policy management and updating integrated with VPN management.
Suited for enterprise use?
The IPSec standards are virtually mum on the topic of remote access. To compensate for this, most VPN vendors have extended the standards in several ways. While departing from the standard is usually a bad idea, there really is no way to build a good IPSec remote access VPN without taking liberties. This reduces interoperability, of course, and ties you to a single vendor. It also reduces your choice of VPN client platforms. Although there are IPSec clients for virtually every platform, without the vendor-specific proprietary extension, a deployment of more than a handful of clients would be unmanageable.
One area where remote access and IPSec collide directly is in NAT and NAPT support. NAT and NAPT are techniques that ISPs use, especially in broadband environments, to deal with the shortage of IP addresses by having multiple users share a single IP address or set of IP addresses as their packets move toward the Internet. "NAT is the kind of attack that IPSec was designed to detect" is security designer Dan Harkins' famous quote. Nevertheless, NAPT and some kind of dynamic addressing, such as Dynamic Host Configuration Protocol (DHCP) client or Point-to-Point Protocol over Ethernet, are realities in virtually all broadband network deployments. A solution that doesn't support NAPT simply won't work, and this is one reason to avoid ActiveLane's and Secure Computing's remote access VPN products. (ActiveLane actually does support NAPT when using PPTP, a less-secure alternative, but we considered this unacceptable from a security model point of view.)
Internal addressing is another nonstandard extension for remote access. Network managers find it very convenient to control the IP addresses from which clients appear to come when they appear on a corporate network. This helps with internal routing in more complex networks, because it is important that packets that came in via the VPN also go out by the same path. In addition, internal firewalls can identify which users are VPN users by their addresses, which can simplify access controls and security policy enforcement.
Cylink and SonicWall don't support internal addressing at all. NetScreen and ActiveLane support internal addressing, but only if you run L2TP as a tunneling protocol. The simplest case is to simply give a pool of addresses to the VPN concentrator and let it hand them out. Solutions that support basic internal addressing generally let you do this.
But Check Point, Cisco and Secure Computing let you control the address assignment based on user groups. Cisco and Imperito also will go to a DHCP server to get an address.
Internal addressing is one of those features for corporate VPNs that can be a showstopper. If the details of how internal addressing is implemented are not compatible with the VPN deployment architecture, everything might fall apart. This is why it is critical to design a VPN before selecting a product and then understand exactly how these subtle details are to be implemented. Symantec implements internal addressing by doing the address translation of the VPN clients on the central site side. It's a clever solution that avoids non-standard IPSec, but if you have an application to run over your VPN that is difficult to translate properly (such as VoIP via H.323) or that isn't supported in the Symantec NAT code, then you've got a serious problem.
One of the most difficult parts of a remote access VPN deployment is authentication, because the IPSec standards admit only one type: public-key infrastructure (PKI)-based digital certificates. Very few companies have rolled out PKI for user authentication, which means that the only way to build a workable remote access VPN based on IPSec is to go around the standards.
NetScreen has developed a remote access VPN authentication process that wraps a proprietary protocol around IPSec. You authenticate to a policy server first, using NetScreen's client that gives you a copy of the current policy. From then on, you use standard IPSec functions to authenticate.
In our testing, we assumed that any company would authenticate using one of two approaches. The first uses an existing authentication system that can be connected to the corporation using Remote Authentication Dial-In User Service (RADIUS), perhaps linking to tokens or even an older username/password database, such as the Windows authentication database. The other is PKI-based digital certificates designed for multiple applications and stored on Smart Cards. We tested both approaches.
The RADIUS test gave us the least trouble, with two exceptions. Neither Imperito nor Cylink support RADIUS-based authentication. Imperito requires that you maintain a separate user database for the VPN. As a former managed service offering, Imperito got the deployment and policy updating piece down almost perfectly, but completely stumbled when it came to user authentication. Again, Imperito officials state that its upcoming SafeSecure Global product will better address RADIUS support.
Not everyone insists you use RADIUS for legacy authentication. Symantec will talk to a Lightweight Directory Access Protocol directory, to a Windows NT domain, and directly to Cryptocard, SecurID, S/Key and Defender servers for your choice of token-based authentication.
Bryan Lunduke talks with Martin Wimpress—the man behind Ubuntu MATE—about why he decided to make his...
I love my iPhone 6 Plus—and that’s Apple’s problem.
The Internet of Things is predicted to grow to a $1.4 trillion market by 2020, which means there are...
The website of toy maker Maisto was infected with malicious code that distributed CryptXXX, a new and...
Follow these steps to reap the benefits of SDN without disrupting your IT environment
Three ways to respond to demands for a fast, iterative, rapid-feedback monitoring solution
Flame wars in the bug tracker might be exactly the right (harsh) feedback your code needs