> Source: [sk31533](https://support.checkpoint.com/results/sk/sk31533)

# sk31533 - ClusterXL Load Sharing Sticky Decision Function for Passive FTP

| Property | Value |
|----------|-------|
| Solution ID | sk31533 |
| Date Created | 2006-02-25 |
| Last Modified | 2013-12-17 |
| Technical Level | General |

## Symptoms

- Passive FTP data connection packets are dropped as out-of-state packets.

## Cause

The Sticky Decision Function for Load Sharing has not been set to the most "sticky" configuration.

Initially the passive FTP data connection goes through one cluster member, but after that the FTP data connection packet arrives at another cluster member and is blocked.

## Solution

In order to configure the Sticky Decision Function for Load Sharing to the most "sticky" configuration, perform the following steps in SmartDashboard:   

1. Go to 'Manage' menu - click on 'Network Objects'.

2. From the network objects list, select the relevant cluster object.

3. Click 'Edit...'.

4. In the Cluster Properties window - go to 'ClusterXL' pane.

5. In the ClusterXL page, click the 'Advanced' button in the Load Sharing option section.

6. In the 'Advanced Load Sharing Configuration' window, select the 'IPs' option from the "Use sharing method based on:" section.

7. Click 'OK' in the 'Advanced Load Sharing Configuration' window.

8. Click 'OK' in the 'Cluster Properties' window.

9. Click 'Close' in the 'Network Objects' window.

10. Install the Security policy on the cluster object.

Note:   

By default, packets are distributed among cluster members based on IP addresses, Ports and IPSec SPIs, resulting in maximum distribution.   

In some cases, however, an application may require a few connections to go through a specific cluster member. Such cases require a decrease in the distribution of packets in order to increase the probability that a certain connection will pass through a single cluster member on both inbound and outbound directions. This is done by choosing a more "sticky" sharing method.   

**Use Sticky Decision Function**   

A "sticky" connection is one in which a reply packet returns through the same gateway as the original packet. The Sticky Decision function ensures that in a Load Sharing configuration, a connection that starts on a given cluster member will continue to be processed by the same cluster member in both directions. In High Availability configurations, all packets reach the same cluster member, so all connections are sticky.   

The Sticky Decision Function makes Load Sharing compatible with certain services. For example, it is required when passing L2TP traffic though the cluster, or when the cluster acts as a VPN peer with a Cisco VPN peer. By default, Use Sticky Decision Function is unchecked.   

The Sticky Decision Function works for most popular connection types including:   

* FTP. The data connections are passed through the same cluster member as the control connection.

* NATed connections, including Static NAT and Hide NAT.

* VPN, including encrypted connections generated from SecuRemote/SecureClient or from another VPN gateway.

The Sticky Decision Function has the following limitations:   

* Connection types that are not recognized by the Sticky Decision Function may not maintain stickiness and will pass through the same members as they would when using the default Decision Function.

* The Sticky Decision Function does not work with SecureXL (either a Performance Pack or a hardware-based accelerator card). If acceleration is installed on the member, and the Sticky Decision Function is turned on, SecureXL will be stopped.

<br />

<br />

The Sticky Decision Function does not maintain stickiness in VPN Routing (back-to-back VPN) Gateways where both sides of the connection are encrypted.   

The various sharing configurations are based on different criteria:   

* 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 even though they have the same source and destination IP addresses.

* IPs is the most "sticky" sharing configuration, in other words, it increases the probability that a certain connection will pass through a single cluster member on both inbound and outbound directions.

<br />

<br />

<br />

<br />

Warning:   

The SmartDashboard Help files state that the "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". This is misleading because the procedures described in this solution potentially address problems with regular (i.e., non VPN) passive FTP traffic data connection packets being blocked as out-of-state packets, when an initial passive FTP data connection packet goes through one gateway cluster member, and a subsequent passive FTP data connection packet arrives at another gateway cluster member.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content