There are many SK and diagrams available on Internet as well as on checkpoint portal to describe the Packet flow of Checkpoint firewall. In most of Checkpoint SK you can find single diagram which is little complex to understand However, I’m trying to explain packet flow in step by step with help of diagrams. Hopes this can help to understand the logical packet flow of Checkpoint firewall.
Any suggestion most welcome.
Basic Packet Flow:
Here, I’m talking about basic overall flow of packet thought the Checkpoint firewall. Below Diagram can explain the Basic flow of Checkpoint firewall.
- Packet received on Ingress Interface
- Stateless Inspection
- Firewall Rule Base
- Content Inspection
- Route Lookup
- Egress Interface
In next Step I’m going to explain content Inspection. Content Inspection is a complex process.
In checkpoint firewall we have multiple security blades to perform multiple types of checks on packets like URL filtering, Anti-Bot, Application control etc.
Please refer below diagram
In Third step I’m going to explain CoreXL and Acceleration path
Before CoreXL coming into picture (pre-R65 versions), FW was only capable to perform a single CPU core based policy inspection. To leverage multi-core platforms, and to avoid a single CPU core to be a bottleneck, SecureXL was added.
SecureXL is capable to offload particular part of security decisions and VPN encryption into separate computation devices: a different core or cores on the same chip or even to a CPU-on-a-card.
With SecureXL certain connections could avoid FW path partially (packet acceleration) or completely (acceleration with templates)
CoreXL helps GWs in leveraging multi-core platforms even better, allowing to use some CPU cores for acceleration and some others for FW and Content Inspection (fwk workers). With Content Inspection in the picture, today we can distinguish three so-called paths for the packet flow through a Security GW:
- FW Path
- Accelerated Path and
- Medium Path
Although CoreXL is out there for some years now, sometimes those terms can be misunderstood or misrepresented. Let’s clarify what which path really means. The easiest way to do so is to use Diagram 1 and to see which parts of the packet flow is active for every case.
When acceleration is not possible or in case of acceleration is disabled. In this case each packet in the connection goes through FW Kernel Inspection section and sometimes through Content Inspection block, if policy requires that. This is how it looks:
Accelerated Path (previously also known as Fast Path) is active when a connection can be accelerated with a template through SecureXL device. In this case all individual packets within the connection will bypath both FW Kernel section a Content Inspection block:
This term causes some confusion from time to time. Let’s clarify what it means.
Medium Path is a situation when opening and closing a connection is handled by SecureXL, while data flow needs some further inspection and hence goes through Content Inspection. In such case the full connection flow can be shown as follows:
When Medium Path is available, TCP handshake is fully accelerated with SecureXL. Rulebase match is achieved for the first packet through an existing connection acceleration template. SYN-ACK and ACK packets are also fully accelerated. However, once data starts flowing, to stream it for Content Inspection, the packets will be now handled by a FWK instance. Any packets containing data will be sent to FWK for data extraction to build the data stream. RST, FIN and FIN-ACK packets once again are only handled by SecureXL as they do not contain any data that needs to be streamed.