The scenario
Two identical paths side by side. On top, Client-A (10.0.1.10) reaches Server-A (10.0.10.10) through FW-Stateful. Below, Client-B (10.0.2.10) reaches Server-B (10.0.20.10) through FW-Stateless. Each firewall has one rule at priority 10: allow TCP port 80 from the client subnet to the server subnet. FW-Stateful tracks connections, so it recognises the server's answer as part of a conversation it allowed. FW-Stateless has connection tracking switched off: it judges the answer as a brand-new packet, finds no rule for traffic from the server subnet, and drops it. Client-B's request arrives at Server-B, but the reply never makes it back.
What you will work out
Understand what connection tracking does, why a stateless filter needs rules for both directions, and how this maps to AWS security groups and network ACLs.
Why this matters
Knowing which kind of filter you are writing for decides whether you must think about return traffic. The classic symptom of getting it wrong is a connection that hangs: the request arrives, the server answers, and the answer is dropped on the way back. On AWS this is the difference between a security group, which needs only the inbound rule, and a network ACL, which also needs an outbound rule for the replies.
Running it
Stateful vs Stateless Firewall opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.
Open Stateful vs Stateless Firewall
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →