Packet Filtering Firewalls

A packet arrives at your network boundary. The firewall has microseconds to decide: let it through or drop it into the void.

Packet filtering makes this decision by looking at exactly five things: the source IP address, the destination IP address, the source port, the destination port, and the protocol. That's it. Five fields from the packet header, compared against a list of rules, producing a binary outcome.

This simplicity is the point. A packet filter doesn't read the letter—it only checks the envelope.

What the Firewall Sees

When a packet arrives, the firewall extracts its header information. Imagine a packet heading for your web server:

• Source IP: 203.0.113.42 (some computer on the Internet)
• Destination IP: 198.51.100.10 (your web server)
• Source port: 49152 (ephemeral port chosen by the sender)
• Destination port: 443 (HTTPS)
• Protocol: TCP

The firewall checks this against its rules. A simple rule might say: "Allow TCP traffic to 198.51.100.10 on port 443 from any source." The packet matches. It passes.

Another packet arrives with destination port 22 (SSH). If no rule permits SSH from that source, the packet is dropped. The sender never knows why their connection failed—the packet simply vanishes.

This happens millions of times per second. Hardware packet filters running on specialized chips can inspect traffic at 100 Gbps without adding measurable latency. The decision is so fast because it's so limited: five fields, a rule lookup, done.

The Return Traffic Problem

Early packet filtering was stateless—each packet evaluated in isolation, with no memory of what came before.

This created an awkward problem. Say you want to allow users inside your network to browse the web. They send requests to port 80 on external servers. Simple enough: allow outbound TCP to port 80.

But the responses come back on ephemeral ports—high-numbered ports like 49152 that the operating system assigned for the connection. To allow these responses, you'd need to permit inbound traffic on ports 49152-65535. From anywhere.

You've just opened 16,000 ports to the entire Internet. Any attacker can send traffic to those ports, and your firewall will let it through because it can't distinguish legitimate responses from unsolicited attacks.

Stateful packet filtering solved this by remembering connections. When an internal host initiates a connection to an external web server, the firewall records it. When the response arrives—even on an ephemeral port—the firewall recognizes it as part of an established connection and allows it through.

Today, virtually all packet filtering is stateful. The term "packet filtering firewall" implies connection tracking unless explicitly stated otherwise. But understanding the stateless era reveals why connection state matters so much.

What Packet Filtering Cannot See

A packet filter examines only headers. It never looks inside the packet's payload.

This creates a fundamental blind spot. If your rule allows TCP traffic on port 443, the firewall permits anything using that port—HTTPS traffic, yes, but also any other application a user decides to tunnel through port 443.

An employee running BitTorrent over port 443? The packet filter sees allowed traffic to an allowed port. A SQL injection attack embedded in an HTTP request? The malicious payload sits in the packet body, invisible to header inspection. Malware communicating with command servers over HTTPS? Perfectly legitimate-looking packets.

Packet filtering tells you what port traffic is using. It cannot tell you what the traffic actually is.

This limitation extends to complex protocols. FTP, for instance, negotiates data transfer ports dynamically during the session. A client connects to port 21, then the server tells it to connect to port 37429 for the actual file transfer. Static packet filtering rules can't anticipate these dynamic ports—you'd need to either open wide port ranges or use application-aware inspection that understands FTP's port negotiation.

Where Packet Filtering Lives

Packet filtering happens at boundaries—anywhere two networks meet.

Routers include packet filtering through Access Control Lists (ACLs). These provide basic firewall functionality without dedicated hardware, often serving as the first line of defense at network edges.

Operating systems provide host-based packet filtering. Linux has iptables and nftables. BSD has pf. Windows has Windows Firewall. These protect individual machines regardless of what network they connect to.

Cloud platforms implement packet filtering through security groups—rules that define which ports and protocols can reach virtual machines. When you configure an AWS security group or Azure NSG, you're writing packet filtering rules.

Dedicated firewall appliances use packet filtering as their foundation, then layer additional inspection on top.

Writing Effective Rules

Packet filtering rules are processed in order. The first matching rule determines the packet's fate. This makes rule ordering critical.

Place specific rules before general ones. If you want to block a particular IP address but allow all other traffic to a service, the block rule must come first. Otherwise, the general allow rule matches and the block never applies.

Apply least privilege. If a service only needs to accept connections from your office network, specify that source range—don't allow from everywhere because it's easier to configure.

Document why rules exist. The rule "allow TCP 10.0.0.0/8 to 192.168.1.50:22" means nothing six months from now without context. A comment explaining "SSH access for ops team from internal network" makes the rule auditable.

Remove rules when they're no longer needed. Decommissioned servers, old IP ranges, temporary exceptions that became permanent—these accumulate into configuration debt that obscures what your firewall actually does.

The Foundation Layer

Modern firewalls—next-generation firewalls, application-aware firewalls, unified threat management systems—all perform packet filtering. It's the first stage of inspection, the fast check before deeper analysis.

This layered approach makes sense. Packet filtering is cheap. Checking five header fields against a rule table takes nanoseconds. Deep packet inspection, application identification, malware scanning—these are expensive. Why waste resources inspecting traffic that should never have been allowed in the first place?

So edge routers drop obviously unwanted traffic with ACLs. Stateful firewalls handle connection tracking and basic filtering. Application-layer inspection examines only the traffic that passes these earlier stages.

Packet filtering isn't sophisticated enough to be your only defense. But it's fast enough to be your first one.