Visual walkthrough — Firewalls — stateless vs stateful packet filtering

---

Step 1 — What is a packet, and what does a firewall actually see?

WHAT. A packet is one small envelope of data travelling across the network. Like a real envelope, it has writing on the outside (the header) and a message inside (the payload). A packet-filtering firewall reads only the outside writing.

WHY. Reading the outside is fast and cheap — the firewall never has to open the letter. The four pieces of writing it cares about are exactly the ones from the parent note's table: the two addresses (who sent it, who it's for), the protocol, the two ports, and — for TCP — the flags.

PICTURE. Look at the envelope. The burnt-orange band is the header the firewall reads; the pale inside is the payload it ignores.

---

Step 2 — The 5-tuple: a connection's fingerprint

WHAT. Pick five fields off the header and staple them together. That bundle is the 5-tuple — a single label that names one specific conversation:

$\underset{\text{who sent it}}{\underbrace{(\text{srcIP}}},\underset{\text{who it’s for}}{\underbrace{\text{dstIP}}},\underset{\text{sender’s apartment}}{\underbrace{\text{srcPort}}},\underset{\text{receiver’s apartment}}{\underbrace{\text{dstPort}}},\underset{\text{TCP or UDP}}{\underbrace{\text{proto})}}$

Each label under a symbol tells you what that symbol is doing: the two IPs are the buildings, the two ports are the apartments, the protocol is the language.

WHY. We need one handle that means "this browsing session and no other." If your laptop opens two tabs to the same server, the srcPort differs, so the two 5-tuples differ — the firewall can tell them apart. This is the atom everything else is built from.

PICTURE. Two machines, one arrow between them, and the five fields lifted out and boxed as the fingerprint.

---

Step 3 — The stateless decision: one packet, no memory

WHAT. A stateless filter runs each packet down an ordered list of rules and takes the first one that matches. Written as a decision:

$\text{decision}(p)=\text{firstMatch}(p.\text{header},\text{ruleList})$

Here $p$ is this packet, $p.\text{header}$ is the writing from Step 1, and $\text{firstMatch}$ means "walk the list top-down, stop at the first rule whose conditions all fit." Notice what is absent: no term for past packets. That absence is the whole meaning of "stateless."

WHY. Simplicity and speed. No memory to store, nothing to look up — just compare header fields to constants. This is what makes Access Control Lists (ACLs) on routers so fast.

PICTURE. A packet drops into a stack of rules; the first matching rung fires and everything below is skipped.

---

Step 4 — The return-traffic problem, and the ACK trick

WHAT. You send a request out; the reply comes in. The stateless filter has no memory that you started the chat, so it must decide about the inbound reply using the header alone. The trick: allow inbound TCP only when $\text{ACK}=1$.

WHY. Recall the TCP Three-Way Handshake. The very first packet of any new connection is a lone SYN with $\text{ACK}=0$. Every packet after that carries $\text{ACK}=1$. So:

$\text{ACK}=1\Rightarrow \text{"this is not the first packet of a new conversation"}$

The arrow reads: if the ACK bit is set, then (we hope) it belongs to something already going. "Allow inbound only if $\text{ACK}=1$" therefore lets replies pass while blocking an attacker's opening SYN.

PICTURE. Two timelines side by side: a real reply (ACK=1, passes) and a stranger's opening SYN (ACK=0, blocked by needing ACK=1).

---

Step 5 — The edge case that breaks the trick: the spoofed ACK

WHAT. An attacker hand-builds a packet with $\text{ACK}=1$ that belongs to no real connection — it never did a handshake. This is an ACK scan / spoofed probe.

WHY it slips through. The stateless filter's only test is the flag. The forged packet shows $\text{ACK}=1$, matches rule 2, and is allowed. The filter had no way to ask "did I ever see the SYN that started you?" — because it remembers nothing. This is the degenerate case the parent note warned about, and it's the seed of a probe/scan.

PICTURE. A red forged packet with the ACK bit ticked walks straight past the stateless door — no handshake behind it.

---

Step 6 — Adding memory: the state table

WHAT. Give the firewall a notebook: the state table. Every time an outbound packet is allowed to start a connection, write down its 5-tuple and its phase:

$\text{StateTable}=\{(\text{5-tuple},\text{tcpState}),\dots \}$

Each row is one live conversation. $\text{tcpState}$ moves through phases — $\text{SYN\_SENT}\to \text{ESTABLISHED}\to \text{closed}$ — mirroring the TCP Three-Way Handshake.

WHY. Now the return-traffic question stops being a guess. Instead of trusting a flag, the firewall looks up the reverse 5-tuple (swap src↔dst, srcPort↔dstPort) and asks: is this row in my notebook?

PICTURE. The notebook: outbound SYN writes a row; the arrow shows the state advancing as the handshake completes.

---

Step 7 — The stateful decision, and why it beats the trick

WHAT. The stateful return rule collapses to a single, honest test:

$\text{allow}(p)⟺\underset{\text{I remember you}}{\underbrace{p\in \text{StateTable}}}\vee \underset{\text{policy lets you start}}{\underbrace{\text{matchesExplicitAllow}(p)}}$

The left branch means "the reverse 5-tuple is a row in my notebook." The right branch is the ordinary policy for starting new allowed flows. No fragile ACK check anywhere.

WHY it kills the spoof. Feed in the attacker's forged ACK from Step 5. Its 5-tuple is not in the table (no handshake ever wrote it), and it matches no explicit ALLOW → DROP. The firewall answered "did I ever see your SYN?" with a truthful "no."

PICTURE. Same three packets — legit reply, forged ACK, data packet — each queried against the notebook: two found (ALLOW), one absent (DROP).

---

Step 8 — The stateful firewall's own weak spot: state exhaustion

WHAT. The notebook is finite. An attacker floods you with millions of opening SYNs (a SYN flood), each of which creates a half-open $\text{SYN\_SENT}$ row that never completes.

WHY it's the mirror image of Step 5. Stateless firewalls have no table, so they cannot be exhausted — they shrug off a SYN flood. Stateful firewalls gain security by having memory, and that same memory is the resource an attacker fills up. Security and vulnerability come from the exact same feature. (A DoS against the firewall itself.)

PICTURE. The notebook overflowing with half-open $\text{SYN\_SENT}$ rows; legitimate rows can no longer be added.

---

The one-picture summary

Everything above on one canvas: an outbound SYN writes a row (memory born); the real reply and later data are matched and allowed; the forged ACK finds no row and dies; and the flood of half-open rows is the stateful box's Achilles' heel.

Recall Feynman retelling — the whole walkthrough in plain words

A packet is an envelope; the firewall reads only the label (Step 1). Staple five fields off that label and you get a fingerprint naming one exact conversation (Step 2). A forgetful guard just checks each envelope against a list of rules, top to bottom, first match wins — no memory at all (Step 3). Trouble: your replies come in, and with no memory he must trust a flag — "let it in if the ACK bit is set," because real replies always have it and a stranger's first knock doesn't (Step 4). But anyone can paint the ACK bit on a fake envelope, and the forgetful guard waves it through (Step 5). So we hand the guard a notebook: every time he lets a conversation out, he writes it down (Step 6). Now the reply rule is honest — "let it in only if it's in my notebook" — and the painted-on ACK, having no page, is turned away (Step 7). The catch: the notebook has finitely many pages, so a mob of fake half-started conversations can fill it up and jam him — the forgetful guard, having no notebook, can't be jammed that way (Step 8). Memory is both his strength and his weakness.

Recall Quick self-test

What makes a filter "stateless"? ::: Its decision uses only the current packet's header and the rule list — no memory of past packets. Why does "allow inbound if ACK=1" leak? ::: An attacker can forge a packet with ACK=1 that belongs to no real connection; the flag alone can't prove membership in a flow. How does a stateful filter reject that forged ACK? ::: It reverses the 5-tuple, searches the state table, finds no matching row, and drops it. Which firewall is vulnerable to a SYN flood, and why? ::: Stateful — each half-open SYN creates a table row, so millions of them exhaust its finite memory. Why does the stateless box shrug off that same SYN flood? ::: It keeps no per-connection state, so there is no table to exhaust.