|
|
|
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 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 participates in a Site-to-Site VPN tunnel with a third-party VPN peer.
The following services and connection types are now supported by enabling the Sticky Decision Function:
The Sticky Decision Function has the following limitations:
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:
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. Enabling the Sticky Decision Function sets all VPN sessions, initiated by the same third-party gateway, to be processed by a single cluster member.
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.
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:
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 applicable user.def file (see sk98239). This second step ensures that both third-party gateways always connect to the same cluster member.
To configure a third-party gateway as a spoke in a Hub and Spoke VPN deployment, perform the following on the Security Management Server:
|
The elements of this configuration are as follows:
|
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 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:
|
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.
