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.
This is the case in High Availability mode, where all connections are routed through the same Cluster Member, and hence, are sticky.
This is also the case in Load Sharing 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 in the cluster object in SmartConsole.

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 gateways. A special case occurs when certain third-party peers (for example, Microsoft LT2P, Cisco gateways) attempt to establish VPN tunnels with ClusterXL 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 (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 - Cluster Member A
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:

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 Security 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 Cluster Members. In case of a change in cluster state (for example, failover or Cluster Member attach/detach), the reassignment is performed according to the new state.