Synchronizing Connections in the Cluster

In This Section: The Check Point State Synchronization Solution

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.

Members of a ClusterXL in Load Sharing mode must be synchronized.

Members of a ClusterXL High Availability mode do not have to be synchronized. Although if they are not, current connections are interrupted during cluster failover.

The Synchronization Network

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

The synchronization network carries the most sensitive Security Policy information in the organization. Therefore, 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.

Notes:

• See Supported Topologies for Synchronization Network.
• You can synchronize members across a WAN. To do this, do the steps in Synchronizing Clusters on a WAN.
• 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, only 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. The fwd daemon handles the Full Sync using an encrypted TCP connection on port 256.
• Delta Sync transfers changes in the kernel tables between Cluster Members. The Security Gateway kernel handles the Delta Sync using UDP connections on port 8116.

Full Sync is used for initial transfers of state information, when a Cluster Member joins the cluster. If a Cluster Member is brought up after being down, it performs the Full Sync with the Active peer Cluster Member(s). After all Cluster Members are synchronized, only updates are transferred using the Delta Sync, because the Delta Sync is quicker than the Full Sync.

State Synchronization traffic typically makes up around 90% of all Cluster Control Protocol (CCP) traffic. Cluster Members distinguish the State Synchronization packets from the rest of CCP traffic based on the opcode in the UDP data header.

Note - You can change the source MAC address for CCP packets. See sk25977.

Configuring Services to Synchronize After a Delay

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

For short-lived services, you can use the Delayed Notifications feature to delay telling the Cluster Member about a connection, so that the connection is only synchronized, if it still exists X seconds after the connection was initiated. The Delayed Notifications feature requires SecureXL to be enabled on all Cluster Members.

Procedure:

1. In SmartConsole, click Objects > Object Explorer.
2. In the left tree, click the small arrow on the left of the Services to expand this category
3. In the left tree, select TCP.
4. Search for the applicable TCP service.
5. Double-click the applicable TCP service.
6. In the TCP service properties window, click Advanced page.
7. At the top, select Override default settings (on Domain Management Server: Override global domain settings).
8. At the bottom, in the Cluster and synchronization section, select Start synchronizing and enter the desired value.

   Important - This change applies to all policies that use this service.

9. Click OK.
10. Close the Object Explorer.
11. Publish the session.
12. Install the Access Control Policy on the cluster object.

Note - The Delayed Notifications setting in the service object is ignored, if Connection Templates are not offloaded by the Firewall to SecureXL. For additional information about the Connection Templates, see the R80.20 Performance Tuning Administration Guide.

Configuring Services not to Synchronize

Synchronization of connections incurs a performance cost. Not all connections that go through a cluster must be synchronized:

• Protocols that run solely between Cluster Members need not be synchronized. Although, you can synchronize them, you go not gain any benefit. This synchronization information does not help during a cluster failover.
• You can decide not to synchronize TCP, UDP and other service types. By default, Cluster Members synchronize all these services.
• The VRRP and the IGMP protocols are not synchronized by default (but you can choose to turn on synchronization for these protocols).
• Broadcast and multicast connections are not, and cannot be, synchronized.

You may choose not to synchronize a service if these conditions are true:

• A significant amount of traffic goes through the cluster. 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, 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 High Availability, or VRRP on Gaia).
  • ClusterXL in a Load Sharing mode with clear connections (no VPN, or Static NAT).
  • 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.

You can have a synchronized service and a non-synchronized definition of a service, and use them selectively in the Rule Base. For more information, see the R80.20 Security Management Administration Guide.

To configure a service not to synchronize in a cluster

1. In SmartConsole, click Objects > Object Explorer.
2. In the left tree, select Services.
3. Double-click the applicable existing synchronized service, for which you need to create a non-synchronized counterpart service.
4. Write down all the settings from both the General and Advanced pages, and click OK.
5. Click New > Service > desired service type.
6. Enter the desired name that distinguishes the new non-synchronized counterpart service from the existing synchronized service.
7. On the General page, configure the same settings as in the existing synchronized service.
8. On the Advanced page:
   1. Configure the same settings as in the existing synchronized service.
   2. In the Cluster and synchronization section, clear Synchronize connections if State Synchronization is enabled on the cluster.

      Important - This change applies to all policies that use this service.

9. Click OK.
10. Close the Object Explorer.
11. Use the synchronized service and the non-synchronized counterpart service in the applicable rules in the applicable Access Control Policies.
12. Publish the session.
13. Install the Access Control Policy on the cluster object.