iptables & nftables — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about iptables and nftables.
iptables replaced ipchains in the Linux 2.4 kernel (2001)¶
Before iptables, Linux used ipchains (kernel 2.2, 1999) and before that, ipfwadm (kernel 2.0, 1996). Each generation brought a more flexible packet filtering architecture. iptables introduced the concept of tables (filter, nat, mangle, raw) and the Netfilter framework that persists in modified form today.
iptables rules are evaluated linearly — order matters enormously¶
Every packet traverses rules in order until a match is found. A chain with 10,000 rules checks every rule sequentially for each packet. This O(N) behavior means that rule ordering is critical for performance: putting the most frequently matched rules first can reduce CPU usage by orders of magnitude on busy firewalls.
nftables was designed by the same team that built iptables¶
Pablo Neira Ayuso, the lead Netfilter maintainer, led the nftables development starting around 2009. It was merged into the Linux kernel in version 3.13 (January 2014). The team built nftables specifically to address iptables' limitations: linear rule evaluation, code duplication across ip/ip6/arp/bridge tools, and a rigid kernel ABI.
nftables uses a virtual machine in the kernel for packet matching¶
Unlike iptables' hardcoded match/target modules, nftables compiles rules into bytecode that runs on a small virtual machine inside the kernel (nf_tables). This design allows new match types without kernel module changes and enables the kernel to optimize rule evaluation with sets, maps, and concatenated lookups.
Docker injects its own iptables rules and can silently bypass your firewall¶
Docker adds FORWARD chain rules and its own DOCKER chain to iptables, routing container traffic through NAT. These rules are inserted with higher priority than user rules. Many administrators have been surprised to find that containers are accessible from the internet despite restrictive firewall rules because Docker's rules take precedence.
The CONNTRACK table is the unsung hero of stateful firewalling¶
Connection tracking (conntrack) maintains a table of all active network connections. This is what makes "stateful" firewalling possible — allowing return traffic for established connections. The default conntrack table size is 65,536 entries on most distributions. Exhausting it (common on busy NAT gateways) silently drops new connections with no obvious error message.
iptables-nft is the compatibility layer bridging both worlds¶
Starting with Debian 10 (2019) and RHEL 8 (2019), the iptables command is actually iptables-nft — a translation layer that accepts iptables syntax but creates nftables rules under the hood. This means many administrators are already running nftables without knowing it. The iptables-legacy command accesses the old iptables kernel API directly.
A single misconfigured iptables rule can lock you out of a remote server permanently¶
Running iptables -P INPUT DROP without first allowing SSH traffic will immediately sever your connection to a remote server. Unlike most configuration mistakes, there is no SSH session to recover from — you need console access. This is why experienced administrators always set a cron job to flush rules (iptables -F && iptables -P INPUT ACCEPT) before testing new rulesets.
nftables sets and maps replace dozens of iptables rules with a single lookup¶
nftables introduced native set support, allowing rules like "match any of these 10,000 IP addresses" with O(1) hash lookup instead of 10,000 sequential iptables rules. Named sets can be updated atomically at runtime without reloading the entire ruleset, a feature that iptables' ipset extension partially addressed but never as cleanly.
Kubernetes uses iptables for service routing — and it does not scale well¶
kube-proxy's iptables mode creates roughly 5 rules per Service endpoint. A cluster with 10,000 Services and 100,000 endpoints generates over 500,000 iptables rules. Rule insertion alone takes seconds, and each packet must traverse the probability-weighted chains. This scaling problem drove the development of kube-proxy's IPVS mode and projects like Cilium that replace iptables entirely with eBPF.