Why does a stateful firewall's session table fill with strangers when only one port is open?

## What statefulness actually buys A stateless filter decides each packet on its headers alone. To let a client talk to your web server you must permit the request inbound and permit *something* back outbound, and that return permission is written in terms of header fields the sender chooses. Anyone can set those fields. A stateful filter buys you a better property. When it permits the first packet of a flow it writes an entry into a **session table** and, from then on, the return direction is permitted **because the entry exists**, not because any rule describes it. The reply is admitted only if it belongs to a conversation the firewall watched begin. That is the "replies only" guarantee, and it is genuinely worth money: it removes an entire class of forged inbound traffic that a stateless return rule would have to allow. ## What it costs, and who gets to spend it The entry is not free and it is not unlimited. Each one is a record: the five-tuple, the current protocol state, timers, counters, often the matched policy and any translation. Every platform has a **maximum concurrent sessions** figure, usually tied to the model or licence tier, and it is a hard ceiling rather than a soft one. The question that catches people out is *who is allowed to spend that budget*. The intuition is that the rule base controls it: we only permit one port, so surely we control the load. That is the wrong answer. The rule base controls **what** is permitted; the table records **how many** permitted flows currently exist. A policy line that reads "any source to 198.51.100.7 on TCP 443" deliberately names an unbounded source population. Every one of those sources allocates an entry by sending a single packet, and no rule you can write gets to cap the count without also breaking the service you published. That is the conjunction the interviewer is probing. There is an adversary in the loosest sense of the word: not necessarily anybody attacking you, just an unbounded set of strangers whose arrival rate is not yours to control, plus the occasional badly-behaved client that opens connections and walks away from them. And there is a bill: a fixed number of entries, on a box you bought, with a licence tier attached. ## Entries do not care whether the flow is useful Three things surprise people about how entries are consumed: - **A half-formed TCP connection costs a full entry.** The firewall must remember the SYN it forwarded so that it can recognise the SYN-ACK as a legitimate reply. That means the entry is allocated on the first packet, long before anything is established. It is usually held under a separate, much shorter embryonic timeout, but while it is held it occupies the same slot as a busy flow. - **A finished flow may still cost an entry.** If the application never closes cleanly, the entry lives until an idle timer expires. UDP has no close at all, so a UDP entry always lives out its idle timeout regardless of how briefly the application actually spoke. - **A denied packet usually costs nothing.** On most stateful designs, policy is evaluated for the first packet and an entry is created only for a permitted flow. This is the point that turns the whole question around: the traffic that fills your table is the traffic you **allow**, on purpose, from the sources you deliberately published to. ## Why this matters at the interview The wrong answer that a competent engineer gives is "my inbound policy is tight, so my exposure is bounded". Tight policy bounds exposure to *services*; it does not bound consumption of *state*. The two are different resources with different owners: you own the rule base, and your customers plus the rest of the internet own the arrival rate. The operational consequence is worth memorising because it is what you will actually be paged for. A firewall at its session ceiling does not slow down gracefully. It keeps forwarding every flow that already has an entry and refuses to create new ones. The symptom reported to you is "nobody new can log in, but people already logged in are fine" — which reads exactly like an application bug and gets sent to the wrong team first. Recognising that shape as a state-table ceiling rather than a bandwidth problem is most of the value of understanding what an entry is. The follow-on, which the rest of this topic covers, is what you can do about it: you cannot cap arrivals, so you can only shorten how long each entry lives, buy a larger ceiling, or give up the "replies only" property for some flow class and stop tracking it.