Re: R80.x Security Gateway Architecture (Logical Packet Flow)

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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".

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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.

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.

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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.

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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.

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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 🙂

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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.

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

Re: R80.x Security Gateway Architecture (Logical Packet Flow)

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.