Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
JTE
Participant

Load Sharing & Asymetric Routing

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.

 

0 Kudos
4 Replies
PhoneBoy
Admin
Admin

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.
0 Kudos
JTE
Participant

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 ?

 

0 Kudos
_Val_
Admin
Admin

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.

 

0 Kudos
Timothy_Hall
Legend Legend
Legend

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events