What is the exact processing of the flow with CoreXL and SecureXL? How are the packages processed here?
Q: Why this question?
A: There are several articles in the forum that currently discuss this thema.
References to the articles:
Check Point Threat Prevention Packet Flow and Architecture - 09-04-2017 (Moti Sagey )
R80.x Security Gateway Architecture (Logical Packet Flow) - 07-28-2018 ( Heiko Ankenbrand )
Simplified Packet Flow document - 08-06-2018 ( Valeri Loukine )
Security Gateway Packet Flow and Acceleration - with Diagrams - 08-06.2018 (Valeri Loukine )
References to SK's:
To avoid confusing all users, I think we should clarify this in this article.
Thanks in advance
Hi Heiko Ankenbrand, I love the sketch. Apparently you are not only a talented engineer but also a gifted artist. Do you have it in a good resolution?
Now, to your question.
SecureXL is the acceleration technology Check Point developed to speed up stateful inspection of authorized connections (packet acceleration) and, in some cases, opening new connections by bypassing slower FW kernel inspection.
CoreXL is an add-on that allows utilizing multiple cores for FW processing. It removes a critical FW kernel inspection limitation. By design and because of the nature of kernel memory utilization, a specific connection flow can only be inspected by a single CPU core. CoreXL adds a decision point (SND) allowing sticky static load balancing by designating particular connections to different CPU cores. This decision is being made by SND on the first packet arrival and is based on specific parameters (IPs and ports).
For that specific reason Check Point does not put CoreXL decision point on the packet flow diagram. To do so in a correct, you would have to multiply FW path sections per CPU and put the decision on top of everything, including SecureXL path. Such diagram would be too confusing and impractical to use.
As an add-on, CoreXL is only effective in tackling traffic with many different sources and destinations. In a rare case where there is only one source and one destination, the flow will hit a single core all the time, and the single core FW kernel bottleneck will still be unavoidable.
I have already answered this question in Security Gateway Packet Flow and Acceleration - with Diagrams