topic Re: correction layer - clarification on the work in Hyperscale Firewall (Maestro)

correction layer - clarification on the work

yura_k — Wed, 14 May 2025 16:52:00 GMT

Hey, Maestro Masters!

From a great presentation by Lari_Luoma (https://community.checkpoint.com/t5/Maestro/Maestro-Masters-2025-Quantum-Maestro-Architectures-and/m-p/248873#M3414)

SGM where the initial Client to Server (C2S) packets are distributed becomes the owner of the connection in the connections table.
The owner calculates the SGM who will get the return packets of the connection. This SGM is called a target.
If the target is different from the owner, the connection is determined asymmetric, and the owner synchronizes connection to the target.
Target SGM won’t process packets it receives but sends them to the owner for processing.

Could you tell us a little bit more about how the correction works? 🙂

I may be wrong, but while doing some debugging I noticed a pattern that correction occurs if an asymmetric session is handled by a fw_worker instance with the same number on both owner SGM and target SGM. If asymmetric session on target SGM is assigned to a different fw_worker instance number from owner, then such connection will be dropped by the target and no correction occurs.

Re: correction layer - clarification on the work

Lari_Luoma — Thu, 15 May 2025 04:38:41 GMT

Hi!

Correction happens in environments where outgoing and incoming packets are distributed using a different IP-address. In practice this means NAT. Consider the following example:

Client with IP-address 10.1.1.10 communicates with a server in the Internet with IP-address 123.123.123.123. Of course the 10-network cannot be routed in the internet, so the traffic is natted by the Maestro security group to IP-address 222.222.222.222.

By default the distribution mode is auto-topology, which means that the internal interfaces are in user mode (packets are distributed to the SGMs based on the destination IP-address) and the external interfaces in network mode (packets are distributed using the source IP-address).

Considering the example above and assuming that the security group is in default setting, the outgoing packets would be distributed based on the destination IP-address. When the server responds to the connection, the external interface is in network mode and the packets are distributed based on the source IP-address. Source for return packets is the same as the destination for outgoing packets, so this means that the distribution is symmetric and there is no correction.

Now if you change the outgoing interface also to user mode, the return packets would be distributed based on the destination IP-address. Destination IP in natted environments is the NAT-IP. This would send the return packets to a different SGM. This SGM would receive the packets from the MHO, but not process them. It would simply send them to the original owner for processing. This means that there is an "extra hop" inside the Maestro system every time correction kicks in. In busy environments there is always some correction, but the recommendation is to keep it to minimum as large numbers of corrected traffic can cause some performance degradation.

Re: correction layer - clarification on the work

yura_k — Fri, 23 May 2025 12:26:09 GMT

Hey, Lari! Thank you very much for your explanation about NAT!

Can you also explain in detail how and which CoreXL instances are involved in the correction layer traffic processing?

Re: correction layer - clarification on the work

Lari_Luoma — Fri, 23 May 2025 14:52:06 GMT

In most cases, the CCL performs correction at the CoreXL SND (Secure Network Dispatcher) level, which is part of SecureXL.
When a packet for an existing connection arrives at the "wrong" member (not the owner), SecureXL (SND) detects this and forwards ("corrects") the packet to the owner member.
This correction is done before the packet reaches the Firewall or other inspection engines, minimizing latency and maximizing performance.
The correction is transparent to the network and ensures that all packets for a connection are handled consistently.
For some traffic types (e.g., Dynamic Routing, VPN, encrypted connections), correction may occur at the Firewall or SecureXL level, depending on the information required to identify the connection.

Even though we try to eliminate performance impact of correction as explained above, I have seen in several occasions where fixing distribution to be symmetric for certain traffic also improves performance. It depends on the traffic and some traffic seems to have more impact on performance when corrected than some other.