iptables doesn't filter packets itself — it's a user-space tool that configures rules stored in the kernel. The actual packet interception happens at five hook points called Netfilter hooks, embedded in the kernel's networking code. Understanding these hooks explains why iptables chains have the names they do, and how everything from firewalls to Docker NAT works under the hood.
How does iptables know if a packet is "established" vs "new"?
Connection tracking (conntrack) runs at the PREROUTING hook and records every connection it sees in a table. When a packet arrives, conntrack looks it up: is this part of a known connection (ESTABLISHED), related to one (RELATED — like FTP data connections), or brand new (NEW)? This state lets iptables write rules like "allow ESTABLISHED" once instead of duplicating rules for every return packet.
# View current connection tracking table
cat /proc/net/nf_conntrack
# or:
conntrack -L
# Example output:
# tcp 6 86400 ESTABLISHED src=192.168.1.5 dst=1.2.3.4 sport=54321 dport=443
# src=1.2.3.4 dst=192.168.1.5 sport=443 dport=54321 [ASSURED]
# Conntrack table stats:
cat /proc/sys/net/netfilter/nf_conntrack_count # current entries
cat /proc/sys/net/netfilter/nf_conntrack_max # max entries (default: 65536)
# Increase conntrack table (for high-connection servers):
sysctl -w net.netfilter.nf_conntrack_max=524288
# IMPORTANT: when conntrack table is full, new connections are DROPPED
# Monitor: watch for "nf_conntrack: table full, dropping packet" in dmesg
Hook Priorities — Multiple Handlers on One Hook
Multiple subsystems can register handlers on the same hook point. They run in priority order (lower number = runs first):
PREROUTING hook, priority order:
-400 conntrack (raw table, connection tracking start)
-300 mangle (packet modification)
-200 DNAT / nat table
0 filter
POSTROUTING hook, priority order:
-300 mangle
100 SNAT / nat table (masquerade)
# This is why NAT happens AFTER conntrack:
# conntrack records original packet,
# NAT modifies it,
# conntrack tracks both original + translated addresses
XDP — Even Earlier Than Netfilter
Can you filter packets before Netfilter for maximum performance?
Yes — XDP (eXpress Data Path) runs eBPF programs directly in the NIC driver, before the sk_buff is even allocated. This means packets can be dropped or redirected before any of the normal kernel networking stack runs. XDP-based firewalls can process millions of packets per second with negligible CPU overhead — used by Cloudflare, Facebook, and others for DDoS mitigation.
Packet interception points (earliest to latest):
1. XDP (eBPF in NIC driver) ← before sk_buff, max performance
2. NF_INET_PRE_ROUTING (Netfilter) ← iptables PREROUTING
3. Routing decision
4. NF_INET_LOCAL_IN / FORWARD ← iptables INPUT/FORWARD
5. Socket layer
6. Application
# XDP actions:
# XDP_DROP — drop immediately, no sk_buff allocation
# XDP_PASS — continue normal processing
# XDP_TX — send back out same interface
# XDP_REDIRECT — redirect to another interface
# Used by: Cilium (Kubernetes networking), Cloudflare's DDoS protection,
# Facebook's Katran load balancer
Frequently Asked Questions
What will I learn here?
This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.
How should I use this page?
Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.
What should I read next?
Use the navigation below to continue to the next lesson or explore related topics.