Other High Availability Methods

So far, this chapter has discussed some generic high availability configurations, and has only mentioned using the Check Point HA and Load Sharing modules.

There are, however, other ways to create high availability. Many vendors have developed HA solutions for Check Point VPN-1/FW-1, and some of them are very good. A popular choice is RainWall from Rainfinity (www.rainfinity.com).

Hardware products can also be employed to provide the load sharing and high availability between firewalls. One notable hardware solution is the Foundry ServerIron XL content switch. This product was the first to be OPSEC-certified to provide full failover support, including the failover of active VPN sessions. ServerIron also supports clustering and synchronization of its load balancers, so that they are not a single point of failure. Also, the configuration commands for this switch are nearly identical to those of the Cisco IOS, which makes the learning curve simpler. You can see a full listing of Check Point OPSEC-certified products at www.opsec.com. Discussion of the configuration for each of these products is beyond the scope of this book and is best obtained directly from the vendor.

Routing Failover

Another failover method is to use a routing protocol to handle moving traffic around a downed firewall. The most popular method of implementing this is by using the Virtual Router Redundancy Protocol. Numerous platforms currently support VRRP, including the Nokia appliance. For those readers with a networking background, think of VRRP as a takeoff on HSRP.. The firewall software will have to take over the duties of synchronization, but that s not unusual to the HA solutions we ve looked at.

Configuration of VRRP is outside the scope of this text, but we can discuss some of the more general points that you ll be dealing with. First, you need to decide which version of VRRP you want to implement. There are two versions in common use: VRRP v2 and VRRP Monitored Circuit. Unless you have a pressing need to use VRRP v2 (address-space exhaustion, backward compatibility, etc.), you should opt for Monitored Circuit. In either of these configurations, you may experience problems with asymmetric routing. One of the main differences in v2 and Monitored Circuit is the convergence time, that is, the time it takes for a failure to be detected and corrected. In earlier versions of IPSO, convergence time could be over eight seconds. Using Monitored Circuit, the convergence time is less than one second. Like HSRP, VRRP uses HELO messages, sent at a default interval of one second, to a multicast destination (which must be allowed in the rulebase) to announce their status. This HELO message includes a priority, which is used to determine which gateway should be the active member of the cluster. If the primary machine detects a failed interface, for example, it would decrement its priority, thus notifying the backup gateway to take over the cluster. Remember to include all of the firewall interfaces in the tracking list. It wouldn t do much good if the outside interface was down, but not tracked, and the inside interface was still taking traffic.

A more complete discussion of VRRP is available in the Check Point NG VPN-1/FireWall-1: Advanced Configuration and Troubleshooting book published by Syngress as well as the Nokia Network Security book.

For other routing-based configurations, in NG with Application Intelligence, Route Injection into your internal routing infrastructure based on VPN Tunnel availability was added (referred to as the Route Injection Module or RIM). And in NG with Application Intelligence R55, ISP redundancy was also introduced for SecurePlatform and Nokia IPSO.