A firewall interview often turns on one follow-up question: if an outbound request is allowed, what permits the reply? The answer separates a packet rule from connection tracking.
Short answer: A stateless firewall evaluates packets without remembering the flow; a stateful firewall maintains a connection table and uses that context when evaluating subsequent packets.[3] With a stateful policy, valid replies to an allowed connection can pass without a separate rule permitting a new connection in the reverse direction; a stateless filter needs rules that permit both directions.[1][2]
Stateful vs stateless firewall: comparison
| Question | Stateless filtering | Stateful inspection |
|---|---|---|
| Does it remember the flow? | No per-flow connection history | Maintains a state table.[3] |
| What informs the decision? | Packet fields and the configured rules | Packet fields, policy and tracked connection context.[3] |
| What permits return traffic? | A matching reverse-direction rule | A valid match to tracked, permitted traffic, subject to implementation.[1][2] |
| Does a TCP ACK prove a connection exists? | A flag match alone cannot prove prior traffic | The firewall can compare the packet with its connection table.[3] |
| Public cloud example | AWS VPC network ACL | AWS VPC security group.[1][2] |
Do not turn this into “stateless is always bad” or “stateful is always faster.” Choose a control for its job, then evaluate policy, throughput, connection capacity and operational requirements rather than relying on the label alone.
A simple TCP packet flow
The following is a fictional explanation, not an executed firewall lab. Assume no NAT and no additional filtering layers. Client 192.0.2.10 uses source port 53000 to connect to server 198.51.100.20 on TCP port 443.
Client Firewall Server
192.0.2.10:53000 198.51.100.20:443
---- SYN --------------------> policy allows new flow ---------->
<--- SYN-ACK ----------------- reply ----------------------------
---- ACK --------------------> connection continues ------------>
The connection can be described by protocol, source address and port, and destination address and port; the state table also records connection state.[3]
With stateful inspection
The firewall checks the initial request against policy and tracks a permitted connection; a TCP entry need not already be fully established to exist in the table.[3] The returning SYN-ACK is evaluated in that connection context rather than treated as an unrelated server-initiated connection.[3] The reply tuple reverses the addresses and ports, so in this example the reply destination is client port 53000, not port 443.
A valid state match is not a promise that every security control permits the packet. For example, an AWS security group can allow a response while a subnet network ACL still blocks it, because the controls operate at different scopes and network ACLs do not automatically allow replies.[1][2]
With stateless filtering
For the same fictional exchange, the conceptual permissions are:
Forward: TCP 192.0.2.10 source 53000 -> 198.51.100.20 destination 443
Reverse: TCP 198.51.100.20 source 443 -> 192.0.2.10 destination 53000
These are an explanation of one flow, not a deployable rule set. A real client can select a different source port for a later connection, so do not hard-code this example port as a general solution. In a stateless design, define the necessary return-port range for the actual clients and platform, while retaining appropriate peer and protocol restrictions.
The reverse rule does not remember that the client sent a request; that absence of connection history is precisely what “stateless” means.[1][3]
What is in the session table?
NIST describes typical state-table entries as source and destination IP addresses, port numbers and connection state; when a firewall also performs NAT, translation information is often included.[3] Exact fields and enforcement checks vary by product.[3]
For troubleshooting, request the session entry for the exact test flow, not merely a screenshot of a broad allow rule. My suggested evidence checklist is:
- Original source and destination addresses and ports.
- Protocol, matched rule and ingress/egress context.
- Current state and remaining lifetime, where exposed.
- Packet or byte counters in each direction.
- Translated addresses and ports, if NAT is involved.
- Which firewall or cluster member owns the flow.
Treat this as an investigation checklist, not a claim that every product displays every field.
Does a stateful firewall work with UDP?
Yes: stateful inspection is not limited to TCP; NIST explicitly discusses tracking UDP and other connectionless traffic.[3] UDP does not acquire a TCP handshake merely because a firewall tracks it; a firewall instead maintains its own context for deciding whether subsequent traffic belongs to an allowed exchange.[3]
For a DNS troubleshooting exercise, record the query's addresses and ports, send the query, and inspect whether the response matches the tracked exchange. If intermittent failures appear only after idle periods, check the product's flow lifetime and the actual time between request and response before changing a timeout. Do not describe the firewall's UDP tracking entry as a TCP-style established connection.
AWS example: security group vs network ACL
AWS security groups are stateful: responses to permitted outbound requests are allowed inbound regardless of the inbound security-group rules, and responses to permitted inbound traffic are allowed outbound regardless of the outbound security-group rules.[2] AWS network ACLs are stateless and do not automatically permit response traffic.[1]
Network ACLs apply as traffic enters or leaves a subnet, not to traffic routed within that same subnet.[1] A security group controls the traffic of its associated resources, such as an EC2 instance.[2]
For an HTTPS client instance, my recommended diagnostic order is: confirm the security-group permission for the request, inspect the subnet ACL in both directions, and then inspect routing and captures. Do not copy an AWS rule layout onto an appliance without checking the appliance's own policy model.
Troubleshooting: request allowed, reply missing
Use this decision table to collect evidence before widening permissions. It is a practical workflow, not a universal vendor packet-processing sequence.
| Observation | Next check |
|---|---|
| Initial SYN never reaches the firewall | Client route, gateway, VLAN and upstream filtering |
| SYN arrives but no session appears | Actual rule match, zones/interfaces, drop reason and connection limits |
| Session appears but only forward counters grow | Server response and return route; capture on both sides |
| Reply crosses a different firewall | Whether that device has the corresponding session and whether supported state sharing is working |
| Failure appears after idle time | Flow timeout, application keepalive behavior and packet timestamps |
| Failure starts after HA failover | Session availability on the new active member, NAT context and routes |
| AWS security group permits the request | Subnet ACL return permissions and any other controls on the path |
The reason to inspect both directions is the dependence on connection context: a stateful firewall compares packets with its own state table, not with an operator's belief that the connection exists.[3] Do not “fix” unexplained drops by disabling state checks or adding an unrestricted inbound allow rule.
Common interview pitfalls
“The ACK flag means the connection is established.” An attacker can set flags; stateful inspection can check whether a corresponding tracked connection actually exists.[3]
“Stateful means application traffic is safe.” Connection tracking and application inspection are different capabilities; NIST separates stateful inspection, application-level analysis and intrusion prevention.[3]
“NAT and stateful filtering are the same thing.” They are distinct functions even when a product stores translation details alongside connection state.[3]
“An allowed reply is an allowed new inbound connection.” A response permission applies to the tracked exchange; it is not a blanket authorization for unrelated inbound traffic.[2]
A concise interview answer
A strong answer would be:
A stateless firewall checks packets against rules without retaining connection history. A stateful firewall tracks connections and uses their state to evaluate subsequent packets. For an allowed HTTPS connection, valid replies can match existing state rather than require permission for a new inbound connection. With stateless filtering, I must account for return traffic explicitly.[1][2][3]
Then add your diagnostic approach: “If replies fail, I verify the actual session, both packet directions, the return path, timeout behavior and any additional stateless filters.”
Related reading
Summary
Stateless filtering asks whether this packet matches a rule; stateful inspection also asks whether it fits a tracked connection.[3] For interview preparation, draw the request and reply with both port numbers, explain what the firewall remembers, and name the evidence you would collect when the reply disappears.
Preparing for a network engineering interview? Practice this answer aloud, then challenge yourself to explain how the same flow behaves with NAT, a subnet ACL and an HA failover.
Post a Comment