nftables is the Linux kernel’s packet classification framework and its user-space tool nft, used to define firewall filtering, network address translation and packet mangling rules. In Linux networking, it is the successor to iptables, ip6tables, arptables and ebtables, and it unifies them in one syntax and one kernel subsystem.
nftables has been part of the kernel since version 3.13 and is the default firewall backend on current Debian, Ubuntu, Fedora and Red Hat Enterprise Linux releases. Higher-level tools such as firewalld and UFW can generate nftables rules, so many systems use it even when administrators never type an nft command.
How nftables processes packets
nftables builds on the Netfilter hooks inside the kernel network stack. A packet passes hooks such as prerouting, input, forward, output and postrouting, and at each hook the kernel runs any base chain registered there. Each chain contains rules that are evaluated in order until a verdict is reached.
The key design change compared with iptables is a small virtual machine in the kernel. The nft tool compiles rules into bytecode, and the kernel executes that bytecode. New matches therefore do not require new kernel modules for every protocol field, which keeps the kernel side simpler and more generic.
Rules are organized in a clear hierarchy. The table explains each level of the nftables object model.
| Object | Role | Example |
|---|---|---|
| Table | Container tied to an address family | table inet filter |
| Base chain | Chain attached to a hook with a priority and policy | type filter hook input priority 0; policy drop |
| Regular chain | Jump target for rule organization | chain ssh_rules |
| Rule | Match expressions plus a verdict | tcp dport 22 accept |
| Set or map | Named collection used in lookups | set blocked { type ipv4_addr; } |
Changes are applied as atomic transactions. Loading a whole rule file with nft -f replaces the ruleset in one step, so there is never a moment when half of the new rules are active, which was a known risk with sequential iptables commands.
Address families, chain types and hooks
Each table belongs to an address family, which decides what kind of traffic it sees. The inet family is the most practical choice for host firewalls because one table covers both IPv4 and IPv6.
| Family | Traffic covered | Typical use |
|---|---|---|
| ip | IPv4 only | Legacy-style IPv4 rules |
| ip6 | IPv6 only | IPv6-specific policies |
| inet | IPv4 and IPv6 | Host and gateway firewalls |
| arp | ARP frames | ARP filtering |
| bridge | Frames crossing a Linux bridge | Filtering between bridged ports |
| netdev | Ingress and egress on one device | Early filtering and DDoS mitigation |
Base chains also have a type: filter for accepting or dropping packets, nat for address translation and route for rerouting locally generated traffic. The priority value orders chains on the same hook; lower numbers run first, and standard names such as filter (0) and dstnat (-100) make the order readable.
Sets, maps and stateful rules
Sets and maps are the feature that most improves on iptables. A set lookup uses hash or interval data structures, so matching one address against ten thousand entries costs roughly the same as matching against ten. In iptables, a list of ten thousand addresses meant ten thousand rules evaluated one after another.
Verdict maps go further by mapping a key directly to an action, for example sending each destination port to its own chain. Sets can have timeouts and dynamic updates, which allows rules such as adding an address that exceeds a connection rate to a temporary block list.
Stateful filtering relies on connection tracking. The common rule ct state established,related accept early in the input chain lets reply traffic through, while ct state invalid drop discards malformed packets. Counters, limits and quotas can be attached to rules to measure or rate-limit traffic.
nftables compared with iptables and UFW
nftables, iptables and UFW are often discussed together, but they work at different levels of the firewall stack. The table clarifies how they relate.
| Tool | Level | Rule model | Current status |
|---|---|---|---|
| nftables | Kernel framework and nft tool | Tables, chains, sets, bytecode | Default backend |
| iptables-legacy | Kernel x_tables and tool | Fixed tables, linear rules | Maintained for compatibility |
| iptables-nft | iptables syntax on nftables | Translated into nftables objects | Common transition layer |
| UFW | Front end | Simple allow and deny commands | Generates rules for the backend |
| firewalld | Front end with zones | Zones and services | Uses nftables by default |
The tool iptables-translate converts single iptables rules into nftables syntax, and iptables-restore-translate converts saved rule files. Mixing legacy iptables rules and native nftables rules on one host is possible but confusing, because both are evaluated and either can drop a packet.
Practical configuration and common mistakes
Most distributions load the persistent ruleset from /etc/nftables.conf through the nftables.service unit. A safe workflow is to edit the file, test it with nft -c -f /etc/nftables.conf, and only then apply it.
| Mistake | Consequence | Prevention |
|---|---|---|
| Policy drop before allowing SSH | Remote administrator locked out | Test with a timed rollback or console access |
| No established,related rule | Replies to outgoing traffic blocked | Accept established traffic first |
| Forgetting flush ruleset | Old and new rules merged | Begin the file with flush ruleset |
| Separate ip and ip6 tables | IPv6 left unfiltered | Use the inet family |
| Docker and nftables conflicts | Container traffic bypasses rules | Review rules created by the runtime |
nft list ruleset shows the complete active configuration, and nft monitor streams rule changes and traced packets. Enabling meta nftrace set 1 on selected traffic is the most precise way to see which rule produced a verdict.
Explained without jargon
A computer connected to a network receives a constant stream of small data packages. nftables is the gatekeeper that inspects each package. It decides whether to let it in, send it elsewhere or throw it away.
The gatekeeper follows a written rule book. A good rule book is short and clear. nftables lets administrators keep long lists, such as thousands of blocked addresses, in one quick lookup table instead of thousands of separate rules.
A typical use case
A small hosting provider runs a public web server that must accept HTTP, HTTPS and SSH, while dropping everything else and blocking addresses that repeatedly attack the login service.
The administrator writes one inet table with an input chain whose policy is drop. It accepts established and related traffic, loopback traffic, ports 80 and 443, and SSH only from the office network. A dynamic set named attackers with a one-hour timeout collects addresses that open more than ten SSH connections per minute.
The file is checked with nft -c, applied atomically, and enabled through nftables.service. The result is one readable ruleset for IPv4 and IPv6, and the block list grows and shrinks automatically without manual cleanup.