Load Sharing & Asymetric Routing

[JTE]

Hi guys,

I have a question about load sharing clustering & asymetric routing because it's not clear for me (without SDF enable). 

When two nodes are in loadsharing clustering (Multicast or Unicast), the original packet is handle by one gateway but the reply packet may/can returns via a different security gateway. In this case, there is a asymetric routing.

As the connection is shared in the kernel table of the both gateway, the reply packet is accepted by the other firewall or not ? 

Regards.

[PhoneBoy]

Connections are shared, yes.
For Threat Prevention, packets are forwarded via the sync interface to the original member (if necessary) via a mechanism called Chain Forwarding.

[JTE]

Thank you for your answer.

Ok If I correctly understanding, the reply packet is accepted by the other gw for access control policy and if three is threat prevention policy the packet is forwarded via sync interface to original member.

But I'm confused because as I know, if there is a access control policy and threat prevention policy on a gw, first the firewall check the access control policy to match a rule then the threat prevention policy. What is the behavior in this case ?

[_Val_]

Two things:

1. In Unicast mode, all packets are received by pivot and then forwarded to a specific cluster member for processing. This way pivot member is responsible for perfect stickiness. No other members are receiving packets related to a particular connection, except for a case when the designated member fails in the middle of connection. FW kernel tables are synchronised through the cluster members, but do not require acknowledgement to proceed with packet forwarding.

2. In multicast mode, all cluster members receive the packet, but only the designated member processes it. The other members just drop it. To ensure this behaviour, cluster performs something called "Flash and ACK", where packets are not forwarded before delta sync is done is confirmed through the cluster. Flash and ACK is causing some performance drawbacks. In some specific cases, such as Threat Prevention, where connection should be streamed and go through deeper inspection, there is a decision function providing perfect stickiness. 

In all cases, FW kernel tables as synced.

Case of forwarding is not going through sync and in most cases is not related to Load Sharing at all.

[Timothy_Hall]

Note that the Sticky Decision Function (SDF) is gone in R80.20+ due to the major overhaul of SecureXL in that revision, and has been replaced with the Cluster Correction Layer mechanism described here: sk169154: Asymmetric connections in ClusterXL R80.20 and higher