Synchronizing Connections in the Cluster

In This Section: The Check Point State Synchronization Solution Configuring State Synchronization

The Check Point State Synchronization Solution

A failure of a firewall results in an immediate loss of active connections in and out of the organization. Many of these connections, such as financial transactions, may be mission critical, and losing them will result in the loss of critical data. ClusterXL supplies an infrastructure that ensures that no data is lost in case of a failure, by making sure each cluster member is aware of the connections going through the other members. Passing information about connections and other Security Gateway states between the cluster members is called State Synchronization.

Every IP based service (including TCP and UDP) recognized by the Security Gateway is synchronized.

State Synchronization is used both by ClusterXL and by third-party OPSEC-certified clustering products.

Members in a ClusterXL Load Sharing configuration must be synchronized. Members in a ClusterXL High Availability configuration do not have to be synchronized, though if they are not, connections will be lost upon failover.

The Synchronization Network

The Synchronization Network is used to transfer synchronization information about connections and other Security Gateway states between cluster members.

Since the synchronization network carries the most sensitive Security Policy information in the organization, it is critical that you protect it against both malicious and unintentional threats. We recommend that you secure the synchronization interfaces using one of the following strategies:

• Use a dedicated synchronization network
• Connecting the physical network interfaces of the cluster members directly using a cross-cable. In a cluster with three or more members, use a dedicated hub or switch

Note -You can synchronize members across a WAN. To do this, do the steps in Synchronizing Clusters on a WAN.

These recommendations make the synchronization network more secure because no other networks carry synchronization information.

In ClusterXL, the synchronization network is supported on the lowest VLAN tag of a VLAN interface. For example, if three VLANs with tags 10, 20 and 30 are configured on interface eth1, interface eth1.10 may be used for synchronization.

How State Synchronization Works

Synchronization works in two modes:

• Full sync transfers all Security Gateway kernel table information from one cluster member to another. It is handled by the fwd daemon using an encrypted TCP connection.
• Delta sync transfers changes in the kernel tables between cluster members. Delta sync is handled by the Security Gateway kernel using UDP multicast or broadcast on port 8116.

Full sync is used for initial transfers of state information, for many thousands of connections. If a cluster member is brought up after being down, it will perform full sync. After all members are synchronized, only updates are transferred via delta sync. Delta sync is quicker than full sync.

State Synchronization traffic typically makes up around 90% of all Cluster Control Protocol (CCP) traffic. State Synchronization packets are distinguished from the rest of CCP traffic via an opcode in the UDP data header.

Note - The source MAC address for CCP packets can be changed.

Non-Synchronized Services

In a cluster, all connections on all cluster members are normally synchronized across the cluster. Not all services that go through a cluster must be synchronized.

• You can decide not to synchronize TCP, UDP and other service types. By default, all these services are synchronized.
• The VRRP and IP Clustering control protocols, and the IGMP protocol, are not synchronized by default (but you can choose to turn on synchronization for these protocols). Protocols that run solely between cluster members need not be synchronized. Although you can synchronize them, no benefit will be gained. This synchronization information will not help a failover. These protocols are not synchronized by default: IGMP, VRRP, IP clustering and some other OPSEC cluster control protocols.
• Broadcasts and multicasts are not synchronized, and cannot be synchronized.

You can have a synchronized service and a non-synchronized definition of a service, and use them selectively in the Rule Base.

Configuring Services not to Synchronize

Synchronization incurs a performance cost. You may choose not to synchronize a service if these conditions are true:

• A significant amount of traffic goes through the cluster for a service. Not synchronizing the service reduces the amount of synchronization traffic and so enhances cluster performance.
• The service typically opens short connections, whose loss may not be noticed. DNS (over UDP) and HTTP are typically responsible for most connections and frequently have short life and inherent recoverability in the application level. Services that open long connections, such as FTP, should always be synchronized.
• Configurations that ensure bi-directional stickiness for all connections do not require synchronization to operate (only to maintain High Availability). Such configurations include:
  • Any cluster in High Availability mode (for example, ClusterXL New HA or IPSO VRRP).
  • ClusterXL in a Load Sharing mode with clear connections (no VPN or static NAT).
  • OPSEC clusters that guarantee full stickiness (refer to the OPSEC cluster documentation).
  • VPN and Static NAT connections passing through a ClusterXL cluster in a Load Sharing mode (either multicast or unicast) may not maintain bi-directional stickiness. State Synchronization must be turned on for such environments.

Duration Limited Synchronization

Some TCP services (for example, HTTP) are characterized by connections with a very short duration. There is no point in synchronizing these connections because every synchronized connection consumes Security Gateway resources, and the connection is likely to have finished by the time a failover occurs.

For all TCP services, whose Protocol Type (that is defined in the SmartDashboard) is HTTP or None, you can use this feature to delay telling the cluster members about a connection, so that the connection will only be synchronized if it still exists X seconds after the connection is initiated. This feature requires SecureXL to be enabled on all cluster members.

Note - The Delayed Notification setting in the service object is ignored if Connection Templates are not offloaded from the Firewall to SecureXL. For additional information, see the SecureXL documentation.