A stateless firewall (a packet filter) judges each packet on its own, using header fields such as addresses and ports. A stateful firewall also tracks each connection in a state table and blocks packets that do not fit the expected state of that connection, which stops many spoofed packets.
How does a stateless packet filter decide?
It reads the headers of each packet and compares them with a rule list: allow TCP to port 443 from this network, deny the rest. It remembers nothing. NIST SP 800-41 notes that stateless packet filters are generally vulnerable to attacks that exploit problems in the TCP/IP specification and protocol stack. For instance, many cannot tell when a packet's addressing information has been spoofed or altered.
That memorylessness has a practical cost. To let reply traffic back in, you must write rules that allow broad ranges of return packets, because the filter cannot know which replies match a request that went out.
What does a stateful firewall add?
NIST describes stateful inspection as improving on packet filters by tracking the state of connections and blocking packets that deviate from the expected state. The firewall keeps a state table, whose entries typically include source and destination addresses, port numbers and connection state.
For TCP there are three major states: connection establishment, usage and termination. Each new packet is compared with the table. NIST gives the example of an attacker crafting a packet that claims to belong to an established connection. A stateful firewall first checks that such a connection is actually listed, so the forged packet fails. Many firewalls also check TCP sequence numbers and reject packets that are out of sequence.
What about UDP and other connectionless traffic?
UDP has no handshake, so state cannot be established at the transport layer the way it is for TCP. NIST explains that most stateful firewalls track only addresses and ports, and remove the entry after a configured timeout. A DNS reply from outside passes only if the firewall earlier saw the matching query from inside.
A constructed example
A small office allows staff to browse the web. With a stateless filter the administrator writes an inbound rule allowing packets from any address with a source port of 443, so replies can return. An outside host can send packets with a source port of 443 to any internal machine, and the filter lets them through. With a stateful firewall the administrator writes only an outbound rule. Return traffic is allowed because it matches an entry created when an internal user opened the connection. The unsolicited packets match nothing and are dropped.
Is stateful always better?
For most network boundaries, yes, and NIST observes that most firewalls built on packet filters also keep some state. But the table consumes memory and can be exhausted by floods of half open connections. Stateless filtering is fast and still useful for simple, high volume cases, such as blocking known bad address ranges at a router before traffic reaches heavier devices.
Neither type inspects application content. NIST SP 800-215 describes deep packet inspection, which examines packet payloads as well as headers, and application aware firewalls, which sit above stateful inspection. If you need to block a specific command or file type, you need that layer.
How to check or apply this
- List where filtering happens today: routers, host firewalls, appliances, cloud security groups.
- For each, note whether it tracks state. Check the product documentation, not the marketing name.
- Remove any rule that opens a wide range of source ports to allow replies.
- Set sensible timeouts for UDP entries.
- Watch state table utilization and alert before it fills.
- Keep stateless filters for coarse, early blocking only.
- Test with an unsolicited packet from outside to confirm it is dropped.
Quick check
Do cloud security groups track state?
It depends on the provider and the control type. Read the provider's documentation for each, since some filters are stateful and some are not.
Can a stateful firewall stop malware in web traffic?
No. It tracks connections, not content. Payload inspection or endpoint controls are needed for that.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- NIST SP 800-215, Guide to a Secure Enterprise Network
Last reviewed: 18 October 2026.
