Packet flow

[Vineethkumar]

Hello all, 

I'm very confused about the packet flow in the CP security gateway .. particularly in between Access policy and NAT policy. Referred few documents and these AI models creating lot of confusion.  

when a packet arrives at interface, after checking for VPN decryption / Secure XL ( if applicable)  Access policy applied first and DNAT will be next ? or  DNAT first and policy look up next ? Can some one please clarify.. 

I could see NAT happens at two instants,  firstly it is DNAT and then after content inspection/ taking  routing decision  SNAT happens.. why can't both happen at a time? any reason ? Please explain  

[Vincent_Bacher · Accepted solution]

Maybe Heiko can helP

https://community.checkpoint.com/t5/General-Topics/R81-x-Security-Gateway-Architecture-Logical-Packe...

[PhoneBoy · Accepted solution]

The firewall kernel attaches at the ingress/egress of kernel networking.
The OS is ultimately responsible for routing the packet. 
If you don't do DNAT before OS routing, then you have to add a static route for the pre-NAT address.
If you prefer this old behavior (which dates back decades at this point), there is a global properties setting to adjust it:

[the_rock · Accepted solution]

On top of what was already provided, see if this helps.

Great explanation by Tim Hall.

https://community.checkpoint.com/t5/General-Topics/Check-Point-Inspection-points-iIoO/td-p/34938

[the_rock · Accepted solution]

FWIW, here is AI explanation.

**************************************

You’re not alone—Check Point’s packet path is not the same mental model as many other firewalls, and a lot of “AI summaries” mix vendors/versions and end up contradicting themselves.

Below is the practical, Check Point–accurate way to think about it (for “normal” firewalling; acceleration changes where things happen, but the logical order is the same).

---

1) Short answer (what happens first: Access Policy or DNAT?)

✅ In Check Point, Access Policy lookup happens before NAT policy (including DNAT)

Timothy Hall states it directly: “the network policy layer (‘firewall policy’) is referenced prior to the NAT policy” [community….kpoint.com]

And in his i/I/o/O breakdown (unaccelerated traffic), he lists Access Control policy evaluation and only then Destination IP NAT (DNAT) on the inbound side [community….kpoint.com]

So the simplified sequence for a new connection is:

1. Inbound checks (anti-spoof, etc.)
2. Security Policy / Access Control match
3. DNAT
4. Routing
5. SNAT
6. Forward out

This is not “opinion”—it’s consistent with CheckMates material and how the kernel chain is designed. [community….kpoint.com], [community….kpoint.com]

---

2) The clearer picture: i / I / o / O (where DNAT & SNAT actually occur)

The best mental model is Check Point’s common troubleshooting capture points:

• i = pre-inbound (packet just arrived)
• I = post-inbound (after most inbound inspection)
• o = pre-outbound (before outbound processing)
• O = post-outbound (ready to leave)

Timothy Hall’s breakdown (for unaccelerated / F2F path) is:

Between i → I (inbound side)

Most enforcement happens here, including:

• inbound anti-spoofing
• decryption (VPN / HTTPS inspection where applicable)
• connection/state table lookups
• Access Control policy evaluation
• Destination NAT (DNAT)
• Threat Prevention policy evaluation [community….kpoint.com]

Between I → o

• Gaia routing decision happens here [community….kpoint.com]

Between o → O (outbound side)

• outbound operations including
• Source NAT (SNAT)
• encryption (VPN / HTTPS as applicable) [community….kpoint.com]

Important nuance: these four points are mainly meaningful for non-accelerated traffic; accelerated flows can take shorter paths. [community….kpoint.com]

---

3) “But why does DNAT need to happen before routing?”

Because the OS routing table is what actually forwards packets, and it needs to route using the post-DNAT destination in most designs.

PhoneBoy (Check Point admin) explains the key reason plainly:

If DNAT is not done before OS routing, you’d need static routes for the pre-NAT destination. [community….kpoint.com]

So even though policy is evaluated before NAT, DNAT still happens before the routing lookup step (which is later, between I and o). [community….kpoint.com], [community….kpoint.com]

Also, Check Point notes there’s a Global Properties option to adjust legacy behavior (i.e., when DNAT vs routing occurs). [community….kpoint.com]

---

4) Your second question: why DNAT first, then SNAT later—why not “both at once”?

✅ Because DNAT affects routing, while SNAT often depends on routing/egress

From the same iIoO breakdown:

• DNAT is part of inbound-side processing (i→I) [community….kpoint.com]
• routing happens after inbound processing (I→o) [community….kpoint.com]
• SNAT happens on the outbound side (o→O) [community….kpoint.com]

That ordering exists for real functional reasons:

(A) DNAT must happen before routing can be correct

If destination is translated to an internal host/network, the kernel must hand the packet to Gaia routing with the real destination, otherwise routing might be wrong (or require special routes). [community….kpoint.com], [community….kpoint.com]

(B) SNAT may require knowing the egress interface / next hop

Many SNAT designs are “hide behind egress interface address” or depend on which uplink is chosen. That decision can’t be final until routing/forwarding is known (which occurs between I and o). [community….kpoint.com]

(C) It matches the kernel module chain architecture

Check Point exposes this in the kernel chain/module concept (what fw ctl chain shows). The CLI guide explains that fw ctl chain lists the inspection modules traffic passes through.
In the example output, you can literally see separate inbound/outbound processing modules, including things like fw VM inbound and outbound NAT-related modules (e.g., “vpn nat outbound” in the sample chain). [sc1.checkpoint.com]

So: two-stage NAT is not arbitrary—it aligns with the OS routing dependency and the inbound/outbound chain design. [community….kpoint.com], [community….kpoint.com], [sc1.checkpoint.com]

---

5) One more nuance that causes a lot of confusion (Automatic NAT vs Manual NAT)

You might think:

“If policy happens before NAT, how does inbound traffic to the public IP match a rule that uses the private server object?”

Timothy Hall explains why:

• With Automatic NAT configured on an object, that same object can match both the real IP and the NAT IP during policy evaluation. [community….kpoint.com]
• With Manual NAT, you often model the NAT IP as a separate object, and then you must reference the correct one in the Security Policy because policy is evaluated before NAT. [community….kpoint.com]

This is one of the biggest sources of “it works but I don’t understand why.”

---

6) A practical “cheat sheet” flow (typical inbound to DNAT’d server)

Inbound packet arrives (ethX)

1. Anti-spoof / sanity checks / decrypt if applicable [community….kpoint.com], [sc1.checkpoint.com]
2. Security Policy match (Access Control) [community….kpoint.com], [community….kpoint.com]
3. DNAT applied [community….kpoint.com]
4. Gaia routing lookup decides egress interface [community….kpoint.com]
5. Outbound side: SNAT applied (if needed) [community….kpoint.com]
6. Forward out

---

7) If you want to prove it on your own gateway (best troubleshooting approach)

• Run fw ctl chain to see the enabled chain modules and their order (will vary by blades/features). Check Point documents this command as showing “inspection Chain Modules, through which the traffic passes.” [sc1.checkpoint.com]
• Use fw monitor at i/I/o/O to observe where NAT/decrypt/routing effects become visible (works best for non-accelerated flows, as noted). [community….kpoint.com]

---

Quick follow-up (so I tailor the explanation to your exact environment)

1. Which version (R80.40 / R81.x / R82.x)?
2. Is this manual NAT rules or mostly object/automatic NAT?
3. Are you doing HTTPS Inspection or IPsec VPN on the same traffic?

If you share one concrete example (src/dst/service + NAT rule + access rule), I can walk through exactly which object matches where and why, and what you should see at i/I/o/O in fw monitor.

[PhoneBoy]

The AI response includes stuff from this thread, interestingly enough.
Even quotes me 🙂

[the_rock]

Even all AI engines know who is the TRUE LEGEND 😉

[Timothy_Hall]

Most AI responses I've seen about topics such as these have been pretty bad, but this one was...actually...100% accurate?

Hmm, maybe there is something to this AI thing after all.  😀

[the_rock]

Haha...its actually MS Copilot AI gpt 5.2 version, "think deeper" setting...guess it outsmarts others? lol

[Vineethkumar]

Thanks for response. I got into another doubt/ confusion in between Anti spoofing and VPN decryption.   I was practicing site to site VPN in the lab env. I generated traffic from 192.168.197.10 ip  to 192.168.190.1 IP,  I configured ESP packet IP address to use main address i.e  gateway's management, so ESP packet arrived at management interface eth0 instead of my expected interface eth1. That packet was dropped by gateway showing the reason address spoofing. So here Decryption was done first and then antispoofing done next on the actual packet and that's the reason why packet with internal LAN address arriving on incorrect interface has been dropped for address spoofing reason. I changed the ESP packet address to Interface IP of gateway, so when packet arrived at gateway 2, gateway2 accepted and decrypted it

Here my query is.. Decryption first and then antipsoofing next?  Is  Antispoofing performed twice on both headers ie ESP and actual packet header?  first on ESP packet header with main IP or gateway's Interface IP and then after decryption, second time on actual packet with LAN IP address.  Or else Antispoofing  happens only once  after decryption on actual packet ? 

[PhoneBoy]

Anti-spoofing checks both the encrypted and unencrypted packet, to the best of my knowledge.

Considering you were using the eth0 IP as the main IP for VPN and both gateways are on that same subnet, surely that packet did not violate anti-spoofing.
However, once the packet was decrypted, the source IP didn't match the anti-spoofing configuration for eth0...thus the "address spoofing" message. 

[the_rock]

I believe anti-spoofing would always take precedence.