AddySec AddySec
Learning / network security

Firewalls — How They Actually Decide Allow or Deny

beginner firewallpolicystateful-inspection

A firewall’s core job sounds simple — allow or deny traffic — but understanding how it makes that decision is what separates reading a policy from actually understanding one.

Stateless vs. stateful inspection

Stateless (packet filtering) — every packet is evaluated in isolation against a rule set: source IP, destination IP, port, protocol. The firewall has no memory of previous packets. This is fast but limited — you’d need explicit rules for both directions of every conversation.

Stateful inspection — the firewall tracks active connections in a state table. Once a session is allowed (e.g. an outbound HTTP request), the firewall automatically permits the matching return traffic, without needing a separate inbound rule. Almost every modern firewall (FortiGate, Palo Alto, Cisco ASA/Firepower) works this way by default.

This is why you typically only write outbound-allow rules for internal-to-internet traffic — the state table handles the return path automatically.

How policy order matters

Firewall policies are evaluated top-to-bottom, first-match-wins in most platforms. This means:

  • A broad “allow all” rule placed too high in the list can silently make every rule below it irrelevant.
  • A narrow, specific deny rule needs to sit above a broader allow rule that would otherwise catch that traffic first.

A huge share of real-world firewall misconfigurations aren’t wrong rules — they’re right rules in the wrong order.

What a firewall actually checks, in sequence

  1. Interface/zone — which network segment is this traffic coming from and going to?
  2. Source and destination address — does it match the rule’s defined objects?
  3. Service/port and protocol — TCP/UDP and the specific port(s)
  4. Action — allow, deny, or (on next-gen firewalls) apply additional inspection like IPS/AV before deciding

Next-generation firewalls add more: application identification (not just port-based), user identity, and threat inspection — but the base allow/deny logic above still applies underneath all of that.

Key takeaway

Reading a firewall log or policy isn’t about memorizing syntax — it’s about mentally re-running this same sequence: which zone, which addresses, which service, and where does this rule sit relative to everything else in the list.