Firewall-Blades Order of Operation

[ahmedaburaihan]

Hallo Mates

What is the order of operation of Firewall-Blades in a normal environment? 

Let suppose a packet from Internet enters an OUT Interface of a Firewall, How does the Firewall deal with it?

- Does the Policy/Rule is checked against.

- Does the Threat Prevention Module works first?

... and so on. 

I would be grateful for a detailed answer in this regard. 

Thank you, 

A. 

[_Val_ · Accepted solution]

This pic should answer your quesiton

[ahmedaburaihan]

Yes, thank you for the pic. Could you please also put some light on this? 

[_Val_]

It depends. You asked about the order of different blade enforcement.

When the packet comes to your GW, it is being inspected before forwarding. The first action is anti-spoofing. Then, and even before it is filtered through the security policy, TLS inspection policy is applied, if the feature is enabled on your GW.

The next step is your Security policy in combination with Application Control, URL filtering, and Content Inspection if they are used. If the result is Accept action, the next step is Threat Prevention: AV, IPS, and anything else you have in your Threat Prevention Policy.

The whole logic is linear, without loops.

[ahmedaburaihan]

@_Val_ Thanks for the details. 
For me it is not so much clear because, as of Order of OSI layer, TLS inspection should be done at L4 and L1 (because of TCP and HTTPS). I thought that it could be Linear, first Source and Destination and then Port and then application. I am kinda not getting into details. Where can i find resource which tells me exact behavior step by step? thanks. 

[_Val_]

TLS inspection is a special case. You have to decrypt the traffic in order to inspect it with your security policies. To make it happen, GW will proxy your HTTPS traffic. In a sense, it is "the man in the middle" situation. TLS connection from the client is terminated on the GW, and a secondary TLS tunnel is opened to the server, allowing your GW to see the cleartext traffic.

I sense you are new to Check Point. if this is true, please browse our Check Point for Beginners materials in this community, it will help.

[Bob_Zimmerman]

Two noteworthy items are missing from that diagram: VPN decisions (like flagging a packet for encryption to a given VPN peer) and NAT.

My memory is VPN decisions are made between antispoofing and HTTPS inspection. This is before any address translation can happen, and it affects which addresses you need to include in a firewall's encryption domain.

NAT rule matching is done with the firewall policy matching, but decisions aren't actually applied until later (after the Threat Emulation/Extraction part of this diagram). All rules should be written based on how the traffic will look when it arrives at the firewall.

[_Val_]

The question was, in which order the policies are being enforced. 

VPN description is happening on inbound before FW filtering, but the decision to do VPN is also part of FW filtering, together with NAT.

I keep saying that it is pointless trying to put everything in a single diagram.  If the question is, in which order policy is applied, the answer is above. If you want to how a connection can be modified (decrypted/NAT-ed/encrypted) as part of the traffic handling by your security gateway, it is a completely different story, much deeper, with a lot of information you need to know before you understand the answer. 

[Bob_Zimmerman]

Sure, but generally people ask what order things happen in because they want to know something deeper like how rules should be written. The details of VPN domain matching and NAT affect how VPN domains and rules are written, so they are often relevant for the question behind the question.

[_Val_]

@Bob_Zimmerman

I was addressing the specific question raised by the topic starter: What is the order of operation of Firewall Blades in a typical environment?

I’d like to reiterate my perspective regarding providing an all-encompassing answer to questions that haven’t been explicitly asked.

Based on my professional experience, attempting to address every possible scenario in a single response is both impractical and potentially counterproductive.

To fully understand how traffic interacts with firewalls, it’s essential to make a deep dive into the intricate details of firewall software modules, chains, and the various parameters associated with connections and packets. This includes how these parameters are presented, controlled, and manipulated by different security blades. This is a complex subject that requires significant time—weeks, months, or even years—to master comprehensively.

That said, this level of detail is not typically necessary for the day-to-day responsibilities of security administrators and architects. While such knowledge is indispensable for software developers and TAC experts, most field tasks, including deployment, management, and even troubleshooting of security systems, can often be performed effectively without diving into every technical nuance. 

Once again, this is just my personal opinion. In my trainings I tend to do the opposite: take a complex case and creak it down to a number of simple to grasp subjects, then slowly and carefully deepen the understanding, to be efficient. And then repeat the principle to the required depth. 

Looking at the questions from the author here, I am not ready to dive to the bottom of everything in a single sentence of even a paragraph.

I hope this makes sense. If not, let's talk further 🙂

[ahmedaburaihan]

@_Val_ I respect your personal opinion. 

Although it is a very complex topic to discuss about, it is still important to know how things work in order to interact with it in a fully functional way. Shallow information about something is like throwing an arrow on a dark space which is the reason i wanted to know more about the functions from the experts like you. 

[_Val_]

I believe I answered your original question already, @ahmedaburaihan 

[kamilazat]

While both @_Val_ and @Bob_Zimmerman have already mentioned how deep of a dive you're about to take, I recommend using Check Point Copilot for explanations. Unless you go for firewall chain analysis and diving even deeper, the AI will be your friend explaining the overall workings of how traffic is processed with 'relatively' lesser hallucinations.

Below is what AI responses based on my notes say. Definitely not the full picture but hopefully it can provide some illumination.

Here's what happens to an incoming packet, integrating NAT and VPN operations:

1. Packet Arrival and Initial Hand-off to SecureXL

• The journey begins as a packet arrives at the firewall's Network Interface Card (NIC), where the NIC driver performs initial sanity checks.

• The operating system then hands off the packet to SecureXL, Check Point's proprietary acceleration technology, if it's enabled. SecureXL's goal is to handle traffic as efficiently as possible, potentially bypassing the full firewall kernel for speed.

• The first packet of every new connection, including those that will ultimately be dropped or rejected, must go through the Firewall Path (F2F/slowpath) for a rule base lookup. This is considered the longest and least efficient path.

• If a connection is accepted, SecureXL creates an Accept Template based on the packet's source IP, destination IP, source port, destination port, and IP protocol number. Subsequent packets for this connection can then be accelerated by SecureXL, avoiding repeated rule lookups.

2. Inbound Firewall Kernel Processing (fw VM inbound)

• If the packet is not fully accelerated (e.g., it's the first packet or requires complex inspection), it enters the firewall kernel's inbound processing chain.

• Anti-Spoofing: Very early in the inbound chain, stateless verifications, including anti-spoofing, are performed. Anti-spoofing checks the validity of IP addresses for incoming traffic based on the firewall's defined network topology.

• VPN Decryption (Inbound): For incoming encrypted traffic, VPN decryption (vpn decrypt) and VPN tagging (vpn tagging inbound) occur early in the inbound kernel chain, after IP Options Strip and Anti-Spoofing. This is critical because the decision whether to encrypt or decrypt incoming traffic (especially for domain-based VPNs) happens before destination NAT. VPN tagging is based on the original source and destination IPs.

• Access Control Policy Matching & NAT Rule Matching: The packet proceeds to the fw VM inbound module, where the main firewall rule evaluation (Access Control Policy) occurs and NAT rule matching is performed. If a security rule permits the packet, an evaluation against the NAT policy also takes place.

• Destination NAT (DNAT) Application: For incoming connections, if a NAT rule matches, Destination NAT is applied prior to Gaia IP routing. This means the destination address is translated before the packet is routed. This change can be observed between the 'i' (Pre-Inbound) and 'I' (Post-Inbound) inspection points in fw monitor output.

3. Routing

• After inbound processing, the packet is handed off to the Gaia IP driver. This driver performs a routing table lookup to determine the appropriate egress (outgoing) interface.

4. Outbound Firewall Kernel Processing (fw VM outbound)

• The packet then enters the outbound firewall kernel processing chain.

• Source NAT (SNAT) Application: Source NAT is applied after routing. This means the source address is translated before the packet leaves the firewall. In fw monitor output, SNAT typically occurs immediately after the 'o' (Pre-Outbound) point.

• VPN Encryption (Outbound): For outbound traffic that needs to be encrypted, the vpn encrypt module is located later in the outbound chain, after the main firewall VM processing and VPN policy outbound checks.

5. Content Inspection / Threat Prevention

• Deep content inspection features such as Threat Emulation, Threat Extraction, Anti-Virus, Anti-Bot, Application Control, URL Filtering, and HTTPS Inspection generally occur after the primary firewall rule evaluation (fw VM inbound/outbound) and NAT application.

• These functions often involve "active streaming" modules (TCP streaming (in/out) (cpas)), which can prevent full SecureXL acceleration. For example, Threat Emulation receives a copy of the file for analysis, while the original file proceeds.

6. Final Delivery

• After all necessary inspections and transformations are complete, the packet is released to the SecureXL Acceleration Layer associated with the egress interface and is finally transmitted out of the firewall onto the network.

---

A Critical Principle

It's vital to remember that all firewall policy rules (Access Control and Threat Prevention) should be written based on how the traffic will look when it first arrives at the firewall (i.e., using the original, pre-NAT IP addresses). The firewall's topology definition is also crucial for the correct application of security policies and anti-spoofing, especially for features like the "Internet" object and DMZ networks.