A stateful firewall keeps a table of active connections and allows a packet only if it matches a permitted rule or belongs to a connection already in that table. A forged packet claiming to be part of an existing session gets dropped. What it cannot do is read encrypted or tunneled content.
How does it differ from a simple packet filter?
NIST's firewall guidance, SP 800-41 Rev. 1, says stateful inspection improves on packet filtering by tracking the state of connections and blocking packets that deviate from the expected state. It does this by adding awareness of the transport layer. Like a packet filter it intercepts packets at the network layer and checks them against rules. Unlike a packet filter it records each connection in a state table.
NIST says entries typically include source and destination IP addresses, port numbers and connection state information. For TCP it describes three major states: connection establishment, usage and termination, where termination covers both a request to close and a long period of inactivity.
What happens to a forged packet?
NIST's own example is the clearest. An attacker builds a packet with a header indicating it belongs to an established connection, hoping it will slip through. A stateful firewall first checks that the packet belongs to an established connection listed in its state table.
Constructed walk through. An office laptop at 192.168.1.100 opens a connection to a web server at 192.0.2.71. The firewall checks its rule set, permits it and adds a table entry marked as a new session. As the handshake completes, the entry moves to established. Replies from the server match the entry and pass.
Now an outside host sends a packet to the laptop that claims to be an acknowledgment in an ongoing session. A stateless filter that only allows packets with the ACK flag set might let it in. The stateful firewall looks up the sender, receiver and ports, finds no entry, and drops it. NIST adds that many firewalls go further, tracking TCP and UDP state machines and rejecting packets that do not follow them, for example checking sequence numbers and rejecting out of sequence packets.
What does the table cost you?
The table lives in memory and has a limit. Every tracked connection uses space until it ends or times out. CISA describes a SYN flood in its denial of service guidance: the attacker starts connections but never completes the handshake, leaving ports occupied. A device that tracks half open connections has to decide how long to hold them and what to do when the table fills up.
This is a design point, not a flaw to panic over. Ask any firewall you buy or configure three questions: how many concurrent connections it supports, what its timeouts are for half open and idle sessions, and what it does when the table is full. Fail open and fail closed are very different answers.
What can a stateful firewall not see?
NIST is blunt about limits. A firewall can only work effectively on traffic it can inspect. Many protocols use cryptography to hide their contents, and firewalls cannot read encrypted application data such as S/MIME email or manually encrypted files. Traffic tunneled in a way the firewall does not understand, even if not encrypted, cannot be interpreted. The rule set decides what happens to such traffic, so NIST recommends a policy for it.
So a stateful firewall tells you which conversations are allowed to exist. It does not tell you whether an allowed conversation carries something malicious. An HTTPS session to a permitted server passes the same way whether it is a download or a data transfer out.
How to check or apply this
- Start from deny by default: NIST recommends permitting only the traffic the organization needs.
- Write rules for connection initiation direction. Allow inside to outside as needed. Allow outside to inside only to named services.
- Record the state table size, timeouts and full-table behavior of each firewall.
- Alert on table utilization crossing a threshold, such as 70 percent, which is an example number you should tune.
- Log denied packets that look like mid-session traffic with no entry. A burst can be probing.
- Add controls that look inside the traffic when your policy needs it, and decide deliberately how to treat encrypted flows.
- Test rules from outside with a port scan after every change.
Quick check
Does a stateful firewall inspect application content?
Not by itself. It tracks connection state at the network and transport layers. Content inspection needs additional features such as application proxies or intrusion prevention, and it cannot read encrypted data.
Are cloud security groups stateful?
AWS documents its security groups as stateful, so reply traffic for allowed requests is permitted regardless of rules. Other platforms vary, so check the documentation for yours.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- CISA, Understanding Denial-of-Service Attacks
- AWS documentation, Security groups
Last reviewed: 18 October 2026.
