Print Download PDF Send Feedback

Previous

Next

Non-Sticky Connections

A connection is called sticky if a single Cluster Member handles all packets of that connection. In a non-sticky connection, the response packet of a connection returns through a different Cluster Member than the original request packet.

The cluster synchronization mechanism knows how to handle non-sticky connections properly. In a non-sticky connection, a Cluster Member can receive an out-of-state packet, which Firewall normally drops because it poses a security risk.

In Load Sharing configurations, all Cluster Members are active. In Static NAT and encrypted connections, the source and destination IP addresses change. Therefore, Static NAT and encrypted connections through a Load Sharing cluster may be non‑sticky. Non-stickiness may also occur with Hide NAT, but ClusterXL has a mechanism to make it sticky.

In High Availability configurations, all packets reach the Active member, so all connections are sticky. If failover occurs during connection establishment, the connection is lost, but synchronization can be performed later.

If the other members do not know about a non-sticky connection, the packet will be out-of-state, and the connection will be dropped for security reasons. However, the Synchronization mechanism knows how to inform other members of the connection. The Synchronization mechanism thereby prevents out-of-state packets in valid, but non‑sticky connections, so that these non-sticky connections are allowed.

Non-sticky connections will also occur if the network Administrator has configured asymmetric routing, where a reply packet returns through a different Security Gateway than the original packet.

Non-Sticky Connection Example: TCP 3-Way Handshake

The 3-way handshake that initiates all TCP connections can very commonly lead to a non-sticky (often called asymmetric routing) connection. This diagram shows a sample scenario:

Item

Description

1

Client

2

Security Gateway - Cluster Member A

3

Security Gateway - Cluster Member B

4

Server

The client initiates a connection by sending a SYN packet to the server. The SYN passes through Cluster Member A, but the SYN/ACK reply returns through Cluster Member B. This is a non-sticky connection, because the reply packet returns through a different Security Gateway than the original packet.

The synchronization network notifies Cluster Member B. If Cluster Member B is updated before the SYN/ACK packet sent by the server reaches it, the connection is handled normally. If, however, synchronization is delayed, and the SYN/ACK packet is received on Cluster Member B before the SYN flag has been updated, then the Security Gateway treats the SYN/ACK packet as out-of-state, and drops the connection.

You can configure enhanced 3-Way TCP Handshake enforcement to address this issue.

Synchronizing Non-Sticky Connections

The synchronization mechanism prevents out-of-state packets in valid, but non-sticky connections. The way it does this is best illustrated with reference to the 3-way handshake that initiates all TCP data connections. The 3-way handshake proceeds as follows:

  1. SYN (client to server)
  2. SYN/ACK (server to client)
  3. ACK (client to server)
  4. Data (client to server)

To prevent out-of-state packets, the following sequence (called "Flush and Ack") occurs

  1. Cluster Member receives first packet (SYN) of a connection.
  2. Suspects that it is non-sticky.
  3. Hold the SYN packet.
  4. Send the pending synchronization updates to all Cluster Members (including all changes relating to this packet).
  5. Wait for all the other Cluster Members to acknowledge the information in the sync packet.
  6. Release held SYN packet.
  7. All Cluster Members are ready for the SYN-ACK.

Synchronizing Clusters on a Wide Area Network

Organizations sometimes need to locate Cluster Members in geographical locations that are distant from each other. A typical example is a replicated Data Center, whose locations are widely separated for disaster recovery purposes. In such a configuration, it is clearly impractical to use a cross cable for the synchronization network.

The synchronization network can be spread over remote sites, which makes it easier to deploy geographically distributed clustering. There are two limitations to this capability:

  1. The synchronization network must guarantee no more than 100ms latency and no more than 5% packet loss.
  2. The synchronization network may only include Layer 2 networking devices - switches and hubs. No Layer 3 routers are allowed on the synchronization network, because routers drop Cluster Control Protocol (CCP) packets.

You can monitor and troubleshoot geographically distributed clusters using the command line interface.

Synchronized Cluster Restrictions

The following restrictions apply when you synchronize Cluster Members: