our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

In one of our Real-World Labs® at Syracuse University, we set up IPSec tunnels based on preshared secrets, with Check Point Software Technologies' FireWall-1 4.0, Shiva Corp.'s LanRover VPN Gateway, TimeStep Corp.'s Permit 4520 and VPNet Technologies' VSU-1010 V2.0b25. While we were able to get all these products to communicate, doing so was neither simple nor robust. Numerous issues popped up along the way, including basic tunnel construction when tunneling across subnets. We also ran into configuration issues, largely specific to implementation, in determining particular control parameters of the IPSec protocol. While irrelevant in a single-vendor implementation, these issues matter in a multivendor setup, where tunnel establishment goes from asymmetric to utter failure.

Bear in mind there are proprietary features that you may give up in a multivendor environment. VPNet's VSU1010, for one, supports Stac compression, but only within VPNet's environment. And while unified management seems to be an issue, one goal of a VPN (virtual private network) is to connect separate organizations securely for extranet access across the Internet, so you would only manage one side of the VPN anyway.

You should also remember that IPSec is an evolving standard. Though interoperation is possible, it's not exactly an elegant configuration. In the coming months, the ICSA will begin certifying IPSec version 1.1, which adds support for advanced features such as certificate authorities and IPSec tunnels for variable subnets. It is possible to obtain non-ICSA-certified products to interoperate, though the vendors won't guarantee stable results. In our testing, Shiva's LanRover VPN Gateway (not ICSA-certified at the time of this writing) interoperated very well, though we did run into a few small anomalies.

In general, IPSec tunnels are configured on each IPSec gateway by defining the two endpoints (or subnets), the encryption and authentication algorithms used, and the preshared secret each IPSec gateway in the VPN is to use. This information must match exactly for the gateway to negotiate successfully. For single-host VPNs, the configuration is straightforward; it gets more complex for subnets.

Subnet-Specific Problems Tunneling subnets poses a particular problem because of the way IDs are handled during IPSec negotiation. All IP addresses for the protected networks must be formatted exactly or the Quick Mode negotiation fails because of an unknown ID (see "The Many Modes of IPSec With IKE," on page 112). When protecting a single host, such as 10.2.2.5, the configuration of the two gateways are fairly straightforward. During the IKE security association (SA) negotiation, the IPSec gateways pass their own IP addresses as IDs. But during Phase 2, the IP addresses of the device or devices being protected are used as the ID. For example, creating a VPN to pass traffic between 10.2.2.5 and 10.3.3.5 (see "VPN Network Map," at left), TimeStep's Permit was configured to secure traffic from 10.2.2.5. We configured Permit to send all traffic for 10.3.3.5 to the VSU1010. During Quick Mode, Permit sent 10.2.2.5 as the ID while VSU sent 10.3.3.5. To set up the entire subnet, both the subnet address and the subnet mask pairs on each VPN gateway must be precisely defined.