The Remote Access Conundrum Part 4:
VPN Client Administration—continued

Will History Repeat Itself ?

Like after-market TCP stacks, add-on IPsec clients may someday become a relic of the past. Microsoft Windows Dial-up Networking has been shipping with an embedded PPTP client for a couple of years. Last March, Windows 2000 shipped with both PPTP and L2TP/IPsec clients. If Redmond has its way, you won't have to worry about VPN client software installation much longer.

Conceptually, embedded clients are attractive. Say what you will about monopolies, but integrated TCP has greatly simplified getting on-line. Integrated IPsec promises to simplify software administration and reduce permutations that interfere with compatibility and interoperability.

To realize this promise, IPsec gateway vendors must test their own products against embedded VPN clients and make changes for interoperability. Many vendors, including CoSine, Spring Tide, and NetScreen, now support the Windows L2TP/IPsec client.

On the flip side, embedded clients may not embrace value-added features developed by other vendors. Will other IPsec vendors—particularly remote access concentrator vendors—abandon value-added VPN clients? At least in the near term, the answer is almost certainly "no." Factors include support for other desktop operating systems, migration issues, and product differentiation.

Embedded clients no silver bullets
To better understand what embedded clients can and cannot offer, let's take a brief look at the Windows 2000 VPN client.

In Windows 2000, remote access VPN connections are configured with Dial-up Networking. Microsoft's Connection Manager can be used to centrally-define and push connection parameters to clients. By default, VPN connections attempt L2TP first, and then fall back to PPTP.

When L2TP is selected, Windows 2000 uses IPsec underneath to encrypt tunneled PPP. The default IPsec policy permits DES-encrypted, MD5-authenticated traffic from port 1701 (L2TP) to any destination. Other IPsec policies can be configured with Microsoft Management Console (MMC) snap-ins.

Instead of distributing add-on VPN software, Windows 2000 administrators distribute X.509 certificates. To connect with L2TP/IPsec, each Windows 2000 client must be configured with its own machine certificate, created with the Windows 2000 CA or a third-party CA. PPP user-level authentication occurs after IKE machine-level authentication is successful.

In short, Windows 2000 provides a ready foundation, but embedded software does not eliminate VPN client administration. You still have to administer security policies, machine-level certificates, and user-level credentials.

Parting thoughts
So, how can ISPs reduce the complexity and cost of VPN client administration?

• Choose a VPN client that comes as close as possible to requiring zero end-user expertise. Seek out features like canned policies and automated push updates to remove the end-user from the equation. Doing so will reduce support calls and increase subscriber satisfaction.
• Test your VPN client in every desktop environment you plan to support. Document environmental requirements, supported adapters, and compatibility issues. Nobody likes to waste time debugging a combo already known to be problematic.
• Efficient VPN administration requires more than a homegrown database, accessed by RADIUS or LDAP. Invest your time in software administration and policy management tools from the start. With the right infrastructure in place, you'll be able to scale with your customer base.
• Develop formal policies and procedures for VPN client administration. Auto-update features and policy-based management systems are only tools. Applying them wisely and consistently is up to you.
• As embedded VPN clients become more widely deployed, leverage them. But remember: if you try to dictate the operating system used by subscribers, you'll end up with a smaller market. Support add-on clients for older operating systems, and draw the line somewhere to avoid spreading your support staff too thin.

Finally, deploy IPsec remote access where the fit is good, but don't overlook other alternatives to minimize client administration. Subscribers that don't need confidentiality can use compulsory-mode L2TP. Customers that require only a secure web portal may be satisfied with a hosted site, ordinary browsers, and SSL encryption. Secure teleworker access to corporate desktops can be accomplished with browser-based remote control services offered by ExpertCity and uRoam. Be creative.

There are many ways to address the remote access VPN market. We hope this series has provided insight into some of the challenges and solutions associated with offering IPsec-based remote access services.

—End

Back to page 1:
< The Remote Access Conundrum Part 4: VPN Client Administration

   

Related articles:
	The Remote Access Conundrum Series:
	[Jan. 5, 2000]	Part 1: Extended Authentication
	[Dec. 20, 2000]	Part 2: Tunneling at Layer Two
	[Feb. 8, 2001]	Part 3: Dynamic Addressing
	[Mar. 15, 2001]	Part 4: VPN Client Administration