Non-Sticky Connections

A connection is called sticky if a single Cluster MemberClosed Security Gateway that is part of a cluster. handles all packets of that connection. In a non-sticky connection, the response packet of a connection returns through a different ClusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Member than the original request packet.

The cluster synchronization mechanism knows how to handle non-sticky connections properly. In a non-sticky connectionClosed A connection is called non-sticky, if the reply packet returns via a different Cluster Member, than the original packet (for example, if network administrator has configured asymmetric routing). In Load Sharing mode, all Cluster Members are Active, and 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., a Cluster Member can receive an out-of-state packet, which Firewall normally drops because it poses a security risk.

In Load SharingClosed A redundant cluster mode, where all Cluster Members process all incoming traffic in parallel. For more information, see "Load Sharing Multicast Mode" and "Load Sharing Unicast Mode". Synonyms: Active/Active, Load Balancing mode. Acronym: LS. configurations, all Cluster Members are activeClosed State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism.. 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 ClusterXLClosed Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. has a mechanism to make it sticky.

In High AvailabilityClosed A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA. configurations, all packets reach the Active member, so all connections are sticky. If failoverClosed Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over. 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 connectionClosed A connection is called sticky, if all packets are handled by a single Cluster Member (in High Availability mode, all packets reach the Active Cluster Member, so all connections are sticky)., 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 GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. 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. This diagram shows a sample scenario:

Item

Description

1

Client

2

Security Gateway - Cluster Member A

3

Security Gateway - Cluster Member B

4

Server

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

The synchronization networkClosed A set of interfaces on Cluster Members that were configured as interfaces, over which State Synchronization information will be passed (as Delta Sync packets ). The use of more than one Synchronization Network for redundancy is not supported because the CPU load will increase significantly due to duplicate tasks performed by all configured Synchronization Networks. Synonyms: Sync Network, Secured Network, Trusted Network. notifies Cluster Member B. If Cluster Member B is updated before the SYN-ACK packet sent by the server reaches it, the connection is handled normally. If, however, synchronization is delayed, and the SYN-ACK packet is received on Cluster Member B before the SYN flag has been updated, then the Security Gateway treats the SYN-ACK packet as out-of-state, and drops the connection.

You can configure enhanced 3-Way TCP Handshake enforcement to address this issue (see Enhanced 3-Way TCP Handshake Enforcement).

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 AckClosed Cluster Member forces the Delta Sync packet about the incoming packet and waiting for acknowledgments from all other Active members and only then allows the incoming packet to pass through. In some scenarios, it is required that some information, written into the kernel tables, will be Sync-ed promptly, or else a race condition can occur. The race condition may occur if a packet that caused a certain change in kernel tables left Member_A toward its destination and then the return packet tries to go through Member_B. In general, this kind of situation is called asymmetric routing. What may happen in this scenario is that the return packet arrives at Member_B before the changes induced by this packet were Sync-ed to this Member_B. Example of such a case is when a SYN packet goes through Member_A, causing multiple changes in the kernel tables and then leaves to a server. The SYN-ACK packet from a server arrives at Member_B, but the connection itself was not Sync-ed yet. In this condition, the Member_B will drop the packet as an Out-of-State packet (First packet isn't SYN). In order to prevent such conditions, it is possible to use the "Flush and ACK" (F&A) mechanism. This mechanism can send the Delta Sync packets with all the changes accumulated so far in the Sync buffer to the other Cluster Members, hold the original packet that induced these changes and wait for acknowledgment from all other (Active) Cluster Members that they received the information in the Delta Sync packet. When all acknowledgments arrived, the mechanism will release the held original packet. This ensures that by the time the return packet arrived from a server at the cluster, all the Cluster Members are aware of the connection. F&A is being operated at the end of the Inbound chain and at the end of the Outbound chain (it is more common at the Outbound). Synonyms: FnA, F&A.") 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 readyClosed State of a Cluster Member during after initialization and before promotion to the next required state - Active / Standby / VRRP Master / VRRP Backup (depending on Cluster Mode). A Cluster Member in this state does not process any traffic passing through cluster. A member can be stuck in this state due to several reasons. for the SYN-ACK.