nftables

nftables is the packet filtering framework in the Linux kernel, replacing iptables and its family. If you are configuring a firewall on a current distribution, this is what is underneath, even when the interface is firewalld or ufw.

What it fixed

iptables had accumulated four separate tools — iptables, ip6tables, arptables, ebtables — each with its own syntax and its own kernel code, so an IPv4 and IPv6 dual-stack rule set meant maintaining two parallel configurations that could and did drift apart. nftables is one framework handling all address families, and a single rule can cover both.

Two other improvements matter operationally:

Sets and maps. Blocking a thousand addresses in iptables meant a thousand rules evaluated in sequence. nftables has native sets with efficient lookup, so it is one rule against one set. For anything driven by a dynamic blocklist — as fail2ban and CrowdSec are — this is the difference between a firewall that scales and one that degrades as it works.

Atomic replacement. A rule set is loaded as a whole and swapped in one transaction. iptables applied rules one at a time, meaning a window during a reload where the policy was partially applied — briefly permitting or blocking things neither the old nor the new configuration intended. Anyone who has locked themselves out during a firewall reload has met this.

Practical notes

The syntax is structured rather than flag-based, which reads better and means iptables knowledge does not transfer directly. Compatibility shims exist and translate faithfully enough that old rules keep working — which is exactly why many systems still have iptables-shaped rule sets running on nftables underneath, gaining none of the advantages.

Rules do not persist across reboot by themselves. Something has to load them — the distribution’s service, or systemd — and this is a routine way to discover after a reboot that a host has no firewall.

The default policy question is the one to get right first. Default-deny on input with explicit allows is the only defensible posture, and it is also the configuration that locks you out if the SSH rule is wrong. Testing with a scheduled rollback before committing is a habit worth having.

See also: fail2ban and CrowdSec which drive it, OpenSSH, and host hardening patterns.