The Remote Access Conundrum Part 4:
VPN Client Administration

In previous columns, we have discussed protocol issues and alternatives facing ISPs that offer remote access VPN services, ranging from authentication to addressing. Here, in the final installment of this series we open Pandora's box—VPN client administration.

Lisa Phifer VP Core Competence, Inc. [March 15, 2001]

For the most part, Virtual Private Networking is a new technology, playing the same old remote access security tunes. Distributing desktop software, configuring it properly, and keeping it up-to-date is a time-consuming, never-ending administrative chore.

ISPs that offer residential Internet access are all too familiar with support costs associated with dial-up networking, mail client, and web browser configuration. Fortunately, these applications are factory-installed on most Windows PCs and include auto-update features. But remember the old days, when subscribers had to install and configure third-party TCP stacks?

In some respects, IPsec clients stand today where TCP stacks stood a decade ago. In 1998, at InternetWorld IW Labs, we started testing early IPsec gateways with paired client software. These clients operated as "shims" or virtual adapters, inserting themselves into the middle of packet processing. Client install/remove problems were commonplace. Configurations exposed esoteric security parameters like crypto algorithms and secret keys to end-users. Centralized client policy and software administration tools were virtually non-existent. Multi-vendor interoperability was—well, drafty, at best. The bottom line—VPN client administration took a bigger-than-anticipated bite out of ISPs return on investment.

With maturity comes reliability
Fortunately, IPsec clients have matured considerably during the past three years. Base standards stabilized. Testing against reference implementations improved interoperability. Software kinks were resolved with time and field experience. However, testing complex network software with every permutation of Windows OS, service pack, and modem/adapter is a challenge.

Today, many remote access vendors—including Check Point, Nortel Networks, and Indus River—continue to refine their own IPsec clients. But an increasing number of equipment manufacturers—including Cisco, Lucent, 3Com, and Nokia—outsource IPsec client development by OEMing SafeNet's Soft-PK.

Today's IPsec clients are not bullet proof, but compatibility issues are declining. A study conducted by Lucent NetCare cited overall VPN product immaturity as a significant barrier to deployment, but found that technology issues—top challenges just three years ago—had been surpassed by organizational issues in 1999. This study predicted that process and procedural issues would continue to grow in importance as VPNs become more integrated into network infrastructures.

Simplified installation
More robust software is one more nibble into the technical support cost cookie. Streamlined client installation and update is another. Today's IPsec clients require fewer parameters. Through smart defaults, canned policies, and automated policy updating, client installation has become easier and less error-prone. Let's consider a few examples.

eTunnels mails each user a one-time URL to download VPN-On-Demand client software. Each time this IPsec client connects to the company VPN, it must first use SSL to obtain security parameters from the eTunnels Network Server (eNS). Centralized control, simple authentication, and topology assumptions greatly simplify client configuration, but at the cost of flexibility.

IPsec gateways like the Cisco VPN 3060 and Symantec PowerVPN Server automatically pushes administrator-defined policies to IPsec clients each time they connect. Users simply enter gateway hostname and credentials. However, stronger authentication presents the same old challenge: IKE shared secrets are easily mistyped and X.509 certificates are not intuitive to the average end-user.

Check Point's VPN-1 offers automatic version checking to assist in managing client software distribution. Should software updates be automatically pushed for consistency, or applied ad hoc? If ad hoc, how do you ensure client-gateway version synchronization? These procedural decisions still fall to the VPN administrator.

Scalable policy administration
In any large deployment, efficient management and monitoring tools are essential. Policy-based management systems simplify administration of site-to-site VPNs. But sheer volume and frequency of change make remote access administration a tougher nut to crack.

ISPs that offer managed remote access services set the bar even higher. These providers require highly scalable client management systems that support multi-level security policies, delegated user administration, and version control for hundreds of customers, each having perhaps thousands of users.

Vendors like Check Point and WatchGuard market tools specifically designed for managed VPN providers. For example, Check Point's Provider-1 multi-domain policy server can compartmentalize users, rules, and logs for each customer, with automated policy backup and restore. WatchGuard's NOC Control Center provides real-time and historical monitoring, logging, notification, and reporting for managed customer VPNs from one central console.

Over the next few years, we expect to see considerable evolution in large enterprise and carrier-class policy management systems. This past week, Check Point introduced its Next Generation management interface, equipped with a visual policy editor, automated client updates, and predefined policies. Cisco also announced its VPN Security Management (VMS) system—an integrated manager that spans 3000 series concentrators, 7000 series routers, and PIX firewalls.

Go to page 2: Will History Repeat Itself ? >