A stateless firewall forgets every packet the moment it has passed. A stateful firewall remembers the conversation. That single difference shapes how you write rules, how much hardware you need, and why a session sometimes dies halfway through while the firewall log stays suspiciously quiet.
Both types still make an allow-or-deny decision per packet, and both can be configured default-deny. The distinction is context: whether the device knows that the packet in front of it belongs to a connection it already approved. That is the whole argument, and it is worth understanding properly before you buy anything or rewrite a rule set.
What "state" actually means
A connection is usually described by five things: source IP, source port, destination IP, destination port, and protocol. When your laptop opens a page, it sends a TCP SYN from a random high port to port 443 on the server. The server answers with SYN-ACK to that same high port. Your laptop replies with ACK. Three packets, one flow, and the flow continues until someone sends FIN or RST, or the connection times out.
A stateless device looks at each of those packets in isolation and has no idea they are related. A stateful device writes a row into a connection table on the SYN, matches the SYN-ACK and ACK against that row, and deletes the row when the conversation ends. Everything else is a consequence of that difference.
How a stateless firewall handles traffic
Stateless filtering, sometimes called packet filtering, checks each packet against a list of rules using header fields: addresses, ports, protocol, TCP flags, and ICMP types. The first rule that matches wins, so rule order matters more than most people expect.
The practical consequence is that you must describe traffic in both directions. If you allow workstations to reach the web, you also need a rule for the replies coming back. A typical pair looks like this in the abstract:
- Outbound: allow internal hosts to any external address on TCP port 443.
- Inbound: allow any external host on TCP source port 443 to internal high ports, but only when the ACK or RST flag is set.
That second rule is the awkward part. Because there is no memory of who started what, you are forced to open the return path broadly. Flag checks help for TCP, but UDP has no flags at all, so a rule permitting DNS replies from port 53 on any address is effectively a wide door. Stateless UDP filtering is loose by nature; there is no way around it.
What you get in return is speed and predictability. No table, no memory footprint, no session expiry logic. Hardware and firmware can evaluate stateless rules at line rate, which is why they survive on routers, switches, and cloud network ACLs.
How a stateful firewall handles traffic
A stateful firewall evaluates the first packet of a flow against your rules, then creates a state entry. Return traffic that matches that entry is permitted automatically, even if no rule explicitly allows it. When the connection closes or the timeout expires, the entry disappears.
Most implementations also label entries by state, so you can distinguish a genuinely new connection from one related to an existing session, which is how protocols like FTP and SIP get handled without opening a huge port range. Established TCP entries are typically kept for hours, while UDP and ICMP entries expire in seconds or minutes. That asymmetry is deliberate: a UDP entry that lingers is an open door with nobody watching it.
The trade-offs are resource-related and operational. The table has a maximum size, so a burst of connections, a scan, or a misbehaving application can fill it and cause new sessions to be dropped. Devices restart and lose their table, which kills every active session unless the platform synchronises state between cluster members. Asymmetric routing, where the reply comes back through a different path than the request, breaks stateful inspection cleanly.
The differences that matter in practice
- Rules needed: stateless requires two rules per flow, stateful typically one.
- Return traffic: automatic with state, hand-written without it.
- Resource use: stateless is nearly free; stateful consumes memory and CPU per connection.
- Protocol awareness: stateful understands session context, stateless sees only headers.
- Failure behaviour: losing a stateless device costs nothing; losing a stateful one drops live sessions.
- Logging quality: stateful logs show a session starting and ending, stateless logs a wall of individual packets.
Where stateless filtering still earns its keep
Do not treat stateless as legacy. Most well-built perimeters use both. Stateless rules placed ahead of the state table can drop malformed packets, spoofed source addresses, and known-bad ranges before they consume a session entry. Cloud platforms make the split explicit: network ACLs are stateless, security groups are stateful, and mature designs use ACLs for coarse filtering and groups for the real work. Routers and switches with hardware ACLs are also stateless, and they are the right tool when you need to filter a very large volume of traffic cheaply.
Choosing for a small or mid-sized network
Small office, up to roughly 50 users
Use a stateful firewall and stop there. A pfSense or OPNsense box on modest hardware, or a small business appliance from any major vendor, handles this load comfortably, and the time you would spend writing paired stateless rules buys you nothing. Keep a handful of stateless rules at the very top for anti-spoofing and bogons, then work in stateful rules. Check the device's concurrent connection limit before you add a guest network, a VPN, or a backup agent that opens hundreds of sockets.
Mid-sized network, roughly 50 to 500 users
Still stateful at the perimeter, but now the details matter. Segment with VLANs and put stateful filtering between them, not just at the edge. Watch the connection table during peak hours and after adding anything that polls frequently. If you run a high-availability pair, confirm state synchronisation is enabled, or a failover will silently reset every VPN tunnel and file transfer in progress. Keep stateless rules for bogon and spoof filtering, and consider them for rate limiting obvious junk before it reaches the state table.
Signals you need to reconsider
- Connection table usage regularly above half its limit.
- Users reporting random timeouts on long-lived sessions.
- Traffic taking asymmetric paths after a routing change.
- Logs full of state entries for ports you thought were closed.
A practical default
Choose stateful filtering for anything a person or application initiates, and use stateless rules as a cheap pre-filter for traffic you already know is bad. Write your rule sets default-deny, order them from most specific to most general, and document what each rule is for. Then test the boring cases: reboot the firewall during a large download, run a port scan from an internal host, and watch the connection table while everyone signs in on a Monday morning. Those three checks tell you more about your firewall than any specification sheet.
If your network handles regulated data, payment traffic, or contractual security requirements, treat the design decisions here as technical input only and confirm them with a qualified security professional or auditor before you commit.
Photo: Brett Sayles / Pexels