LANs /

High availability's dark side

By Joel Snyder
Network World, 12/11/00

The problem with high availability is that it generally tries to make more than one system look like a single box: one IP address, one media access control address. Unfortunately, the growth of LAN switching power has complicated the lives of high-availability products tremendously.

The difficulty comes when you connect high-availability VPN systems to a single LAN Layer 2 or Layer 3 switch. LAN switches don't like to see the same MAC address on multiple ports --- that's a network loop, and one of the ports has to be shut down. To work around this, every high-availability vendor has some technique to keep the network happy while doing high-availability magic.

User study: VPN services save money despite stalled implementation
Virtual Private Networks: Viable Products Now
Buyer's Guide: Interactive database
Review: Pure hardware VPNs rule high-availability tests
Subscribe to the VPN e-mail newsletter

A simple solution to the LAN switch plus high-availability problem is to do away with the switch: plug your high-availability gear into a hub, and then plug the hub into a switch. Unfortunately network managers have become so enamored of their 100M bit/sec switch-to-the-port gear that hubs are just not in their tool kits any more. As NetScreen's Gregory Lebovitz told us, "If I told a customer that they had to use a hub, they'd throw us out of there in a heartbeat."

For our testing, we used a lot of hubs so we wouldn't have to go through a switch reconfiguration for each product. But when you decide to install your high-availability VPN gear, be prepared to spend some time with your vendor's technical support team (and the manuals for your LAN switch) to get it right.

Check Point's answer was even less satisfactory: all of their high-availability partners' solutions use noncompliant IP Security (IPSec). This makes high availability VPN solutions based on Check Point's VPN-1 proprietary security protocol incompatible with pure IPSec --- they'll work with Check Point products, but anyone strictly adhering to the letter of the IPSec law won't be able to talk to a Check Point high-availability cluster.

Check Point acknowledged this issue and told us that it plans to fix it with the next release of VPN-1 in 2001.

Check Point solves the IP and MAC address problem by stepping around it. In the middle of a VPN negotiation, Check Point will hand off the connection to one of the nodes in the high availability cluster, and that node will start using its own unique IP and MAC address. There is no problem with LAN switches because everything is behaving like a normal IP node. Everything but the IPSec part, of course, which doesn't let you change IP addresses in the middle of a transaction.

We queried the authors of the IPSec request for comment about this and got a resounding vote of no-confidence for Check Point's strategy: it may be high availability, but it's not RFC-compliant IPSec. We also discovered in talking to Check Point partner Rainfinity (the first VPN-1- based solution we tested) that it had never tested its solution with anything but Check Point products. We successfully gained interoperability between the various Check Point partners, however, and had our Rainfinity cluster talk to the Stonesoft cluster and then to the Foundry Networks cluster easily.

The benefit of Check Point's strategy, though, is that they can jump beyond the 100M bit/sec limit (200M bit/sec if you count full-duplex) for Fast Ethernet. Radguard, Nokia, NetScreen and Alcatel are limited to what you can pump down a single Fast Ethernet pipe.

With Check Point passing connections off to nodes with unique IP and MAC addresses, the cluster can go beyond that limit. NetScreen has its own solution with its higher-end NetScreen-1000, which supports Gigabit Ethernet; Nokia said it will be shipping its Gigabit Ethernet hardware after the first of the year.

Radguard was unapologetic about its high-availability strategy, which also depends on a proprietary technique. However, Radguard points to Check Point's approach as reducing total security, by not following the IPSec specifications and by exposing sensitive keying material in the connection between two Check Point VPN-1 nodes. All the devices but Radguard have a similar "shortcoming;" they share state information about the IPSec connection to support failover. Radguard doesn't like the idea of having this information travel over the wire, so it set up a proprietary technique providing two Security Associations for every one it needs: one to the master device and one to a slave. When the master goes offline, the Radguard system simply switches over to the slave. Because the connection was set up ahead of time, the switchover can happen quickly. In effect, Radguard takes its high-availability penalty upfront, by setting up the IPSec Security Association to the back-up device (slave) at the start.