nftables: the Linux firewall that replaces iptables

The project arose from the limitations of iptables. That required four different commands for IPv4, IPv6, Ethernet frames, and ARP. The rule model was static and the internal data structures inefficient. nftables solves this with one daemon, one syntax, one tool (`nft`), and one kernel architecture.

History and development

The first public presentation of nftables took place at the Netfilter Workshop in 2008 in Paris. Patrick McHardy, a member of the Netfilter Core Team, released the first alpha version on March 18, 2009. This was an early development version, but it marked the transition from idea to functional software.

On October 16, 2013, Pablo Neira Ayuso submitted an "nftables core pull request" to the Linux kernel. The merge was completed on January 19, 2014, the same day kernel 3.13 was released. From that point on, nftables was part of the standard kernel.

The first end-user version, 0.099, appeared on January 20, 2014 — one day after the kernel integration. This gave users a stable tool to work with nftables in production environments.

The latest release is version 1.1.6, released on December 5, 2025. The nftables wiki confirms that releases have been maintained up to at least April 30, 2025 (version 1.1.3). The project is actively maintained.

Steps: getting started with nftables

1. Check if nftables is available

nft --version

This shows the version of the nft tool. If the command is not found, first install the package.

2. View the current ruleset

sudo nft list ruleset

This shows all existing tables, chains, and rules. On a new system, this is empty or only shows the default configuration of your distribution.

3. Create a table

sudo nft add table inet filter

This creates a table named "filter" for the family "inet". The `inet` family handles both IPv4 and IPv6 in one table — this is the major advantage over iptables, where you needed separate tables.

Other families are `ip` (IPv4 only), `ip6` (IPv6 only), `arp`, and `bridge`.

4. Add a chain

sudo nft add chain inet filter input { type filter hook input priority 0 \; policy accept \; }

This adds a chain named "input" that is linked to the input hook. The policy is set to `accept`, meaning all packets are allowed by default. The backslashes are needed to escape the braces and semicolons for the shell.

You have three standard hooks: `input` (incoming packets), `output` (outgoing packets), and `forward` (forwarded packets).

5. Add a rule

sudo nft add rule inet filter input tcp dport 22 accept

This accepts incoming TCP traffic on port 22 (SSH). The syntax is logically structured: first the table, then the chain, then the match criteria, then the action.

If you want to block all other traffic, add a drop rule after this rule:

sudo nft add rule inet filter input drop

6. Save the configuration

sudo nft list ruleset > /etc/nftables.conf

nftables rules are not persistent after a reboot. By writing the ruleset to the configuration file, the system loads the rules automatically at startup.

7. Reload the configuration

sudo nft -f /etc/nftables.conf

This reads the configuration file and applies all rules. Use this after editing the file or after restarting the service.

8. Use sets for more efficient rules

sudo nft add set inet filter blacklist { type ipv4_addr \; }
sudo nft add element inet filter blacklist { 192.168.1.100, 10.0.0.5 }
sudo nft add rule inet filter input ip saddr @blacklist drop

Sets are advanced data structures that are more efficient than linear rule chains. The kernel evaluates rules via hash tables or radix trees, which gives faster lookup times with large rule sets. You can also update sets dynamically without reloading the entire ruleset — essential in cloud and container environments.

Verification

Check if your firewall works correctly:

sudo nft list ruleset

This shows the full configuration. You should see your table, chain, and rules. Then test the connection to a blocked IP address:

ping -c 3 192.168.1.100

If the rule works, you will get no response. For an automated check with JSON output:

sudo nft -j list ruleset

This generates JSON that you can process with monitoring tools or logging systems.

Common problems

Problem: nft command not found Install the package:

sudo apt install nftables

On RHEL/Fedora:

sudo dnf install nftables

Problem: "Operation not permitted" error when adding rules You need root privileges. Use sudo or log in as root. Also check whether the kernel supports nftables:

cat /proc/net/netfilter/nf_tables

If this file does not exist, your kernel does not support nftables or the module is not loaded.

Problem: rules are gone after a reboot Write the ruleset to the configuration file and make sure the service is active:

sudo systemctl enable nftables
sudo systemctl start nftables

Integration with other systems

firewalld, the default firewall daemon on Red Hat-based systems, uses nftables as its default backend. Users who use firewalld are therefore already working with nftables without knowing it.

Docker supports nftables experimentally starting with Docker Engine 29.0.0. You can set the backend with:

dockerd --firewall-backend=nftables

This support is still experimental. The rules for overlay networks (Docker Swarm) have not been migrated yet, so you cannot enable nftables when Docker is running in Swarm mode.

Monitoring and debugging

The command `nft monitor` shows real-time changes to the firewall:

sudo nft monitor rules

This only tracks rule changes — additions, removals, and modifications. For automated systems:

sudo nft -j monitor

This generates JSON output that you can integrate with monitoring tools.

Security

nftables simplifies the kernel interface to a single system call (`nft`), which reduces the attack surface. You have fine-grained control over which users or processes may modify rules. This improves access management for the firewall.

The development of nftables is ongoing. The project adapts to the demands of modern network environments — from on-premise servers to cloud infrastructure and containers. With support from Red Hat via firewalld, Docker, and the Linux kernel itself, nftables is no longer an alternative, but the standard. The question is not whether you will switch, but when you will make the switch — and whether you still need legacy iptables configurations by the time the last iptables support disappears.