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