A stateless firewall evaluates each packet against its rules without using the history of earlier packets in the same flow. A stateful firewall can also use information retained about the packet's flow. That extra context helps distinguish a reply to permitted traffic from a separate attempt to start a connection.

The distinction matters whenever communication needs traffic in both directions. An outbound request can satisfy one rule while its response fails another. Understanding who starts the exchange, which addresses and ports reverse, and where connection state is available makes those failures easier to explain.

What a Packet Filter Can Match

Packet filtering commonly uses the source address, destination address, protocol, and transport ports. Depending on the implementation, a rule can also consider Transmission Control Protocol (TCP) flags, an interface, or whether traffic is entering or leaving a particular boundary. These attributes describe the packet being evaluated.

For example, a rule permitting TCP traffic to a server's destination port 443 identifies a possible HTTPS connection. Matching that port rule does not prove that the packet belongs to a connection the firewall previously allowed. A stateless decision has no record of earlier packets in that flow to supply that missing history.

Inbound and outbound are relative to the enforcement point. A client's outbound request becomes inbound traffic at the server's boundary. When reviewing a rule, identify the interface, resource, or subnet it applies to before interpreting its direction.

Following a Request and Its Reply

Consider a client at 192.0.2.47 using local TCP port 52940 to contact 198.51.100.82 on port 443. These are documentation addresses for an illustrative exchange. The client's opening SYN has source port 52940 and destination port 443; the server's SYN-ACK comes back with source port 443 and destination port 52940.

The client then acknowledges the server's response, completing the ordinary TCP handshake. Application data can travel afterward in either direction. The client continues to use port 52940 for that connection, while the server uses port 443.

Return Traffic with Stateless Filtering

A stateless filter needs rules that permit the relevant packets in each direction. Allowing a request to destination port 443 does not, by itself, permit a reply to destination port 52940. The reverse rule must match the response as it actually appears at that boundary.

In practice, clients choose temporary source ports from an ephemeral range, so a return rule often covers more than one destination port. The appropriate range depends on the client and any translation along the path. Copying a broad port range from an unrelated example can allow traffic the application does not need.

A TCP ACK flag can be part of a stateless matching condition, but the flag alone is not evidence that an approved connection exists. It is a value in the incoming packet. A sender can set it without having completed the permitted exchange.

Return Traffic with Connection Tracking

A stateful firewall maintains flow information, commonly including the protocol, addresses, ports, and observed connection progress. It can associate the reverse packet with the original exchange even though the source and destination fields have swapped. A policy can then permit that response because it belongs to an allowed flow.

Connection tracking still needs filtering rules. Observing a packet and creating tracking information does not make the packet authorized. The policy must control which new flows may begin and which tracked packets may continue through the relevant enforcement path.

The exact checks vary. One firewall may primarily match packets by their protocol, addresses, and ports, while another also checks TCP sequence behavior or performs application inspection. The word stateful does not promise every one of those capabilities.

UDP Can Have Tracked Flow State

The User Datagram Protocol (UDP) has no TCP-style connection handshake. A firewall can nevertheless remember a UDP exchange using its addresses, ports, and timing, then recognize packets in the reverse direction. The retained entry represents the firewall's view of that traffic, rather than a connection established by UDP itself.

This is why a connection tracking label such as established should be interpreted within the firewall's tracking model. Linux Netfilter uses tracking states for multiple protocols; its state labels are not simply a copy of the endpoint's TCP socket states. A UDP response can belong to tracked traffic without a SYN ever appearing.

Timeouts provide a way to remove entries when there is no explicit transport-level close. Different implementations can use different timers for one-way UDP traffic and ongoing exchanges. A delayed response arriving after its entry expires may require a separate rule or may be rejected, depending on the policy and tracking behavior.

Operational Costs of Retaining State

Tracking consumes capacity. The Linux connection tracking subsystem exposes the current number of flow entries and a configured maximum; it also has protocol-specific timeout settings. Large numbers of idle flows can occupy resources alongside active traffic.

Shorter timeouts reclaim entries sooner but can disrupt applications that leave connections idle for long periods. Longer timeouts retain context for those applications while keeping entries around longer. The useful setting depends on actual traffic and the implementation's limits, so there is no universal timeout for every stateful firewall.

Routing also matters. If a request reaches one firewall and its reply reaches an independent firewall with no matching state, the second device may lack the context needed to permit the reply. A design must provide the required flow visibility or supported state sharing. A stateless filter does not need the earlier flow record, although its reverse-direction rules still have to allow the packet.

Neither label establishes a performance ranking for every product. Packet evaluation, rule volume, hardware, inspection features, and traffic patterns all influence throughput. Capacity planning should include both packet processing and the rate at which new tracked flows appear.

AWS Examples of the Distinction

Amazon VPC security groups demonstrate stateful return handling. Responses to traffic permitted by a security group are allowed regardless of the opposite-direction security group rules. Other controls on the route still apply, so that behavior does not guarantee end-to-end delivery.

VPC network ACLs demonstrate stateless handling at a subnet boundary. Their inbound and outbound rules must independently permit the exchange, including return traffic. AWS evaluates these rules by ascending rule number and uses the first match; that ordering belongs to network ACLs and should not be assumed for every firewall.

AWS Network Firewall combines both approaches. Its stateless engine can drop a packet, pass it to its destination, or forward it to the stateful engine. A stateless pass does not mean the packet will subsequently receive stateful inspection. For routed Network Firewall inspection, request and response traffic must use the same firewall endpoint.

Test New Connections, Replies, and Timeouts

Before applying a configuration, describe an allowed initiating flow and its reverse traffic using concrete addresses, protocol, and ports. Then describe an initiating flow that should be blocked. This separates permission to start communication from permission to return traffic within it.

In an authorized test environment, check both cases, along with a response that has no matching flow and an exchange resumed after the relevant idle timeout. Compare the expected decision with the observed rule match, tracking information where available, and application result. An allowed packet at one firewall is only one part of the path.