State Synchronization's Role in High AvailabilityAn application is said to be highly available when you have taken steps to minimize single points of failure. In the mid-1990s, several companies introduced High-Availability (HA) software that provided an infrastructure allowing applications to be monitored on the primary system and "failed over" to a secondary system when a failure was detected . The applications were stored on a shared medium (usually a mirrored disk connected to both systems), and state for the applications had to be stored on the shared disk drive. This allowed the secondary system to pick up where the primary system left off. This setup is historically referred to as a warm standby . Although this was a boon for many companies, it had some drawbacks.
A better way to handle High Availability is to have both systems active at the same time, actively sharing information. In FireWall-1, this can be done with a feature called State Synchronization . State Synchronization is a mechanism in FireWall-1 that allows two firewalls to share information contained within their respective state tables. This allows a firewall to more readily take over in the event of a failure. This condition is referred to as a hot standby . Although State Synchronization preserves most connections, any connections involving the Security Servers will not fail over properly. This is because all Security Server “ related connections actually terminate at a single firewall. It is difficult to fail over connections that terminate at a specific firewall. A Word about LicensingThere is no special license for High Availability, though each gateway must have its own unique firewall license, even in a hot-standby configuration. Check Point typically offers discounts to customers who purchase gateways that will be used in an HA configuration. Node-limited gateway licenses can be used in an HA configuration, though single-gateway products (i.e., firewall plus local management module licenses) cannot. The notable exception to the "no extra licenses" rule is ClusterXL, which requires a separate license. This feature is discussed later in this chapter. The State Synchronization ProtocolState Synchronization occurs via UDP port 8116, or at least that's the way sync appears to work. In reality, State Synchronization is a layer-2 multicast-type protocol that, in many protocol analyzers, looks an awful lot like UDP port 8116 traffic. Packets from the master host use one MAC address; packets from a slave host use a different MAC. Within State Synchronization, there are two modes of operation: full sync and incremental sync. When firewalls begin synchronizing with each other for the first time (e.g., after a reboot or restart of FireWall-1) or after certain events (e.g., a policy install), a full sync is done. This means all tables marked as "sync" on these platforms are synchronized. Depending on how loaded the firewalls are, this can take a lot of communication, and thus time, to accomplish. Once a full sync has been performed, every 100 milliseconds or so, the firewalls simply exchange the "changes" that have occurred since the last full sync. This is an incremental sync. In most cases, FireWall-1 operates in this mode. Configuring State SynchronizationIn FireWall-1 4.1 and earlier releases, synchronization was configured in $FWDIR/conf/sync.conf . This meant you could tie any two firewalls together, whether or not they ran the same security policy. In FireWall-1 NG, synchronization is now configured in a gateway cluster object. This makes sense because a gateway cluster is designed to treat two or more firewalls as if they were one. Ensuring all the cluster members have the same state information allows the cluster members to act as a single gateway. You can create a gateway cluster object from the objects tree by clicking on the Network Objects icon, right-clicking New Check Point, and selecting Gateway Cluster. Alternatively, you can select Network Objects from the Manage menu, click on New, select Check Point, and then select Gateway Cluster. You will see a screen similar to Figure 13.1. Figure 13.1. Gateway Cluster Properties, General Properties frame
Configuring a gateway cluster object is similar to configuring a standard gateway object, so I cover only the differences in the procedures here. Options you might configure in this object apply to all members of the cluster. For your gateway cluster object, you should use an IP address that addresses the "virtual" firewall. All of the supported HA schemes, including Check Point HA, Virtual Router Redundancy Protocol (VRRP), Nokia IP Clustering, Rainfinity, and Stonebeat have some sort of concept of a virtual IP address. The active firewall will respond to packets sent to this virtual IP address. In a load-balanced configuration, multiple firewalls may be active at the same time, but only the appropriate firewall will respond. When a failover occurs, a different firewall will respond. Figure 13.2 shows the Cluster Members frame, where you configure which gateways are part of your gateway cluster. Figure 13.2. Gateway Cluster Properties, Cluster Members frame
WARNING!
The 3rd Party Configuration frame, shown in Figure 13.3, allows you to configure whether this cluster is an HA cluster (i.e., active-standby) or a Load Sharing (active-active) cluster. On a Nokia platform, regardless of whether you use VRRP or IP Clustering, the cluster type is High Availability. If you use ClusterXL, it is a Load Sharing configuration. Figure 13.3. Gateway Cluster Properties, 3rd Party Configuration frame
Other options on this screen include those listed below.
Figure 13.4 shows the Synchronization frame, where you configure which network will be used for State Synchronization. Add a network name (choose a name that doesn't match a network object name ), an IP address, and a netmask . The chosen network should be a dedicated network segment, that is, one not used for other kinds of traffic (including traffic used by Nokia IP Clustering, which should be on its own dedicated segment). Figure 13.4. Gateway Cluster Properties, Synchronization frame
WARNING!
What Are the Limitations of State Synchronization?You should be aware that State Synchronization happens approximately every 100 milliseconds. All changes in the state table since the last sync interval are sent to the peer firewalls. It also takes roughly 55 milliseconds for these changes to be incorporated into the state tables. This means it takes a minimum of 155 milliseconds for the peer firewall to be updated. The actual amount of time varies based on system load. What does this delay in synchronization mean? The long and the short of it is this: If one firewall receives a TCP SYN packet and the other firewall receives a corresponding TCP SYN/ACK packet before the synchronization actually occurs, you will end up dropping or severely delaying the establishment of the TCP connection. This is a condition known as asymmetric routing , which is discussed in its own subsection below. Some other important restrictions concerning State Synchronization include those listed below.
|