Unlike LAN-to-LAN VPNs, an IPsec (IP security) VPN is particularly onerous (for more on IPsec interoperation, see "Making IPsec Work for You," at www.networkcomputing.com/922/922ws2.html). Although the core IPsec protocols are standardized, widely supported and interoperable, problems with remote-access support, such as remote-user authentication and client configuration, make client IPsec VPN interoperability difficult to implement and support.

A new IETF working group, IPSRA (IPsec Remote Access), is addressing secure remote access. The group is working on several drafts focused on client network configuration and authentication. These protocol drafts (which can be found at www.ietf.org/html. charters/ipsec-charter.html) are still in the early stages, with some interoperability work being done. Certain products, including Cisco Systems' IOS, IRE's SafeNet line and Newbridge Networks Corp.'s 130 Secure VPN Client (formerly TimeStep Permit/Client), are shipping with these new protocols, but we expect wider adoption next quarter and throughout the year. And the IETF isn't forging ahead alone. Microsoft Corp. is in the fray with Windows 2000 and L2TP (Layer 2 Tunneling Protocol) secured by IPsec.

Although IPsec products can use certificates during negotiation, a number of interoperability issues limit certificate use to single-vendor environments. Multivendor situations call for preshared IKE, which uses a secret, or password, to mutually authenticate IPsec devices. Because preshared secrets need to be distributed and managed, this solution isn't as secure or scalable as certificates, but preshared secret IKE is a viable alternative for limited-size implementations.

For this workshop, we used shipping products--including Cisco's 4700 with IOS 12.0(2a)T1, Newbridge's 234 Secure VPN Gateway (formerly TimeStep Permit/Gate 4520), IRE's SoftPK 2.1.0 (Build 15) and F-Secure Corp.'s VPN+--to see just what interoperable IPSec means and what you need to make it happen. Setting the Policy
Using an IPsec VPN solution from a single vendor has many advantages: Vendors can support more options in a proprietary fashion than are currently supported as standards. Client network configuration, remote-user authentication and data compression all are implemented in numerous solutions. But these advantages disappear in a multivendor environment. IPsec vendors recognize the need to interoperate and support the standards, but they also need to meet customer demands. So just forget about automatic configuration for the moment. It may be possible to create and distribute profiles to your end users, but doing so is vendor-dependent. As we all know, manual configuration doesn't scale beyond a handful of users.

Setting up client IPsec VPN is similar to setting up a LAN-to-LAN VPN. Security and networking parameters must match on both ends. We created a very simple network with a Newbridge 130 Secure VPN Client and a SoftPK client, both of which talked to the Cisco router and 234 Secure VPN Gateway (see "Network Map" on to the right). Our security policy was simple: All connections passing from the public network to the private network were to be secured with ESP (Encapsulating Security Payload) using 3DES encryption and MD5 authentication. Setting up the Cisco router and Newbridge 130 Secure VPN Client/234 Secure VPN was a snap. The only problem was that each peer name and shared secret, which function as a user name/password for each individual client, had to be entered manually. Currently, the only supported peer name in interoperable preshared secret VPN devices is the host IP address, and knowledge of the corresponding shared secret ensures authentication.

Once our VPN gateways were properly configured, we set up the clients. Although manually configuring IPsec isn't difficult for users familiar with IPsec and networking, those unfamiliar with the underpinnings of IPsec will need more support. The goal is to match the security proposals and network addresses for both IKE and IPsec with the accepted VPN gateway proposals. Typically you need only one security policy definition on the client that contains all the acceptable security configurations. For example, a remote user may need to use 3DES with HMAC-MD5 when forming a VPN with the corporate network, but a trading partner requires DES with HMAC-MD5. When the client negotiates the VPN, it will send both proposals to the remote IPsec device. The remote IPsec device will typically select the first proposal it finds acceptable--so order is important. Once the security profile is defined, the destination network and gateway must be defined.

Configuration may become confusing when it comes to IP addressing. IP addresses are used to identify the SA (Security Association) to which an incoming packet belongs. An ID or destination address can be a host address or a subnet address. If the addresses of the two IPsec devices do not match correctly, the IPsec phase two negotiation may fail. The IPsec client will use the desktop's IP address as its identity by default, but the remote destination address must be configured manually. Vendors are flexible in their ID syntax implementations, so make sure your specific products let you dictate your syntax. In some IPsec VPN gateways, 10.1.1.1/24 may not equal 10.1.1.1/255.255.255.0, even though logically these statements seem equivalent, because the latter uses a fully qualified IP address/ subnet mask pair while the former uses shorthand. Using identical IP address/ subnet mask pairs in the IPsec VPN is always best.