Security Gateway Packet Flow and Acceleration - with Diagrams

Document created by Valeri Loukine Moderator on Aug 6, 2018Last modified by Valeri Loukine Moderator on Aug 9, 2018
Version 4Show Document
  • View in full screen mode

Version 1.1 - 07.08.2017
Updated diagrams


The purpose of this document is to provide clean and simple diagrams of Security Gateway packet flow. Although there are quite a few SecureKnowledge articles for the matter and also some attempts on CheckMates to summarize the logical packet flows, it is quite hard to find  straight forward explanation of the inspection and acceleration in a single document. 


The most challenging part is to come up with a unified diagram showing all possible packet flow paths, inspection and decision points. The author of this document, after several attempts to make it right, has decided to keep main packet flow diagram separate from Content Inspection block for sake of simplicity and better visual representation.


The document is not intended to provide a full explanation of Gateway architecture, technological solutions and product structure rather than be a reference point for those who seek simplified and easy to grasp materials to start with. Multiple SKs and documents for the matter are listed in the References section of the document.


Main packet flow

The following diagram represents general packet flow through a Security Gateway.

Diagram 1 - Overall GW Packet Flow


In a nutshell, once packet is received by a Security Gateway, the very first decision is about whether is has to be decrypted. Depending on acceleration settings and abilities, both individual packets and full connections can be accelerated through SecureXL. If acceleration is not possible, the packet is inspected through FW policy. Only the first packet in the accepted connection goes through policy rulebase matched routine. FW inspection for further packet belonging to a connection which is already accepted by FW is relatively lightweight.


It may be required to perform Content Inspection for the data flow of a specific connection. In this case packets will also go through Content Inspection block which is discussed below. Once all the required security checks are done, packet will be encrypted, if required, and finally forwarded out of the GW.


Content Inspection

Content Inspection is a complex process based on the data streaming capabilities of a Security Gateway. FW extracts a data content form individual packets and builds a stream which is being inspected by different security features: URL Filtering, Application Control, Anti-Bot, Content Awareness, SandBlast etc. 


A simplified logical view of such inspection is shown on the diagram below:

Diagram 2 - Content Inspection Block


To make it easier correlating it with the main packet flow, entry and exit point for the Content Inspection Block are shown here as well as on the Diagram 1. Content Inspection may decide to discard the packet. If that happens, the connection it belongs to will also be cut and removed from the connection table of FW kernel. If no negative security decision is made, packets will be forwarded normally.


CoreXL and Acceleration Paths

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.


FW Path

FW Path is implored when acceleration is not possible. 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:


Diagram 3 - Firewall Path Flow


Accelerated Path

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 an Content Inspection block:


Diagram 4 - Accelerated Path Flow

Note: Drop Templates acceleration fork is omitted from the SecureXL section of the diagram as it is not considered part of Accelerated Path. We use "Path" term only for packets forwarded through the FW.


Medium Path

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:


Diagram 5 - Medium Path Flow

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.


Questions and Answers

This section is containing the most common questions and answers for the matter. 


Q: Why CoreXL is not on the diagrams?

A: CoreXL is a mechanism to assign, balance and manage CPU cores. CoreXL SND makes a decision to "stick" particular connection going through FW or Medium Paths to a specific FWK instance. It is not part of the logical flow for a specific packet though.



Check Point Security Gateway Architecture and Packet Flow 

Context-Aware Architecture 

R80.10 Security Gateway Architecture  

R77 Security Gateway Architecture  


ATRG: SecureXL 

31 people found this helpful