What can a stateful firewall filter on that a stateless packet filter cannot, and why is UDP harder for it to track than TCP?

## Three kinds of firewall, three depths of reading "Firewall" names a purpose, not a layer. What a firewall can filter on depends on **how much of the packet it reads** and **whether it remembers earlier packets**: | Kind | Reads | Remembers flows | Can filter on | |---|---|---|---| | Stateless packet filter | IP header, TCP/UDP header | no | addresses, protocol, ports, TCP flags, one packet at a time | | Stateful firewall | IP header, TCP/UDP header | yes, a flow table | the same fields plus "is this part of a flow already allowed?" | | Application-layer proxy | the application payload | yes, it is an endpoint | commands, hostnames, paths, content | The first two work at **layers 3 and 4**; the third works at **layer 7** because it terminates the connection and parses the application protocol. ## Stateless filtering: one packet at a time A **stateless packet filter** compares each packet, on its own, with an ordered rule list. The rules can match source and destination addresses, the protocol number, source and destination ports and, for TCP, the flag bits. Its blind spot is **direction of conversation**. A rule that lets web replies in must admit inbound TCP from port 443 to high ports, and nothing in one packet proves it answers a request a local host actually made. A common approximation admits inbound TCP only when the **ACK** flag is set, because the first segment of a new connection (the SYN) has no ACK. That blocks unsolicited connection attempts, but any sender can set ACK on a crafted segment, and the filter has no memory to check it against. ## Stateful filtering: a flow table A **stateful firewall** reads the same headers but keeps **per-flow state**, typically keyed by the **five-tuple** (protocol, source address, source port, destination address, destination port, the identifier RFC 6056 uses for a communication instance). RFC 8085 §3.5 describes the usual pattern for middleboxes such as NATs and firewalls: - one side is treated as **interior**, the other as **exterior**; - state is created when the first packet of a flow crosses from interior to exterior; - while the state exists, **return traffic is forwarded**; - return traffic arriving after the state has expired is dropped, as is other traffic arriving from outside. That is what a stateless filter cannot do: allow a reply **because** a matching request went out. ## TCP: the protocol tells the firewall when flows start and end For connection-oriented protocols, RFC 8085 says, middleboxes "snoop and parse the connection-management information" and create and destroy state accordingly. With TCP that means following the **SYN**, **FIN** and **RST** segments; in a typical implementation: 1. an outbound SYN creates a pending entry; 2. the reply completing the handshake confirms it; 3. FIN exchanges or an RST remove it. Implementations also age out TCP entries that stay idle for long, with timeouts that are an **implementation choice**. When that happens the endpoints still believe the connection is open, and the next segment either sends matches no entry. ## UDP: the firewall has to guess UDP has **no connection setup and no teardown**, so, per RFC 8085, a middlebox creates state when a packet "according to some local criteria" looks like a new flow and **destroys it after a period with no packets** in that flow. The numbers around this are worth knowing, and whose they are: - RFC 8085 records that NATs are required to keep UDP state for **2 minutes or longer** (citing RFC 4787), and that many deployed middleboxes use shorter timeouts; - an application that needs keep-alives to hold that state **SHOULD NOT** send them more often than **once every 15 seconds** (RFC 8085), and keep-alives are not recommended for general use; - RFC 9000 reports that, in practice, sending packets **every 30 seconds** is needed to keep the majority of middleboxes from losing UDP state. Short request-response exchanges such as DNS, which RFC 8085 notes typically complete within seconds, rarely hit these limits; long-lived, mostly idle UDP sessions are what break. ## QUIC: a transport the firewall cannot follow QUIC (RFC 9000) runs over UDP and gives its packets confidentiality and integrity protection, packet numbers included. Most of its connection management travels inside protected packets, so a firewall generally cannot follow a QUIC connection the way it follows TCP flags. In practice it tracks QUIC as a UDP flow with an idle timer. ## What neither firewall sees Neither a stateless nor a stateful firewall reads the **application payload**. It cannot block one URL path, one SQL statement or one mail command. That needs an **application-layer proxy**: a device that accepts the client's connection, parses the protocol, applies its policy and opens its own connection onward. For HTTPS it must also terminate TLS, since the payload is encrypted.