FUNDAMENTALS · MECHANISM WALKTHROUGH

Inside the Firewall
Packet Arrival to Forward or Drop

the internal pipeline of a single packet — and why every packet after the first one in a flow takes a dramatically cheaper path through the exact same firewall.

INGRESS + ZONE→ SANITY / ANTI-SPOOF→ SESSION LOOKUP→ FAST PATH / SLOW PATH→ POLICY MATCH→ NAT DECISION→ SECURITY PROFILES→ SESSION INSTALLED→ EGRESS

01 The Full Sequence — Worked Example

Packet Arrives — Interface Maps to a Zone

An internal host's first packet toward an external HTTPS site (443) arrives on the firewall's LAN interface. That interface is mapped to a security zone — e.g. "LAN" — which is the very first classification the firewall makes, before it looks at a single header field beyond the physical port.

Ingress

Sanity and Anti-Spoofing Checks

Before any policy is even consulted, the firewall runs basic sanity checks: malformed headers, checksum validity, and often a reverse-path check — is this source IP plausible arriving on this interface, given the routing table? A packet failing these is dropped immediately, with no policy lookup ever performed.

Sanity

Session Table Lookup — The 5-Tuple

The firewall computes the packet's 5-tuple (source IP, destination IP, source port, destination port, protocol) and checks its live session table for a matching, already-established session.

Session Lookup

Checkpoint — Fast Path vs. Slow Path

This is the fork the entire mechanism hinges on. Match found (fast path): the packet reuses the forwarding, NAT, and security decisions already recorded for that session — no policy re-evaluation, no security-profile re-inspection, dramatically cheaper. No match (slow path — true for this first packet of a brand-new flow): the full pipeline below runs once, and the resulting decision is what gets cached as a session for every subsequent packet.

Checkpoint

Route Lookup

For this new session, the firewall consults its routing table to determine the likely egress interface/zone for the destination. On zone-based platforms this typically has to happen before policy evaluation, since policies are matched by source/destination zone, not just IP.

Route

Policy / Rule Base Evaluation

Rules are evaluated top-down, first-match: source zone/IP, destination zone/IP, service/port, and on NGFW platforms, application signature. The first rule that matches wins. A matching deny drops and logs the packet here. A matching allow continues — but note this isn't necessarily the final word (see step 8).

Policy

NAT Decision

If the matched policy specifies NAT — source NAT for this outbound flow, or a destination NAT/VIP for an inbound one — the translation is determined here, tied to the specific policy that matched.

NAT

Security Profile Inspection

For this HTTPS flow, security profiles attached to the policy may run: SSL inspection (decrypt, inspect, re-encrypt, if configured), IPS signature matching, antivirus scanning, and web filtering category lookup. Critically, any one of these can still drop or reset the connection even though the base policy already said "allow" — a policy match is a permission to proceed to inspection, not a final verdict.

Security Profiles

Session Installed

A new session table entry is created, recording the matched policy ID, the NAT mapping, the security profile verdicts, and session timers. This is exactly the entry step 4's fast path will match against for every subsequent packet of this same flow — in both directions.

Session

Forwarded Out the Egress Interface

The packet is forwarded out the interface determined in step 5, with NAT applied per the decision in step 7, on its way toward the internet.

Egress

Logging

A traffic log entry is generated (and updated as the session continues) recording the decision, the matched policy, and eventually bytes transferred and session duration — independent of whether a given packet was the very first (SYN) or somewhere in the middle of a long-lived flow.

Logging

Return Traffic — Straight to the Fast Path

The server's reply arrives with the 5-tuple reversed, hits the session table from step 9 as an immediate match, and takes the fast path from step 4 — no policy re-evaluation, un-NAT applied, forwarded straight back to the internal host. This is the concrete mechanism behind "stateful firewalls don't need a separate inbound rule for return traffic."

Return

02 How to Explain This in an Interview

Organize your entire answer around "first packet vs. every packet after it." That's the actual shape of the mechanism — leading with it turns a long pipeline into one clear idea with supporting detail.
State the order precisely if asked: sanity/anti-spoof checks happen before session lookup, which happens before policy, which happens before NAT, which happens before security profiles. Getting this order right (or admitting platform variation exists) reads as real hands-on depth.
Say explicitly that security profiles can override an "allow" policy match. It's a frequently misunderstood point and a strong signal you've actually operated an NGFW/UTM, not just a basic ACL-style firewall.
Bring up SSL inspection if the scenario is HTTPS. Mentioning that the firewall can decrypt, inspect, and re-encrypt (with the trust/certificate implications that come with it) shows platform-specific depth beyond textbook packet filtering.
Close by tying it back to statefulness — the session table is what makes return traffic "just work" without a mirrored inbound rule, which is usually the deeper point this question is fishing for.

03 Follow-Up / Gotcha Questions

Q What's the actual performance benefit of the fast path vs. re-evaluating policy on every packet?

A A session table lookup is a simple hash/key match — computationally trivial compared to walking a rule base top-down and running full security-profile inspection on every single packet. For a firewall handling thousands of concurrent sessions, re-running the full slow path on every packet would be prohibitively expensive; the fast path is what makes line-rate stateful inspection feasible at all.

Q Can a security profile really drop a connection the base policy already allowed?

A Yes — a policy's "allow" only means "this traffic is permitted to be inspected further." If IPS matches an exploit signature, or antivirus finds a malicious payload, or web filtering categorizes the destination as blocked, that profile can reset or drop the session independently, even though the base rule matched as allow.

Q What is a reverse-path (anti-spoofing) check, and why run it before policy lookup?

A It verifies that the source IP of an arriving packet is plausible given which interface it arrived on and what the routing table says about that subnet — catching packets with spoofed source addresses that wouldn't normally be reachable that way. It runs early precisely because there's no point evaluating policy for a packet that's already provably forged.

Q Does NAT get applied at policy-match time or at actual forwarding time?

A The decision of what NAT to apply is determined during policy match (which policy matched dictates the NAT rule), but the actual header rewrite is typically performed during forwarding, right before the packet leaves the egress interface — the distinction matters when troubleshooting why a security profile might see pre- or post-NAT addressing depending on where in the pipeline it inspects.

Q What happens to a packet that matches no policy at all?

A It hits the implicit deny at the bottom of the rule base — nearly every firewall platform defaults to deny-all for anything that falls through every explicit rule, and the packet is dropped and typically logged as an implicit-deny hit, distinct from an explicit deny rule match.

Q Why does route lookup sometimes need to happen before policy evaluation instead of after?

A On zone-based platforms, policies are written against source and destination zones, not raw IPs — and the destination zone for a new session can only be known once the firewall has determined the likely egress interface via a routing lookup. Without that, there'd be no way to know which zone-pair a policy needs to match against.

04 Quick-Fire Glossary

Term	Meaning
5-Tuple	Source IP, destination IP, source port, destination port, protocol — the key used to identify a session
Session Table	The firewall's live record of established flows, enabling the fast path for subsequent packets
Fast Path / Slow Path	Cached-session forwarding vs. full policy + security-profile evaluation for a brand-new flow
Zone-Based Policy	Rules matched against logical security zones (interface groupings) rather than raw IPs alone
Anti-Spoofing / RPF	Reverse-path check verifying a source IP is plausible for the interface it arrived on
SSL Inspection	Decrypting, inspecting, and re-encrypting TLS traffic to apply deep inspection to encrypted flows
IPS	Intrusion Prevention System — signature/behavior-based detection and blocking of known exploit patterns
UTM	Unified Threat Management — bundled security profiles (AV, IPS, web filtering) on one platform
Implicit Deny	The default drop-all rule at the bottom of a policy base for traffic matching nothing explicit
VIP / DNAT	Destination NAT mapping a public-facing address/port to an internal server