Firewall Architecture: Packet Filtering vs Stateful Firewalls

Firewall architecture determines how a system decides whether network traffic may cross a boundary. The two foundational models are stateless packet filtering, which evaluates each packet independently, and stateful inspection, which also considers the connection that produced the packet. This guide explains the difference for developers, network administrators, and home-lab operators, then shows how to design, test, and troubleshoot a small default-deny policy without confusing filtering with authentication or application security.

What Is Firewall Architecture?

A firewall is a policy enforcement point between network interfaces, hosts, applications, or trust zones. It receives traffic, evaluates facts about that traffic against ordered rules, and produces a verdict such as allow, drop, reject, or translate. The facts may include source and destination addresses, protocol, ports, interface, direction, identity, and connection state.

The Netfilter project provides the packet-filtering framework used by the Linux kernel. User-space tools such as nftables configure rules that are evaluated by that framework. On other platforms, the implementation may be a router ACL, a host firewall, a cloud security group, or a dedicated appliance, but the policy problem is similar: decide which flows are allowed while keeping the decision understandable and observable.

Two terms describe the most important architectural distinction:

• Packet filtering evaluates each packet using fields visible in that packet. It does not remember whether an earlier packet created a legitimate conversation.
• Stateful inspection maintains connection-tracking state and uses it when evaluating later packets. A reply can be allowed because it belongs to an approved outbound connection, even when the reply arrives from an otherwise restricted direction.

Neither model automatically understands user intent, validates an application payload, or replaces identity and authorization controls. A stateful firewall can know that a TCP connection is established without knowing whether the authenticated user is allowed to read a particular record.

The Problem Firewalls Solve

Every networked service creates possible paths between systems. Without a policy boundary, any reachable host may probe ports, send malformed traffic, or connect to services that were intended for a smaller group. A firewall reduces this attack surface by making permitted communication explicit.

The challenge is that traffic is bidirectional and protocols are often more complex than a single request packet. A browser sends an outbound TCP connection request, receives packets from the server, and may open additional connections for related services. A DNS resolver sends a query and receives a response from a changing source port. A stateless rule set must describe both directions and account for return traffic manually.

The NIST firewall guidance frames firewalls as part of a broader security architecture rather than a single perimeter product. Filtering is useful only when its policy matches the system’s trust boundaries, logging is actionable, and administrators can test changes safely. A firewall that silently blocks required traffic can be as operationally damaging as one that permits too much.

How Packet Filtering Works

A stateless packet filter inspects each packet in isolation. A rule might say:

This model is predictable and inexpensive. Routers can apply simple access control lists at high speed, and the result is easy to reason about when protocols are simple. Filtering can also be placed at several points: an edge router, a host, a container bridge, or a cloud subnet boundary.

The limitation is that the filter sees packets rather than conversations. If a client sends a request from source port 49152 to a server at destination port 443, the response normally travels from source port 443 to destination port 49152. A stateless policy must explicitly permit that reverse traffic based on address and port ranges. Broad return rules may unintentionally allow unsolicited traffic, while narrow rules can break legitimate clients whenever ephemeral-port behavior changes.

Stateless filtering also cannot reliably infer protocol correctness from transport headers alone. A packet addressed to TCP port 443 is not necessarily valid HTTPS, and a packet with a familiar source port is not automatically a legitimate reply. These limits do not make packet filters obsolete; they define the boundary of what the architecture can know.

How Stateful Inspection Works

A stateful firewall adds a connection-tracking table. When an allowed packet creates a flow, the firewall records attributes such as the protocol, addresses, ports, direction, and lifecycle state. Later packets are compared with that record before ordinary policy rules are evaluated.

For TCP, typical states include:

• NEW: traffic attempting to create a connection.
• ESTABLISHED: traffic associated with a connection that completed the expected handshake.
• RELATED: traffic associated with an existing connection through a protocol-aware helper or tracked relationship.
• INVALID: traffic that does not fit a known or valid tracked flow.

The exact names and transitions vary by platform. The nftables packet-header documentation is useful for understanding what a Linux rule can match, while state tracking is commonly exposed through conntrack expressions. The key principle is that state is evidence about packet sequence and flow identity, not proof that an application or user is trustworthy.

A common stateful policy is:

1. Accept loopback traffic.
2. Accept packets belonging to established or related connections.
3. Allow narrowly defined new inbound connections.
4. Allow or restrict new outbound connections according to the environment.
5. Drop or reject everything else.

This is simpler than duplicating reverse-direction rules for every permitted service. It is not risk-free: a compromised host can create a new outbound connection that the policy allows, and an overloaded connection-tracking table can cause drops or resource pressure. Stateful inspection therefore needs capacity monitoring, sensible timeouts, and an explicit policy for unsolicited traffic.

Packet Filtering vs Stateful Inspection

The choice is not always exclusive. A router may use stateless ACLs for coarse ingress filtering, then a stateful firewall may enforce host or zone policy. Cloud security groups are often stateful, while network ACLs may be stateless. Documenting which layer owns each decision prevents administrators from assuming that a permissive lower layer is compensated for by a control that does not actually inspect the same traffic.

Key Components of a Firewall

Rules, chains, and default policy

Rules are ordered tests with actions. A chain or rule group collects related rules for a direction, interface, or hook. The default policy is the result when no specific rule matches. A default-deny policy is easier to audit because new services do not become reachable merely by starting a listener, but it requires an inventory of legitimate traffic and a recovery path.

Rule order matters. Put narrow exceptions before broader rules, and make the reason for each exception discoverable through names, comments, or change records. Avoid rules that depend on temporary addresses without an owner and expiry plan.

Connection tracking

Connection tracking supplies stateful decisions. It must handle TCP, UDP, and protocols with different lifetimes. UDP has no handshake, so the firewall uses timed tuples and observed traffic rather than a durable session. NAT often shares this state because address and port translations must remain consistent in both directions.

Zones and interfaces

A firewall policy should describe trust zones, not only device names. External, management, server, client, guest, and IoT interfaces may have different defaults. VLAN segmentation creates separate Layer 2 domains, but the firewall still has to control routed traffic between them.

Logging and counters

Logs explain why a packet was denied, while counters show whether a rule is active. Log only useful events and rate-limit noisy drops. A rule with zero matches may be obsolete, incorrectly placed, or simply untested. Treat logging as an operational signal rather than proof that every attack will be recorded.

Practical Guide: Build and Test a Small Stateful Policy

The following nftables example shows the architecture rather than a universal production ruleset. Test from console access or a separate recovery path before applying a default-drop policy to a remote server. The advanced iptables and nftables guide covers persistence, NAT, sets, and compatibility details.

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;

    iifname "lo" accept
    ct state established,related accept
    ct state invalid drop

    # Allow ICMP for diagnostics; narrow this by zone if required.
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept

    # Permit SSH only from the management subnet.
    ip saddr 192.0.2.0/24 tcp dport 22 ct state new accept

    # Permit a public HTTPS service.
    tcp dport 443 ct state new accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
  }

  chain output {
    type filter hook output priority filter; policy accept;
  }
}

Before loading a ruleset, inspect it for syntax errors:

sudo nft -c -f firewall.nft
sudo nft -f firewall.nft
sudo nft list ruleset
sudo nft list ruleset -a

Test both allowed and denied paths. From an authorized management host, verify SSH. From a non-management host, verify that the same port is not reachable. Test the public service from an appropriate external network, then inspect counters and logs. A successful TCP connection proves reachability, not that the application is secure.

For a stateless ACL, write the reverse-direction policy explicitly and test it with the same care. For either model, include IPv6 in the design; filtering IPv4 while leaving IPv6 unmanaged creates a policy gap. Also review forwarding, NAT, container runtime rules, and host-level firewalls together. Docker and Kubernetes may install their own paths and rules, so container networking should be treated as part of the traffic map rather than a separate concern.

Common Misconceptions

“Stateful means secure by default”

State tracking improves flow handling, but it does not decide whether a newly initiated connection should be trusted. An attacker using a permitted outbound path can still reach an external service. Least privilege, egress controls, endpoint hardening, and application authentication remain necessary.

“A firewall blocks attacks inside allowed traffic”

Basic packet filters generally do not inspect application meaning. If HTTPS is allowed, the firewall may permit encrypted malicious requests because it cannot read their payload. Web application firewalls, endpoint controls, and service authorization address different layers.

“VLANs are firewalls”

VLANs separate broadcast domains. They do not automatically enforce who may communicate after routing occurs. Inter-VLAN access needs an ACL or firewall policy, and the policy should be tested from each relevant zone.

Related Articles

• Network Security Architecture: A Beginner’s Guide
• Advanced Networking with iptables and nftables
• Home Lab Network Segmentation with VLANs
• Container Networking Explained
• Windows Firewall Advanced Security Rules

This article was last reviewed on September 22. Firewall policies should be revisited whenever services, interfaces, routing, or trust boundaries change.