Security Gateway Packet Flow and Acceleration - with Diagrams (Obsolete)

[_Val_]

Note: this article is no longer actual. Refer to this post from our Technical Marketing Engineering team for the latest diagrams.

Version 1.1 - 07.08.2017
Updated diagrams

Abstract

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.

References

Check Point Security Gateway Architecture and Packet Flow 

Context-Aware Architecture 

R80.10 Security Gateway Architecture  

R77 Security Gateway Architecture  

ATRG: CoreXL 

ATRG: SecureXL 

[Patricia_OSulli]

Hi Valeri,

Great article but you don't have to do the work twice.
This article has already Moti Sagey released in 2017:

Check Point Threat Prevention Packet Flow and Architecture 

See Link:

• R77 Security Gateway Architecture
• R77 Security Gateway Packet Flow

But it looks better in multicolored.

Regards,

Patricia

[_Val_]

Hi Patricia OSullivan‌

Thanks for pointing this out. Moti Sagey is my boss, and I am pretty much aware of this efforts to spread the word 🙂

I can tell you more. There is another document circulating on this board with the diagrams for packet flow, you'he probably seen it. There are also quite a few SKs describing different parts of GW architecture, acceleration, packet flow logic, etc. Some of them are not up to date, some others are only available for UserCenter accounts with at least Advanced level of access.

So let me explain my intentions. Here is what I am aiming at:

1. Accurate diagrams for the matter (Yes, the main one is the colored official SK diagram, no question. I also had to remove CI out of it to make it more user friendly). You are I both know there are things out there. The fact people are trying to make up their own diagrams means the official ones either not accessible or unknown.

2. Simple and accessible explanation of the subject without need to jump between multiple SKs and documents. 

3. Finally, as far as I know, nobody has tried using the generic packet flow diagram for explaining acceleration and CoreXL cases. I have seen a few situations where customers and even partners misunderstood what Medium Path actually is. Showing FW, Fast and Medium paths on the main diagram is very helpful, I hope.

I will be happy to answer any of your further concerns and questions

[Vladimir]

Valeri,

Thank you for the article. Please, please change the font colors and sizes if you have the time: white (and small and non-bold) characters, especially on pale backgrounds make my eyes bleed.

[_Val_]

Hi, I have updated the diagrams. If it is still not good enough, click on any of them, a pic will be opened full screen.

[Simone_Mantovan]

Very useful documenti, thank you

[18568]

Thank you that's very interesting.

Where would HTTPS Inspection fit into this? I'm especially interested to see if enabling the HTTPS Inspection on a gateway could have a performance impact even on packets that are not inspected according to https inspection policy.

[_Val_]

Good question.

HTTPS Inspection means that you decrypt HTTPS traffic before full inspection and re-encrypt it into a separate session. Impact on traffic excluded from HTTPS Inspection is minimal though. 

[_Val_]

HTTPS inspection goes PXL, if that was the question.

[dror]

Thank you very much for the detailed post and explanations, it was very useful and educational. 

I have a question though, one of the first stages in the drawing is a "stateless inspection" step. I couldn't find any reference to stateless inspection before checking if the packet can be accelerated. 

My suspicion is that these are the inspections that we can control through "inspection settings" via the access policy, is that assumption correct? 

any detail on this step would really help 🙂 

[_Val_]

stateless verification means basic sanity on a packet, like checksum, IP options or allowed ICMP size. It is done by asm kernel logical module. 

Only some of those parameters can be controlled.