Rolling out remote access

Cisco and Check Point earn top scores for enterprise readiness.

By Joel Snyder, Network World Global Test Alliance
Network World, 10/28/02

Original Article on Network World Web Site

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.

Deployment

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.

Authentication

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.

ActiveLane supports RADIUS, but not with any panache. The ActiveLane server is essentially Windows 2000 Routing and Remote Access Service with some percentage of the many Windows user interfaces replaced by a Web graphical user interface (GUI) and a database in the back end for management and reporting. Sometimes the interface is very elegant; in other cases, you get dumped directly into a Microsoft Management Console interface, which is the underlying control structure Microsoft provides. RADIUS is one of those edge cases where ActiveLane's configuration tools don't help. However, to use RADIUS with ActiveLane is to miss the point: The idea with this server is to authenticate to Windows, preferably via Active Directory. That's why you'd buy this product - because it has the best integration with Windows of any of the VPN solutions.

One of the few vendors to integrate VPN services and the enrollment process of assigning a token to each user into a single solution is Secure Computing. If you haven't rolled out two-factor authentication and want to just for your VPN, Secure Computing's product will save you a pile of time. The company integrates the sign-up process for your two-factor token with a Web server and vastly simplifies the difficult process of handing out and registering the tokens. If you don't like the VPN server, you still can use the enrollment tool kit with any other VPN products we tested.

Testing certificates was a headache because VPN software vendors are in a difficult position with certificates, so making products that sort it all out is difficult. Microsoft built a beautiful infrastructure for managing certificates and related technologies (such as Smart Cards) into Win 2000 (and XP). If you use its Cryptographic API (CAPI), then you automatically support almost every card reader and certificate format on earth. However, the certificate part of CAPI isn't available in Windows 98 or NT. To properly support certificates, you need two implementations of your product: a CAPI-compliant one for Win 2000 and above, and a custom-written internal one for all other versions.

Our testing was based on Entrust's PKI certificate authority. We enrolled our users and gave them certificates, stored along with their private keys, on Schlumberger Smart Cards.

Check Point wasn't fancy - it supported CAPI - but it worked just fine. Without CAPI support, SonicWall and Cylink were nonstarters in the certificate front. Cisco, in theory, supports certificates, but our certificate authority had a key longer than the 2,048-bit maximum Cisco supports, so we couldn't test it.

ActiveLane's certificate support relies heavily on Active Directory integration with the Entrust certificate authority. Trying to just use certificates without integrating into Active Directory exceeded our patience because there is no reason for Microsoft and ActiveLane to make it so difficult.

Avaya and NetScreen support certificates, but with a catch. You need a username and password to log on to the policy manager and get your policy. So if you choose to authenticate with certificates, it works as long as you enter your username and password first. NetScreen works around that problem pretty well by suggesting a group username/password. This is used, essentially, to tell the policy server which group you want to join. Once you get your policy, then it's your certificate that authenticates you to the VPN. Because there is no authentication information in the policy, it's not a particularly bad thing if the group username/password gets out, because all it lets you do is download the list of protected networks and security gateways. Still, given that you have a certificate, having to log on at all with username/password seems like you're missing the benefits of certificates.

Reporting

Keeping track of what your VPN is being used for seems to be something that most vendors regard as optional, but we don't. Only ActiveLane, Cisco and Imperito offer basic accounting information on the VPN. The others kept us in the dark about who was consuming resources. For all the talk about the need for tools such as firewalls to control network access, the amount of reporting to come out of those same tools was often weak.

Auditing, which is a little more common in the security world, was better supported. All the vendors had some way of getting at least basic information, such as logons, to a log server. The kings of auditing were Symantec and Secure Computing, which would not only log the VPN session itself, but also any application connections made through the VPN tunnel.

We also looked at VPN tunnel control and firewall issues. We wanted to know how much control you have over a particular VPN tunnel once you let it into your network.Can you enforce stateful packet inspection within a tunnel, only giving access to specific resources? Because IPSec's control mechanisms are fairly coarse, we wanted to see what additional options for tightening access to resources were available. The boxes that are primarily firewalls - Check Point, NetScreen, Secure Computing, SonicWall and Symantec - all have a pretty strong ability to control what happens, even after the tunnel gets into the network. Systems that are primarily VPN concentrators - ActiveLane, Avaya, Cisco, Cylink and Imperito - have little or no additional control.

Operations and network management

A simple question network managers want answered is: Who is logged onto the VPN? Depending on the answer, the next step could be to log off that person. We were amazed at how many of the products tested couldn't handle these simple tasks. Hats off to Cisco and ActiveLane, both of which let us see who was logged on, and log them off. Imperito had a similar feature, but you couldn't see just the logged-on users; you had to dump the entire user database to see which users were logged on or not. That wouldn't be too useful if you had more than 100 users. Avaya let us see who was on, but wouldn't let us do anything about it.

Check Point has a problem on this front. We evaluated Firewall-1 NG FP3 as it was coming out of beta testing and found a number of stability problems with the management interface. Sometimes we could not push changes down to the firewalls, and other times the monitoring and alerting part of Check Point's GUI would report that the firewall was down even when it was working fine. As far as we could tell, all these bugs are in the management side of the house. We didn't have any problems making VPN tunnels or leaking packets through the firewall. However, Check Point's tool for looking at remote access VPN users wouldn't even start up for us, so we couldn't test it.

Cylink, NetScreen, Secure Computing and Symantec gave little or no useful information about current users logged on to the remote access VPN.

Good support for other network integration and management functions, such as per-user or per-group bandwidth management and integration of routing protocols, was sporadic.

Cisco had a nice selection of routing protocols, routing options and bandwidth-management tools built into its product. When a site-to-site VPN tunnel or remote access user came up, Cisco could inject a route into the network to let the rest of the world know that this site or user had become available.

No other vendor offered the same level of integration for both routing and bandwidth management. NetScreen offered bandwidth management of the VPN, but no routing (that is slated for its next major release).

ActiveLane offers routing and bandwidth management, but neither is integrated into the VPN. The same is true of Check Point - with its optional product Floodgate, you get some bandwidth management, but that's not part of the VPN picture. And while the Nokia platform on which we tested Check Point had a range of routing functions built in, none talked directly to the VPN part of the network. Avaya showed up with a Routing Information Protocol implementation, certainly not the routing protocol of choice for enterprise networks.

Making the choice

Picking a remote access VPN product isn't hard once you've taken the time to define your requirements.

You need to nail down big issues such as authentication and user policy management or you won't be able to narrow the field of potential vendors.

From there, a slew of less-important options have to be identified: Do you need internal addressing? A hardware client? Macintosh support? Client-side firewall? High availability? Multiple gateways? Firewall within the tunnel? Advanced Encryption Standard support? NAT support? All these are small in themselves, but can turn into problems if the answer doesn't match your requirements.

A proper evaluation requires that you start with what you want first and only then match products and features to identify a short list of finalists. Although Cisco and Check Point performed well in our bottom-line assessment, each has limitations that might be deal-breakers when it comes to your own corporate-sized VPN.

ActiveLane V3000 VPN Server Appliance   Company: ActiveLane, (800) 276-0578 Pros: Works with built-in Windows 2000/XP client; integrates with Active Directory very cleanly; excellent alerting facilities; good reporting and real-time status. Cons: Uses L2TP or PPTP to deal with NAT/NAPT; single box management; poor RADIUS support.   VSU 1000Concentrator, VSU 5X Hardware Client, VPNremote Client   Company: Avaya, (908) 953-3348 Pros: Automatic policy update for multiple groups; excellent RADIUS support; easy management system installation; simple hardware client. Cons: No real firewall beyond packet filters; HW client inflexible.   FireWall-1 NG on Nokia IP350, Nokia IP30 Internet security appliance, SecureClient   Company: Check Point Software, (800) 429-4391 Pros: Automatic policy update for multiple groups; excellent multigateway support; excellent client-side firewall; easy to fire-wall VPN; strong multi-platform support. Cons: FP3 still not fully debugged; HW client management not yet available.   Cisco VPN 3000 Series Concentrator, Cisco VPN 3002 hardware client, Cisco VPN Client   Company: Cisco, (800) 553-6387 Pros: Automatic policy update for multiple groups; good client-side firewall; good real-time status; multiplatform support. Cons: Single gateway per management domain; difficult to manage packet filters.   NetHawk VPN gateway and clients, Privacy Manager for NetHawk   Company: Cylink, (800) 533-3958, Pros: Easy management installation. Cons: No support for internal addressing; no RADIUS support; poor certificate support; no real firewall.   SafeSecure Access Policy Manager, Integrated SafeSecure Access Gateway, SafeSecure Access Client   Company: Imperito Networks, (866) 467-3748, Pros: Very simple installation and management; easy client and policy update. Cons: No support for RADIUS; no support for multiple user groups.   NetScreen 50, NetScreen-Global Pro Express management system, NetScreen 5XP hardware client, NetScreen-Remote security client   Company: NetScreen Technologies, (408) 730-6000 Pros: Automatic policy update for multiple groups; multigateway support; good client-side firewall; easy to firewall VPN. Cons: Full management system difficult to install (needs Prof. Svcs.).   Sidewinder; Safeword PremierAccess, SoftRemote VPN client   Company: Secure Computing, (800) 379-4944 Pros: Token enroll-ment integration elegant; easy to firewall VPN; excellent auditing. Cons: NAT/NAPT support poor; element-level management.   SonicWall Pro 300 concentrator, SonicWall Global Management System, Tele3 hardware client; SonicWall VPN Client 8.0   Company: SonicWall, (888) 547-6642, Pros: Above-average reporting tool; easy to firewall VPN. Cons: No support for internal addressing; client policy management very weak.   Symantec Enterprise Firewall with VPN   Company: Symantec, (800) 441-7234 Pros: Easy to firewall VPN; many authentication links; excellent auditing. Cons: No hardware acceleration support limits total performance; NAT for internal addressing dangerous.