Non-Sticky Connections

A connection is called sticky if all packets are handled by a single cluster member. In a non-sticky connection, the reply packet returns via a different cluster member than the original packet.

The cluster synchronization mechanism knows how to properly handle non-sticky connections. In a non-sticky connection, a cluster member can receive an out-of-state packet, which Firewall normally drops because it poses a security risk.

In Load Sharing configurations, all cluster members are active. In Static NAT and encrypted connections, the source and destination IP addresses change. Therefore, Static NAT and encrypted connections through a Load Sharing cluster may be non‑sticky. Non-stickiness may also occur with Hide NAT, but ClusterXL has a mechanism to make it sticky.

In High Availability configurations, all packets reach the Active member, so all connections are sticky. If failover occurs during connection establishment, the connection is lost, but synchronization can be performed later.

If the other members do not know about a non-sticky connection, the packet will be out-of-state, and the connection will be dropped for security reasons. However, the Synchronization mechanism knows how to inform other members of the connection. The Synchronization mechanism thereby prevents out-of-state packets in valid, but non‑sticky connections, so that these non-sticky connections are allowed.

Non-sticky connections will also occur if the network Administrator has configured asymmetric routing, where a reply packet returns through a different Security Gateway than the original packet.

Non-Sticky Connection Example: TCP 3-Way Handshake

The 3-way handshake that initiates all TCP connections can very commonly lead to a non-sticky (often called asymmetric routing) connection. The following situation may arise as depicted in this illustration:

Client A initiates a connection by sending a SYN packet to server B. The SYN passes through Security Gateway C, but the SYN/ACK reply returns through Security Gateway D. This is a non-sticky connection, because the reply packet returns through a different Security Gateway than the original packet.

The synchronization network notifies Security Gateway D. If Security Gateway D is updated before the SYN/ACK packet sent by server B reaches it, the connection is handled normally. If, however, synchronization is delayed, and the SYN/ACK packet is received on Security Gateway D before the SYN flag has been updated, then the Security Gateway will treat the SYN/ACK packet as out-of-state, and will drop the connection.

You can configure enhanced 3-Way TCP Handshake enforcement to address this issue.

Synchronizing Non-Sticky Connections

The synchronization mechanism prevents out-of-state packets in valid, but non-sticky connections. The way it does this is best illustrated with reference to the 3-way handshake that initiates all TCP data connections. The 3-way handshake proceeds as follows:

1. SYN (client to server)
2. SYN/ACK (server to client)
3. ACK (client to server)
4. Data (client to server)

To prevent out-of-state packets, the following sequence (called "Flush and Ack") occurs

1. Cluster member receives first packet (SYN) of a connection.
2. Suspects that it is non-sticky.
3. Hold the SYN packet.
4. Send the pending synchronization updates to all cluster members (including all changes relating to this packet).
5. Wait for all the other cluster members to acknowledge the information in the sync packet.
6. Release held SYN packet.
7. All cluster members are ready for the SYN-ACK.

Synchronizing Clusters on a Wide Area Network

Organizations sometimes need to locate cluster members in geographical locations that are distant from each other. A typical example is a replicated Data Center, whose locations are widely separated for disaster recovery purposes. In such a configuration, it is clearly impractical to use a cross cable for the synchronization network.

The synchronization network can be spread over remote sites, which makes it easier to deploy geographically distributed clustering. There are two limitations to this capability:

1. The synchronization network must guarantee no more than 100ms latency and no more than 5% packet loss.
2. The synchronization network may only include Layer 2 networking devices - switches and hubs. No Layer 3 routers are allowed on the synchronization network, because routers drop Cluster Control Protocol (CCP) packets.

You can monitor and troubleshoot geographically distributed clusters using the command line interface.

Synchronized Cluster Restrictions

The following restrictions apply when you synchronize cluster members:

• The use of more than one synchronization interface for redundancy is not supported. You can use Link Aggregation for synchronization interface redundancy. Synchronization interface redundancy is not supported for VRRP clusters. See sk92804.
• All cluster members must run on identically configured hardware platforms.
• All cluster members must use the same Check Point software version.
• If a cluster member goes down, user-authenticated connections through that member are lost. Other cluster members cannot restore the connection. Client-authenticated or session-authenticated connections are maintained.

  The reason for these restrictions is that the user authentication state is maintained by a process on the Security Gateway. It cannot be synchronized on cluster members the same way that kernel data is synchronized. However, the states of Session Authentication and Client Authentication are saved in kernel tables, and can be synchronized.

• The connection statutes that use system resources cannot be synchronized for the same reason that user-authenticated connections cannot be synchronized.
• Accounting information for connections is accumulated on each cluster member and sent to the Security Management Server and aggregated. In the event of a failover, accounting information not yet sent to the Security Management Server is lost. To minimize this risk, you can reduce the time interval when accounting information is sent. To do this, in the cluster object > Logs and Masters > Additional Logging pane, set a lower value for the Update Account Log every attribute.

Configuring State Synchronization

Configure State synchronization as part of the process of configuring ClusterXL and OPSEC certified clustering products. Configuring State synchronization involves the following steps:

1. Setting up a synchronization network for the cluster
2. Installing a Security Gateway and enabling synchronization during the configuration process
3. Enabling State Synchronization on the ClusterXL page for the cluster object

For configuration procedures, refer to the sections for configuring ClusterXL and OPSEC certified cluster products.

Configuring a Service Not to Synchronize

To set a service not to synchronize:

1. In the Services branch of the objects tree, double click the TCP, UDP or Other type service that you do not wish to synchronize.
2. In the Service Properties window, click Advanced to display the Advanced Services Properties window.
3. Clear Synchronize connections on the cluster.

Creating Synchronized and Non-Synchronized Versions

It is possible to have both a synchronized and a non-synchronized definition of the service, and to use them selectively in the Security Rule Base.

1. Define a new TCP, UDP and Other type service. Give it a name that distinguishes it from the existing service.
2. Copy all the definitions from the existing service into the Service Properties window of the new service.
3. In the new service, click Advanced to display the Advanced Services Properties window.
4. Copy all the definitions from the existing service into the Advanced Service Properties window of the new service.
5. Set Synchronize connections on the cluster in the new service, so that it is different from the setting in the existing service.

Configuring Duration Limited Synchronization

Before you start this procedure, become familiar with the concept.

Note - This feature is limited to HTTP-based services. The Start synchronizing option is not displayed for other services.

To configure duration limited synchronization:

1. In the Services branch of the objects tree, double click the TCP, UDP or Other type service that you wish to synchronize.
2. In the Service Properties window, click Advanced to display the Advanced Services Properties window.
3. Select Start synchronizing x seconds after connection initiation.
4. In the Seconds field, enter the number of seconds or select the number of seconds from the list, for which you want synchronization to be delayed after connection initiation.