Sticky Connections
Introduction to Sticky Connections
A connection is considered sticky, when all of its packets are handled, in either direction, by a single Cluster Member Security Gateway that is part of a cluster..
This is the case in High Availability 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. mode, where all connections are routed through the same Cluster
Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Member, and hence, are sticky.
This is also the case in Load Sharing 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. mode, when there are no VPN peers, Static NAT rules, or SIP traffic.
In Load Sharing mode, there are cases, where it is necessary to ensure that a connection that starts on a specific Cluster Member will continue to be processed by the same Cluster Member in both directions. Certain connections can be made sticky by enabling the Sticky Decision Function A special cluster algorithm applied by each Cluster Member on the incoming traffic in order to decide, which Cluster Member should process the received packet. Each Cluster Members maintains a table of hash values generated based on connections tuple (source and destination IP addresses/Ports, and Protocol number). in the cluster object in SmartConsole
Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on..
The Check Point Cluster Correction Layer (CCL) deals with asymmetric connections in Check Point cluster.
VPN Tunnels with 3rd Party Peers and Load Sharing
Check Point provides interoperability with third-party vendor gateways by enabling them to peer with Check Point Security Gateways. A special case occurs when certain third-party peers (for example, Microsoft LT2P, Cisco gateways) attempt to establish VPN tunnels with ClusterXL 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. in Load Sharing mode. These VPN peers are limited in their ability to store SAs, which means that a VPN session that begins on one Cluster Member and, due to Load Sharing, is routed on the return trip through another Cluster Member, is unrecognized and dropped.
Item |
Description |
---|---|
1 |
Internal network |
2 |
Switch for internal network |
3 |
ClusterXL in Load Sharing mode - Cluster Members "A" and "B" |
4 |
Switch for external networks |
5 |
Internet |
6 |
3rd party peer VPN Gateway |
7 |
3rd party peer laptop with VPN client |
In this scenario:
-
A third-party peer (gateway or client) attempts to create a VPN tunnel.
-
Cluster Members "A" and "B" belong to a ClusterXL in Load Sharing mode.
The third-party peers, lacking the ability to store more than one set of SAs, cannot negotiate a VPN tunnel with multiple Cluster Members, and therefore the Cluster Member cannot complete the routing transaction.
This issue is resolved for certain third-party peers or gateways that can save only one set of SAs by making the connection sticky. The Cluster Correction Layer Proprietary Check Point mechanism that deals with asymmetric connections in Check Point cluster. The CCL provides connections stickiness by "correcting" the packets to the correct Cluster Member: In most cases, the CCL makes the correction from the CoreXL SND; in some cases (like Dynamic Routing, or VPN), the CCL makes the correction from the Firewall or SecureXL. Acronym: CCL. (CCL) makes sure that a single Cluster Member processes all VPN sessions, initiated by the same third-party gateway.
Third-Party Gateways in Hub and Spoke VPN Deployments
Another case, where Load Sharing mode requires the connection stickiness, which the Cluster Correction Layer (CCL) provides, is when integrating certain third-party gateways into a Hub and Spoke deployment. Without the ability to store more than one set of SAs, a third-party gateway must maintain its VPN tunnels on a single Cluster Member in order to avoid duplicate SAs.
Item |
Description |
---|---|
1 |
Security Gateway |
2 |
Security Gateway - Cluster Member B |
3 |
Switch for external networks |
4 |
Internet |
5 |
Gateway - Spoke A |
6 |
Gateway - Spoke B |
In this sample deployment:
-
The intent of this deployment is to enable hosts that reside behind Spoke A to communicate with hosts behind Spoke B.
-
The ClusterXL in Load Sharing mode, is composed of Cluster Members "A" and "B", and serves as a VPN Hub.
-
Spoke A is a third-party gateway, and is connected by a VPN tunnel that passes through the VPN Hub to Spoke B.
-
Spoke B can be either another third-party gateway, or a Check Point Security Gateway.
Spokes A and B must be set to always communicate using the same Cluster Member. The Cluster Correction Layer (CCL) solves half of this problem, in that a single Cluster Member processes all VPN sessions initiated by either third-party gateway.
To make sure that all communications between Spokes A and B are always using the same Cluster Member, you must make some changes to the applicable user.def file (see sk98239). This second step ensures that both third-party gateways always connect to the same Cluster Member.
Configuring a Third-Party Gateway in a Hub and Spoke VPN Deployment
To configure a third-party gateway as a spoke in a Hub and Spoke VPN deployment, perform the following on the Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server.:
-
Create a Tunnel Group to handle traffic from specific peers. Edit the applicable user.def file (see sk98239), and add a line similar to the following:
all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>};
The elements of this configuration are as follows:
-
all - All cluster interfaces
-
member1,member2 - Names of Cluster Members in SmartConsole
-
vpn_sticky_gws - Table name
-
10.10.10.1 - IP address of Spoke A
-
20.20.20.1 - IP address of Spoke B
-
;1 - Tunnel Group Identifier, which indicates that the traffic from these IP addresses should be handled by the same Cluster Member
-
-
Other VPN peers can be added to the Tunnel Group by including their IP addresses in the same format as shown above. To continue with the example above, adding Spoke C would look like this:
all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>, <30.30.30.1;1>};
The Tunnel Group Identifier ;1 stays the same, which means that the listed peers will always connect through the same Cluster Member.
Note - More tunnel groups than Cluster Members may be defined.
This procedure turns off Load Sharing for the affected connections. If the implementation is to connect multiple sets of third-party gateways one to another, a form of Load Sharing can be accomplished by setting Security Gateway pairs to work in tandem with specific Cluster Members. For instance, to set up a connection between two other spokes (C and D), simply add their IP addresses to the line and replace the Tunnel Group Identifier ;1 with ;2. The line would then look something like this:
all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>, <192.168.15.5;2>, <192.168.1.4;2>,};
Note that there are now two peer identifiers: ;1 and ;2. Spokes A and B will now connect through one Cluster Member, and Spokes C and D through another.
Note - The tunnel groups are shared between active
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. Cluster Members. In case of a change in cluster state (for example, failover
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. or Cluster Member attach/detach), the reassignment is performed according to the new state.