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, sticky. This is also the case in Load Sharing mode when there are no VPN peers, static NAT rules or SIP.

In Load Sharing mode, however, 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. To that end, certain connections can be made sticky by enabling the Sticky Decision Function.

The Sticky Decision Function

The Sticky Decision Function enables certain services to operate in a Load Sharing deployment. For example, it is required for L2TP traffic, or when the cluster is a participant in a site to site VPN tunnel with a third party peer.

The following services and connection types are now supported by enabling the Sticky Decision Function:

• VPN deployments with third-party VPN peers
• SecureClient/SecuRemote/SSL Network Extender encrypted connections, including SecureClient visitor mode

The Sticky Decision Function has the following limitations:

• Sticky Decision Function is not supported when employing either Performance Pack or a hardware-based accelerator card. Enabling the Sticky Decision Function disables these acceleration products.
• When the Sticky Decision Function is used in conjunction with VPN, cluster members are prevented from opening more than one connection to a specific peer. Opening another connection would cause another SA to be generated, which a third-party peer, in many cases, would not be able to process.

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 (Microsoft LT2P, IPSO Symbian, and Cisco gateways and clients) attempt to establish VPN tunnels with ClusterXL Gateways in the Load Sharing mode. These 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, is unrecognized and dropped.

The following illustration demonstrates this.

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 Gateway 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 any gateways that can save only one set of SAs by making the connection sticky. Enabling the Sticky Decision Function sets all VPN sessions initiated by the same third-party gateway to be processed by a single cluster member.

To enable the Sticky Decision Function:

1. In SmartDashboard edit the cluster object > ClusterXL page > Advanced.
2. Enable the property Use Sticky Decision Function.

Third-Party Gateways in Hub and Spoke Deployments

Another case where Load Sharing mode requires the Sticky Decision Function 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.

The following diagram illustrates this deployment:

In this scenario:

• The intent of this deployment is to enable hosts that reside behind Spoke A to communicate with hosts behind Spoke B.
• The ClusterXL Gateway is 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 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. Enabling the Sticky Decision Function solves half of this problem, in that all VPN sessions initiated by either third-party gateway are processed by a single cluster member.

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 user.def file. This second step ensures that both third-party gateways always connect to the same cluster member.

Configuring the Sticky Decision Function

To configure the Sticky Decision Function:

1. Select a cluster object from the Network Object tree.
2. Select ClusterXL from the tree and click Advanced.
3. In the Advanced Load Sharing window, select one of the following options:
   • IPs, Ports, SPIs (default) provides the best sharing distribution, and is recommended for use. It is the least "sticky" sharing configuration.
   • IPs, Ports should be used only if problems arise when distributing IPSec packets to a few machines although they have the same source and destination IP addresses.
   • IPs should be used only if problems arise when distributing IPSec packets or different port packets to a few machines although they have the same source and destination IP addresses. It is the most "sticky" sharing configuration.
4. Enable the Sticky Decision Function option to enable its functionality or clear to disable. By default the Sticky Decision Function is disabled.

   If enabled, the connection will pass through a single cluster member on both inbound and outbound directions.

Establishing a Third-Party Gateway in a Hub and Spoke Deployment

To establish a third-party gateway as a spoke in a hub and spoke deployment, perform the following on the Security Management server:

1. Enable the Sticky Decision Function if not already enabled. In SmartDashboard, edit the cluster object > ClusterXL page > Advanced, and enable the property Use Sticky Decision Function.
2. Create a Tunnel Group to handle traffic from specific peers. Use a text editor to edit the file $FWDIR/lib/user.def, 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:

1. Other 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>};

   Note that 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 in essence turns off Load Sharing for the connections affected. 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 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:

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.