iptables vs nftables: The Firewall Reckoning

The Linux firewall landscape has quietly crossed a tipping point. nftables is now the default on every major distribution released after 2019 — yet millions of production servers still run iptables. Understanding why, and knowing when to switch, is no longer optional knowledge.

A Tale of Two Frameworks

iptables arrived in 1998 as a rewrite of ipchains, itself a successor to ipfwadm. For over two decades it served as the standard interface to the Linux kernel’s Netfilter packet-filtering subsystem — a silent gatekeeper trusted by millions of servers, routers, and firewalls worldwide.

nftables was first presented at the Netfilter Workshop 2008 and merged into the mainline kernel with version 3.13 in January 2014. Developed by the same Netfilter project team, it was designed not merely to patch iptables’ shortcomings but to replace its entire architecture — tools, syntax, data model, and kernel integration included.

Where Things Stand in 2026

The market has voted. nftables is the default kernel firewall backend on every major Linux distribution released after 2019 — including RHEL/CentOS 8+, Debian 10+, Ubuntu 20.04+, Fedora 32+, and now Arch Linux. The holdouts are almost exclusively legacy systems.

Architectural Differences

Tool Fragmentation vs. Unified Interface

iptables manages different protocol layers through separate binaries: iptables for IPv4, ip6tables for IPv6, arptables for ARP, and ebtables for bridge traffic. Each tool carries its own rule format and state. In large environments, keeping them consistent is a genuine operational burden.

nftables replaces all four with a single command: nft. One tool, one ruleset format, one man page to remember. The inet address family allows a single table to govern both IPv4 and IPv6 traffic simultaneously — critical in dual-stack environments.

Rule Storage and the Kernel Bytecode VM

iptables rules are compiled into a flat binary blob that gets loaded atomically into the kernel. Reading rules back requires kernel round-trips. The architecture offers no scripting primitives — logic, variables, and computed expressions are all userspace concerns.

nftables takes a different approach: the nft tool compiles rules into bytecode for a small, purpose-built virtual machine running inside the kernel. This enables nftables to support native data structures — sets, maps, dictionaries, and concatenations — that can be evaluated directly in-kernel without external tools like ipset.

Atomic Updates

Updating iptables rules is not atomic by default. A script that flushes then re-applies rules creates a transient window during which packets may pass through unfiltered or be dropped unpredictably. Tools like iptables-restore mitigate but do not fully eliminate this risk.

nftables commits rule updates atomically: the new ruleset either takes full effect or the old one persists — no intermediate state. This is a meaningful operational safety improvement for systems where firewall continuity is critical.

Performance: The Honest Picture

Marketing claims around nftables performance — including widespread assertions of blanket “60% improvements” — deserve scrutiny. The reality is more nuanced.

The performance gains are genuine when you use nftables’ native data structures. Here is the actual difference:

The bottom line: migrating rules one-for-one without restructuring them into sets and maps will not yield meaningful performance gains. The architectural advantage must be leveraged deliberately.

Syntax Comparison

The readability gap between the two is real, and it compounds with rule complexity. Here are direct equivalents across common use cases:

// Allow HTTP from a specific IP

# iptables
iptables -A INPUT -s 192.168.1.100 -p tcp --dport 80 -j ACCEPT

# nftables
nft add rule ip filter input ip saddr 192.168.1.100 tcp dport 80 accept

// Multi-port rule

# iptables — requires -m multiport extension
iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT

# nftables — sets are native syntax
nft add rule ip filter input tcp dport { 22, 80, 443 } accept

// Connection state tracking

# iptables
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# nftables
nft add rule ip filter input ct state { established, related } accept

// Dynamic IP blocklist (named set)

# iptables — requires external ipset tool
ipset create blocklist hash:ip
ipset add blocklist 10.0.0.5
iptables -A INPUT -m set --match-set blocklist src -j DROP

# nftables — sets are first-class citizens
nft add set ip filter blocklist { type ipv4_addr\; }
nft add element ip filter blocklist { 10.0.0.5 }
nft add rule ip filter input ip saddr @blocklist drop

Side-by-Side Feature Matrix

Container Ecosystems: The Resolved Friction

One historically significant barrier to nftables adoption was container tooling. Docker historically injected iptables rules directly — a design that caused compatibility friction when distributions like Fedora 32 switched firewalld to the nftables backend. This was explicitly documented as a known issue by the Fedora Project.

By 2025, the ecosystem had largely adapted. Both Docker and Kubernetes tooling updated their Netfilter integration to handle nftables backends cleanly. Cloud-native infrastructure has since become one of the fastest drivers of nftables adoption, independent of distribution defaults. If this compatibility gap was your reason for staying on iptables, that reason has largely expired.

Decision Guide: Which Should You Use?

For teams caught in the middle, the iptables-nft compatibility layer provides a bridge: your existing iptables commands are transparently translated to nftables rules under the hood. This is explicitly a transitional tool, not a permanent solution — some edge-case behaviors differ from the legacy backend, and it should not be relied upon indefinitely.

Migration in Five Steps