The packet filter firewall represents the genesis of network firewall technology—the original mechanism that transformed routers from simple traffic forwarders into security enforcement points. Despite being the oldest firewall technology, packet filtering remains the foundational layer upon which all modern firewall technologies are built, and pure packet filters continue to provide high-performance filtering at network choke points where more sophisticated inspection would create unacceptable latency.

To understand packet filtering, imagine a border checkpoint where guards examine only the exterior of vehicles—checking license plates (IP addresses), noting the driver's stated destination (destination port), and verifying the vehicle type (protocol)—without ever opening the cargo. This surface-level inspection enables rapid processing of thousands of vehicles per hour, but it cannot detect contraband hidden within.

Packet filters operate on the same principle: they examine the metadata of network traffic—the headers that describe where packets came from, where they're going, and what protocol they carry—while remaining completely blind to the content those packets contain. This design produces firewalls that are extraordinarily fast but limited in their ability to detect sophisticated threats.

Where Packet Filters Operate

Packet filter firewalls operate at OSI Layers 3 (Network) and 4 (Transport). This positioning gives them access to:

Layer 3 (Network Layer) Fields:

• Source IP address
• Destination IP address
• IP protocol number (TCP, UDP, ICMP, etc.)
• IP header options and flags
• Fragment identification and offset

Layer 4 (Transport Layer) Fields:

• Source port number
• Destination port number
• TCP flags (SYN, ACK, FIN, RST, PSH, URG)
• TCP sequence and acknowledgment numbers (rarely used for filtering)

What Packet Filters Cannot See:

• Application layer data (HTTP requests, email content, file transfers)
• Encrypted payload content
• Higher-layer protocol violations
• User identity or application context

Stateless vs. Stateful Architecture

Pure packet filters are stateless—each packet is evaluated independently without knowledge of previous packets or ongoing connections. The firewall has no memory of traffic that has already passed.

This stateless nature has profound implications:

Implementation Locations

Packet filters are implemented in several locations throughout network infrastructure:

1. Router Access Control Lists (ACLs) Most routers include packet filtering capabilities in the form of ACLs. Every packet traversing the router can be evaluated against ACL rules.

2. Operating System Network Stacks All major operating systems include packet filtering:

• Linux: iptables, nftables (netfilter framework)
• BSD/macOS: pf (Packet Filter), ipfw
• Windows: Windows Filtering Platform (WFP), Windows Firewall

3. Dedicated Firewall Appliances While modern appliances offer stateful and deep packet inspection, they often include high-speed packet filtering as a first-pass optimization layer.

4. Network Interface Cards (NICs) Some high-performance NICs include hardware packet filtering capabilities, offloading simple filter rules from the CPU.

Understanding exactly which fields are available for filtering is essential for constructing effective packet filter rules. Let's examine each criterion in depth.

IP Address Filtering

IP addresses can be filtered as individual hosts or network ranges using CIDR notation:

Individual Host:

192.168.1.100       # Single IPv4 host
2001:db8::1         # Single IPv6 host

Network Ranges (CIDR):

192.168.0.0/16      # 65,536 addresses (192.168.0.0 - 192.168.255.255)
10.0.0.0/8          # 16,777,216 addresses (entire 10.x.x.x space)
2001:db8::/32       # IPv6 /32 allocation

Special Addresses:

0.0.0.0/0           # Any IPv4 address (wildcard)
::/0                # Any IPv6 address (wildcard)

Source vs. Destination:

• Source IP: The address originating the traffic (who is sending)
• Destination IP: The address receiving the traffic (who is receiving)

Filtering by IP address is fundamental but has significant limitations. IP addresses can be spoofed, are often dynamically assigned, and don't inherently indicate user identity or intent.

Port Number Filtering

Port numbers identify specific services or applications. They range from 0 to 65,535 and are categorized as:

Well-Known Ports (0-1023): Reserved for privileged system services. On Unix-like systems, binding to these ports typically requires root privileges.

Registered Ports (1024-49151): Assigned to specific applications by IANA but not privileged.

Dynamic/Private Ports (49152-65535): Used for ephemeral client connections and internal applications.

TCP Flag Filtering

TCP flags control connection establishment, data transfer, and termination. Understanding flags enables sophisticated filtering:

SYN (Synchronize):

• Present in the first packet of a TCP handshake
• SYN-only packets indicate new connection attempts
• Filtering inbound SYN packets blocks incoming connections

ACK (Acknowledge):

• Present in all packets after the initial SYN (including SYN-ACK)
• Packets with ACK but without SYN indicate established connections
• The "established" trick: Permit inbound packets only if ACK is set

FIN (Finish):

• Indicates graceful connection termination
• Should only appear in established connections

RST (Reset):

• Forcibly terminates a connection
• Generated when packets arrive for non-existent connections

PSH (Push):

• Requests immediate delivery to application layer
• Normal in interactive applications (SSH, Telnet)

URG (Urgent):

• Indicates urgent data in the packet
• Rarely used legitimately; sometimes abused for covert channels

Understanding rule syntax requires familiarity with how different systems express packet filter rules. Let's examine the most common formats and their practical application.

Universal Rule Components

Every packet filter rule contains these elements:

1. Action: What to do if the packet matches (PERMIT/ALLOW, DENY/DROP, REJECT)
2. Direction: Inbound, outbound, or both
3. Protocol: IP, TCP, UDP, ICMP, etc.
4. Source: Source IP address or network
5. Source Port: Source port or range (TCP/UDP only)
6. Destination: Destination IP address or network
7. Destination Port: Destination port or range (TCP/UDP only)
8. Additional Criteria: TCP flags, ICMP types, etc.

Understanding how packet filters process rules is critical for both correctness and performance. Misunderstanding rule order is one of the most common causes of firewall misconfigurations.

First Match Wins

Packet filter rules are evaluated sequentially from top to bottom. When a packet matches a rule, the specified action is taken immediately, and no further rules are evaluated.

Consider this rule set:

Rule 1: DENY traffic from 10.0.0.100 to any
Rule 2: PERMIT traffic from 10.0.0.0/24 to any
Rule 3: DENY all traffic

Packet from 10.0.0.100:

• Matches Rule 1 → DENIED
• Rules 2 and 3 never evaluated

Packet from 10.0.0.50:

• Doesn't match Rule 1
• Matches Rule 2 → PERMITTED
• Rule 3 never evaluated

Packet from 172.16.0.1:

• Doesn't match Rule 1 or Rule 2
• Matches Rule 3 → DENIED

Performance Optimization

In high-throughput environments, packet filter performance becomes critical. Every rule evaluated adds processing latency.

Optimization Strategies:

1. Place High-Volume Rules First Rules that match most traffic should be evaluated early. If 80% of your traffic is HTTP/HTTPS, placing those permit rules early reduces average evaluation depth.

2. Combine Rules Where Possible Instead of:

PERMIT any to 192.168.1.10 port 80
PERMIT any to 192.168.1.10 port 443
PERMIT any to 192.168.1.10 port 8080

Use port ranges or groups:

PERMIT any to 192.168.1.10 port 80,443,8080

3. Use Hardware Acceleration Many routers and firewalls can offload simple packet filter rules to hardware ASICs, achieving line-rate performance. Complex rules may fall back to software processing.

4. Remove Unused Rules Periodically audit rule hit counters. Rules with zero hits may indicate:

• Obsolete rules for decommissioned systems
• Rules shadowed by earlier rules (never reached)
• Misconfigurations

5. Use Object Groups Modern systems support grouping objects (IP addresses, ports) into named sets. This improves both manageability and performance:

object-group network WEB_SERVERS
  host 192.168.1.10
  host 192.168.1.11
  host 192.168.1.12

object-group service WEB_PORTS
  tcp eq 80
  tcp eq 443
  tcp eq 8080

permit tcp any object-group WEB_SERVERS object-group WEB_PORTS

Let's examine specific scenarios where packet filters are commonly deployed and the rule patterns that address each use case.

Use Case 1: Internet Edge Filtering (Anti-Spoofing)

At the internet edge, fundamental anti-spoofing rules prevent attackers from sending packets with forged source addresses:

Block RFC 1918 Private Addresses Inbound:

DENY from 10.0.0.0/8 inbound
DENY from 172.16.0.0/12 inbound
DENY from 192.168.0.0/16 inbound

Block Your Own Addresses Inbound:

DENY from <your_public_ip_range> inbound on external interface

Block Bogon Addresses: Reserved, unallocated, or documentation-only address ranges shouldn't appear on the public internet.

Use Case 2: Service Restriction

Limit access to specific services based on source network:

SSH Access Restricted to Admin Network:

PERMIT tcp from 10.0.0.0/24 to any port 22
DENY tcp from any to any port 22

Database Access Restricted to Application Servers:

PERMIT tcp from 192.168.1.0/24 to 192.168.2.100 port 3306
PERMIT tcp from 192.168.1.0/24 to 192.168.2.100 port 5432
DENY tcp from any to 192.168.2.0/24 port 3306
DENY tcp from any to 192.168.2.0/24 port 5432

Use Case 3: Protocol Restriction

Block known-dangerous protocols at the perimeter:

Block Telnet, FTP, and Unencrypted Protocols:

DENY tcp from any to any port 21    ! FTP
DENY tcp from any to any port 23    ! Telnet
DENY tcp from any to any port 110   ! POP3 (unencrypted)
DENY tcp from any to any port 143   ! IMAP (unencrypted)

Block SMB and RPC (Wormable Protocols):

DENY tcp from any to any port 135   ! RPC
DENY tcp from any to any port 137-139 ! NetBIOS
DENY tcp from any to any port 445   ! SMB

Use Case 4: Rate Limiting (When Supported)

Some packet filter implementations support basic rate limiting:

ICMP Rate Limiting:

PERMIT icmp echo-request from any, limit 1 per second
DENY icmp echo-request from any

This permits ping but prevents ICMP-based denial-of-service attacks.

Use Case 5: Explicit Logging for Security Monitoring

Log All Denied Traffic:

DENY and LOG all traffic not matched by previous rules

Log Access to Sensitive Systems:

PERMIT and LOG tcp from any to database-servers port 3306

Logging is essential for:

• Security monitoring and alerting
• Forensic investigation after incidents
• Rule validation and troubleshooting
• Compliance auditing

Understanding packet filter limitations is as important as knowing their capabilities. These limitations drove the development of more sophisticated firewall technologies.

Fundamental Limitations

1. No Connection Awareness Stateless packet filters don't understand connection state. This creates several problems:

• Return traffic rules: You must explicitly permit response traffic, either through blanket rules or the "established" ACK flag trick.
• Probe attacks: Attackers can send ACK packets to scan internal hosts (they won't be blocked by "deny all inbound except established").
• Dynamic protocols: Protocols like FTP that negotiate data ports dynamically cannot be properly supported.

2. No Content Inspection Packet filters cannot detect:

• Malware in transferred files
• SQL injection in database queries
• Command injection in HTTP requests
• Phishing content in emails
• Data exfiltration disguised as legitimate traffic

3. Port-Based Filtering Is Easily Evaded Attackers routinely tunnel through permitted ports:

• Malware using port 80 (HTTP) or 443 (HTTPS)
• SSH over arbitrary ports
• DNS tunneling for data exfiltration
• HTTP CONNECT proxies through port 443

4. IP Spoofing Vulnerability While egress filtering helps, inbound traffic may contain spoofed source addresses (particularly UDP traffic where no handshake validates the source).

The Fragmentation Problem in Detail

IP fragmentation creates particular challenges for packet filters. When a packet exceeds the MTU (Maximum Transmission Unit) of a network link, it is divided into fragments.

The Problem:

• Only the first fragment contains the transport layer header (ports, TCP flags)
• Subsequent fragments contain only the IP header (no port information)
• Packet filters cannot make port-based decisions on fragments

Attack Scenario: An attacker could:

1. Fragment packets so port 445 (SMB) is in fragment 1
2. Send fragment 2 first (no port info—permitted)
3. Send fragment 1 with a spoofed, high-numbered port (might be permitted)
4. Victim reassembles fragments, revealing actual malicious port 445 connection

Mitigations:

• Block all fragments: Effective but may break legitimate large packets
• Reassemble before filtering: Computationally expensive, may create DoS vulnerability
• Virtual reassembly: Track fragment state and validate consistency

Modern firewalls typically implement fragment tracking, but pure packet filters remain vulnerable.

IPv6 introduces several considerations that packet filter administrators must understand. Simply translating IPv4 rules to IPv6 syntax is insufficient.

IPv6-Specific Protocols

ICMPv6: Unlike IPv4 where ICMP can often be blocked wholesale, ICMPv6 is essential for IPv6 operation:

Blocking all ICMPv6 will break IPv6 connectivity.

Extension Header Complexity

IPv6 uses extension headers for options that IPv4 placed in the IP header. These create filtering challenges:

• Hop-by-Hop Options: Processed by every router on the path
• Routing Header: Specifies intermediate destinations (security concern)
• Fragment Header: Contains fragmentation information
• Destination Options: Processed by destination node only

Security Concerns:

• Type 0 Routing Header (deprecated) enabled source routing attacks
• Excessive or malformed extension headers can evade filtering
• Extension headers can push transport headers beyond typical inspection depth

IPv6 Address Format Changes

IPv6 addresses are 128 bits (vs IPv4's 32 bits), using hexadecimal notation:

IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
Shortened: 2001:db8:85a3::8a2e:370:7334

Common prefixes:
::/128        # Unspecified address
::1/128       # Loopback
fe80::/10     # Link-local
fc00::/7      # Unique local (similar to RFC 1918)
2000::/3      # Global unicast

Dual-Stack Considerations

Most networks run IPv4 and IPv6 simultaneously (dual-stack). This creates security complexity:

• Separate rule sets required for IPv4 and IPv6
• IPv6 tunnels (6to4, Teredo) can bypass IPv4-only firewalls
• Attack surface doubles when both protocols are enabled
• Monitoring must cover both address families

This page has provided comprehensive coverage of packet filter firewalls—the foundational technology upon which all modern firewall systems build. Let's consolidate the essential knowledge:

What's Next:

The limitations of packet filters—particularly the lack of connection state awareness—led directly to the development of stateful firewalls. In the next page, we'll explore how stateful inspection addresses these limitations by maintaining connection state tables and evaluating packets in the context of their associated connections.