R80.x Security Gateway Architecture (Logical Packet Flow)

[_Val_]

Hi Heiko Ankenbrand,there are still a couple of issues with this chart.

1. You have market a CoreXL section there. In fact, you cannot really put CoreXL as a part of the packet flow. It is a system of balancing sticky decisions per connection, not per packet, and that can't be visualized as such.

2. You are keeping Medium Path something independent while it is just a continuation of SecureXL flow into Content Inspection block.

[Max_Thonagel]

Hi,

this is a very straightforward flowchart and a very good reference list.

Thanks,
Max

[Ramazan_Chakmak]

Great work 

[ivo_karzel]

Nice

[HeikoAnkenbrand]

Questions and Answers:

Q: Why this diagram with SecureXL and CoreXL?
A: I dared to map both worlds of CoreXL and SecureXL in a diangram. This is only possible to a limited extent, as these are different technologies. It's really an impossible mission. Why!
- CoreXL is a mechanism to assign, balance and manage CPU cores. CoreXL SND makes a decision to "stick" particular connection going through to a specific FWK instance.
- SecureXL certain connections could avoid FW path partially (packet acceleration) or completely (acceleration with templates)

Q: Why both technologies in one flowchart?
A: There are both technologies that play hand in hand. The two illustrations become problematic, e.g. in the Medium Path.

Q: Why in the Medium Path?
A: Here, the packet-oriented part (SecureXL) cannot be mapped with the connection-based part (CoreXL). Therefore, the following note from an new Check Point article from Valeri Loukine   (Security Gateway Packet Flow and Acceleration - with Diagrams - 08-07-2018) and original article from Moti Sagey (Check Point Threat Prevention Packet Flow and Architecture - 04-25-2017) :
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.

Q: What is the point of this article?
A: To create an overview of both worlds with regard to the following innovations in R80.x:
- new fw monitor inspection points in R80 (e and E)
- new MultiCore VPN with dispatcher
- new UP Manager in R80

Q: Why is there the designation "Logical Packet Flow"?

A: Since the logical flow in the overview differs from the real flow. For example, the medium path is only a single-logical representation of the real path. This was necessary to map all three paths (F2F, SXL, PXL) in one image. That is why the name "Logical Packet Flow".

Q: What's the next step?

A: I'm thinking about how to make the overview even better.

Q: Where does the information come from?

A: From References and links:

SecureKnowledge: SecureXL 

SecureKnowledge: NAT Templates 

SecureKnowledge: VPN Core 

SecureKnowledge: CoreXL 

SecureKnowledge: CoreXL Dynamic Dispatcher in R77.30 / R80.10 and above 

SecureKnowledge: Application Control 

SecureKnowledge: URL Filtering 

SecureKnowledge: Content Awareness (CTNT) 

SecureKnowledge: IPS 

SecureKnowledge: Anti-Bot and Anti-Virus 

SecureKnowledge: Threat Emulation 

SecureKnowledge: Best Practices - Security Gateway Performance 

Download Center: R80.10 Next Generation Threat Prevention Platforms

Download Center: R77 Security Gateway Packet Flow

Download Center: R77 Security Gateway Architecture

Support Center: Check Point Security Gateway Architecture and Packet Flow 

Checkmates: Check Point Threat Prevention Packet Flow and Architecture 

Checkmates: fw monitor inspection point e or E 

Checkmates: Infinity NGTP architecture  

Security Gateway Packet Flow and Acceleration - with Diagrams 

Please help me to improve the flowchart. Therefore I am grateful for any Feefback.

Regards,

Heiko

[vinceneil666]

Hi, this is great stuff 🙂 I might be way off here - but would it be an idea to bring in routing ? When are the routing table checked related to nat / encrypt f.ex?

[TheGrave]

That's a good question, DNAT/SNAT packet processing hook in relation to firewall rulebase evaluation must be in this diagram. My understanding is that in currently supported R80 versions, DNAT occurs before security rule evaluation, but only if "Perform Destination Translation on Client Side" is enabled in the Global Properties->Network Address Translation section (which is the default value).

What is also a good question is whether NAT table overrides the routing table when it comes to egress interface selection like it does in Cisco ASA?

[Timothy_Hall]

No the diagram is correct.  On the first packet of a new connection, the Firewall rule base (Network Policy Layer) is consulted first so any address matching there must be for the original/pre-NAT addresses.  If using the automatic NAT setup technique this detail is somewhat hidden, since a single object with NAT set represents both the original and NAT address in the single object used in the firewall policy rule.  If the packet is accepted, next the NAT policy is checked and how NAT will be performed is set for the life of that connection and cannot be changed.  If the destination IP address is subject to NAT the actual destination IP NAT operation is also performed (with the default "Translate destination on client side" checked).  Everything discussed above happens between i and I in the F2F path.  If the packet is dropped by the firewall policy the NAT rulebase is never consulted because it simply doesn't matter, and this is why you don't see any NAT rules referenced in a drop log.

The NAT operation on the source address (if applicable) happens between o and O.

NAT does not really override the routing table, most of the time the only thing IP routing considers is the destination IP address, so if the destination IP address is subject to NAT we want to perform that NAT operation between i and I prior to routing by IP.

There are exceptions to this with PBR and such but the above is how most traffic gets handled.

[_Val_]

Both NAT and rulebase enforcement are happening at the same place. Agree with @Timothy_Hall , to that extent the diagram os okay.

[ali_yildirim]

Hi Heiko,

good that both components are shown (SecureXL and CoreXL) and a great reference list to other article.

Thanks,
Ali

[_Val_]

Heiko Ankenbrand‌ I would like to reiterate once more that CoreXL markings on the diagram are problematic. I suggest you remove CoreXL notion from the diagram

[HeikoAnkenbrand]

Hi Valeri

I think this topic will trigger a fundamental discussion here and we have discussed this in the background with private messages over the last few days. I think we should open an article here to avoid confusing all users.

New discussion articel:

How does the Medium Path (PXL) and Content Inspection work with R80 

To my point:

There is a SK98737 ( CoreXL ) describing exactly my picture. I will illustrate this with a picture:

my flowchart	SK98737 - topic 5

Here are the original text from SK:

[5] Packet flow

When SecureXL is enabled, a packet enters the Security Gateway and first reaches the SecureXL device. The packet will be handled in one of three ways:

1. Accelerated path - The packet is completely handled by the SecureXL device. It is processed and forwarded to the network.
   
   
2. Medium path (PXL) - Packet flow when the packet is handled by the SecureXL device, except for IPS (some protections) / VPN (in some configurations) / Application Control / Content Awareness / Anti-Virus / Anti-Bot / HTTPS Inspection / Proxy mode / Mobile Access / VoIP / Web Portals. The CoreXL layer passes the packet to one of the CoreXL FW instances to perform the processing.
   This path is available only when CoreXL is enabled.
   
   
3. Firewall path / Slow path - The SecureXL device is unable to process the packet (refer to sk32578 (SecureXL Mechanism)). The packet is passed on to the CoreXL layer and then to one of the CoreXL FW instances for full processing.
   This path also processes all packets when SecureXL is disabled.

If you still think this is not possible, the Check Point article would be wrong in your support center since 01-Jul-2014 and I think strongly that this article is right.

Let's all discuss this here in peace:

How does the Medium Path (PXL) and Content Inspection work with R80 

Regards

Heiko

[_Val_]

I do agree with you, this is a fundamental discussion.

My issue with your diagram is that you put Medium Path as something independent and different from SecureXL Path. It is not.

In essence, the difference between Fast Path and Medium Path is about whether Content Inspection has to be performed or not. If the answer is yes, after crossing SecureXL packets goes to a FWK instance to form a data stream for Content Inspection. If the answer no, it is fully accelerated, hence FW kernel is fully bypassed. So, in other words, both SecureXL and FW kernel are active in case of Medium Path.

I have made three different diagrams in Security Gateway Packet Flow and Acceleration - with Diagrams  trying to make this point as clear as possible. 

[_Val_]

You say: If you still think this is not possible, the Check Point article would be wrong in your support center since 01-Jul-2014 and I think strongly that this article is right.

Well, the article is right and so am I. There is no contradiction between the diagram you have taken from the article and my statement. It is, in fact, very simple.

Medium path can be shown separately if you chart it per connection and not per packet. The SK you are quoiting does just that, it is a high level diagram for handling connections, not individual packets.

Your diagram, on the other hand, is for packet handling. The only way to show any Path, FW, Medium or Fast on a single packet flow diagram is to chart which modules (SecureXL, FW kernel, Content Inspection) are handling a packet in any particular case. As done here Security Gateway Packet Flow and Acceleration - with Diagrams 

The argument we are having is not even about understanding of technology. Your understanding is all right. The support article is correct. I am correct and I also understand that you are too. 🙂

It is about presenting this understanding in graphics. This representation also has to be correct, and this is what I am aiming to.

[_Val_]

Heiko Ankenbrand‌ I also have other corrections to your diagram. I will send you a personal message, as those require some offline discussions. Let's stop doing it here till the issues are fixed.

Thanks

[Moti]

Heiko Ankenbrand great work!! It simply warms my heart to the see the level of your dedication to this community (without getting a salary in return ;)) I think it's a great opportunity on behalf of the CheckMates team Amit Sharon Dameon Welch Abernathy myself and our "new Comer" Valeri Loukine to publically thank you for your great CONSISTENT contribution to CheckMates and keeping it constructive and civilized 🙂

See you in Israel soon 🙂

[HeikoAnkenbrand]

One last comment here.

I will create a revised version with Valeri Loukine from Check Point in the next days.

Regards,

Heiko

[HeikoAnkenbrand]

Special thanks to  Valeri Loukine who supported me here technically in the background.

And special thanks to CheckMates team Moti Sagey, Amit Sharon, Dameon Welch Abernathy who have executed organizational processes in the background.

Regards,

Heiko

[_Val_]

Thanks Heiko Ankenbrand‌ for your hard work and collaboration. We appreciate it, very well done indeed!

[_Val_]

Which is already done 🙂

Now the diagram is perfect, thanks again

[Danny]

As the packet flow shows, there is no Fast path (SXL). It's called Accelerated path. This is important because Check Point puts attention to these little details in it's exams. Please update your diagram.

[_Val_]

Very good point, Danny Jung‌

[HeikoAnkenbrand]

Thanks Danny

I'll change it in the next version.

Regards,

Heiko

[HeikoAnkenbrand]

Is done!

Regards,

Heiko

[_Val_]

Hi, just a note. There is a typo: UP Manger  - at the beginning of the document

[HeikoAnkenbrand]

Is corrected, thx

Regards,

Heiko

[HeikoAnkenbrand]

The background story to this article:

It has been a lot of work over the last two weeks to create this flowchart and the text and I have used a lot of my holiday time for it. I also received very good support from Check Point (Valeri Loukine ). I have discussed a lot with Valeri in the background to improve this article. I was also able to gain some new experiences about the function of the firewall R80.

I would be happy to help you all with this Flowchart.

But now I have to take care of my family.

I think we should now have a final version that Check Point is satisfied with.

Thanks to all involved,

Heiko

[Danny]

You are addicted

[_Val_]

There is nothing wrong being addicted to This is how we like it to be. 🙂

But point taken, we need to have a support group for CheckMates addicts, where we listen to them and then ask them to post more

[HeikoAnkenbrand]

Hi Danny, 

Checkmates is a good drug without side effects
You take them, too