Variable subnet masks such as 10.2.2.5/255.255.255.252 will not work at the current IPSec revision. To segment subnets into specific VPNs, you must be in a single-vendor environment or wait for ICSA 1.1-based products.

Shiva's LanRover VPN Gateway is the exception. We configured the product to build a VPN between the subnet 10.1.1.0/255.255.255.0 and the host 10.2.2.5 and configured Permit to build a VPN between the host 10.3.3.5 and the host 10.1.1.5/255.255.255.255 (see "Asymmetric VPN" above). This configuration should fail. However, we found we could ping from 10.2.2.5 to any IP address behind the Shiva, but could only ping 10.2.2.5 behind the Permit 4520. This asymmetry is specific to the Shiva-Permit combination and highlights the pitfalls of a multivendor setup.

While the network behind the Permit remained secure, the network behind the Shiva was wide open. Reconfiguring the Shiva with a local address of 10.1.1.5/255.255.255.255 allowed access to only that host. The network addresses must be used as the IDs in a Quick Mode exchange, but how to use those IDs, for security purposes, is up to each vendor. At testing time, this configuration worked with Permit, but not with VSU.

Policy Issues There are two policy paradigms available: device-specific, in which the security policy is defined for the VPN gateway; and VPN-specific, where the policy is defined for a single VPN. The policy paradigm implemented by Check Point, Shiva and VPNet specify security parameters on a per-VPN basis; TimeStep defines policies for the device.

The benefit of a per-VPN policy paradigm means you specifically define the parameters for each VPN site. Typically, this means the VPN will propose or accept only one set of security parameters for each tunnel. For example, within the United States, you can use 3DES encryption and its longer key length, but if you want secure VPNs internationally, you're limited to DES 56, with its shorter key length.

Device-based policies offer greater management scalability, but require you to be more careful when constructing your policies. For example, TimeStep's Permit Enterprise lets you specify multiple security policies for a single device. When a remote site sends a proposal during the initial IKE negotiation, Permit Enterprise checks to see if the proposal is acceptable and acts accordingly. When Permit initiates a VPN, it sends multiple proposals from which the remote site selects. The selection process is vendor-specific. Permit will search its list of proposals, in top-down fashion, and pick the first match.

From a policy perspective, you must set boundaries on the minimal set of security requirements necessary to secure communications from behind a gateway; for inbound connections, the sender can propose any set of parameters. If any parameters meet your policy, the proposal will be accepted.

Getting to know each vendor's implementation and conventions is the first step in getting a multivendor VPN up and running. Often, the biggest difficulty is learning the nomenclature. And IPSec VPN connections are encrypted early in the negotiation process, so forget about conventional methods of protocol tracing.

Specifically, know your vendor's logging facilities. Turn on as much debugging as possible while setting up your VPNs and turn it off when you're up to speed. Test your VPN sessions in both directions: asymmetric VPN configurations are possible and can lead to obscure problems. Determine if your gateway defaults to Main Mode or Aggressive Mode during IKE negotiation. TimeStep defaults to Aggressive mode; if your other gateway is expecting Main Mode, the VPN may not be formed. Set the appropriate rekeying times for both IKE and IPSec.

Send your comments on this article to Mike Fratto at mfratto@nwc.com.