Nftables

nftables is the successor to iptables. It replaces the existing iptables, ip6tables, arptables, and ebtables framework. It uses the Linux kernel and a new userspace utility called nft. nftables provides a compatibility layer for the ip(6)tables and framework.

Introduction
As with the iptables framework, nftables is built upon rules which specify actions. These rules are attached to chains. A chain can contain a collection of rules and is registered in the netfilter hooks. Chains are stored inside tables. A table is specific for one of the layer 3 protocols. One of the main differences with iptables is that there are no predefined tables and chains anymore.

Tables
A table is nothing more than a container for your chains. With nftables there are no predefined tables (filter, raw, mangle...) anymore. You are free to recreate an iptables-like structure, but anything might do.

Currently there are 5 different families of tables:


 * ip: Used for IPv4 related chains.
 * ip6: Used for IPv6 related chains.
 * arp: Used for ARP related chains.
 * bridge: Used for bridging related chains.
 * inet: Mixed ipv4/ipv6 chains (kernel 3.14 and up).
 * netdev: Used for chains that filter early in the stack (kernel 4.2 and up).

It is not hard to recognize the old tables framework in these tables. The inet and netdev table families have no equivalent in the iptables world, though. The table family inet is used for both IPv4 and IPv6 traffic. It should make firewalling for dual-stack hosts easier by combining the rules for IPv4 and IPv6. The table family netdev sees packets that the driver has just passed up to the networking stack. Therefore, it is used for very efficient ingress filtering, etc. It makes no assumptions about L2 and L3 protocols and sees all traffic for a given interface.

Chains
Chains are used to group together rules. As with the tables, nftables does not have any predefined chains. Chains are grouped in base and non-base types. Base chains are registered in one of the netfilter hooks, non-base chains are not. Thus, a base chain has a hook its registered with, a type, and a priority. In contrast, non-base chains are not attached to a hook and they don't see any traffic by default. They can be used to arrange a rule-set in a tree of chains.

There are currently three types of chains:


 * filter: for filtering packets.
 * route: for rerouting packets.
 * nat: for performing Network Address Translation. Only the first packet of a flow hits this chain, making it impossible to use it for filtering.

The hooks that can be used are:


 * prerouting: This is before the routing decision, all packets entering the machine hit this hook.
 * input: All packets for the local system hit this hook.
 * forward: Packets not for the local system, those that need to be forwarded hit this hook.
 * output: Packets that originate from the local system hit this hook.
 * postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook.

Rules
Rules specify which action has to be taken for which packets. Rules are attached to chains. Each rule can have an expression to match packets and one or more actions to perform when matching. One main difference to iptables is that it is possible to specify multiple actions per rule. Another is that by default counters are off. A counter must be specified explicitly in each rule for which you want packet- and byte-counters.

Each rule has a unique handle number by which it can be distinguished.

The following matches are available:


 * ip: IP protocol.
 * ip6: IPv6 protocol.
 * tcp: TCP protocol.
 * udp: UDP protocol.
 * udplite: UDP-lite protocol.
 * sctp: SCTP protocol.
 * dccp: DCCP protocol.
 * ah: Authentication headers.
 * esp: Encrypted security payload headers.
 * ipcomp: IPcomp headers.
 * icmp: icmp protocol.
 * icmpv6: icmpv6 protocol.
 * ct: Connection tracking.
 * meta: meta properties such as interfaces.

Statements
Statements represent the action to be performed when the rule matches. They exist in two kinds: Terminal statements, unconditionally terminate the evaluation of the current rules and non-terminal statements that either conditionally or never terminate the current rules. There can be an arbitrary amount of non-terminal statements, but there must be only a single terminal statement. The terminal statements can be:


 * accept: Accept the packet and stop the ruleset evaluation.
 * drop: Drop the packet and stop the ruleset evaluation.
 * reject: Reject the packet with an icmp message.
 * queue: Queue the packet to userspace and stop the ruleset evaluation.
 * continue:
 * return: Return from the current chain and continue at the next rule of the last chain. In a base chain it is equivalent to accept.
 * jump : Continue at the first rule of . It will continue at the next rule after a return statement is issued.
 * goto : Similar to jump, but after the new chain the evaluation will continue at the last chain instead of the one containing the goto statement.

Sets
nftables allows defining anonymous and named sets (dictionaries and maps). For example, the following nft script defines the fullbogons set, adds elements to it and drops packages from the IPs conforming the set.

Kernel
Nftables is very modular, so the bare minimum would depend on your intended purposes. A recommended minimum for basic IPv4 firewalling with NAT would be:

To use family inet for tables with mixed IPv4 and IPv6 rules:

If this is not enabled only families ip and ip6 can be used.

Early filtering based on network device requires netdev tables support:

Emerge
Install :

OpenRC
The init script supports the following actions:


 * stores the currently loaded ruleset in
 * loads the currently loaded ruleset in
 * is intended to be called on system shutdown, verifies if  is enabled in  and saves the ruleset
 * is intended to be called on system boot and loads the last saved ruleset
 * flushes the currently loaded ruleset
 * lists the currently loaded ruleset

Don't forget to add nftables service to startup:

systemd
After first setup:

Usage
All nftable commands are done with the nft utility from.

Creating tables
The following command adds a table called filter for the ip(v4) layer:

Likewise, a table for arp can be created with

Listing tables
The following command lists all tables for the ip(v4) layer:

The contents of the table filter can be listed with:

using -a with the nft command, it shows the handle of each rule. Handles are used for various operations on specific rules:

Deleting tables
The following command deletes the table called filter for the ip(v4) layer:

Adding chains
The following command adds a chain called input to the ip filter table and registered to the input hook with priority 0. It is of the type filter.

A non-base chain can be added by not specifying the chain configurations between the curly braces.

Removing chains
The following command deletes the chain called input

Adding rules
The following command adds a rule to the chain called input, on the ip filter table, dropping all incoming traffic to port 80:

Deleting rules
To delete a rule, you first need to get the handle number of the rule. This can be done by using the -a flag on nft:

It is then possible to delete the rule with:

Atomic rule loading
supports atomic rule replacement by using. Thus it is possible to conveniently manage the rules in a text file. Comments may be added to the file by prefixing them with, as with shell scripts; they can also be appended to the end of rules as  , and these will be preserved as-is in  output.

Compared to building a ruleset with multiple calls in a shell script, this also ensures that failures in such a script do not end with an only partially applied ruleset.

Backup
You can also backup your rules:

Start logging
Logging of e.g. dropped packages is possible by adding a line with the keyword log at the end of the rule-set, e.g..

Adding a prefix will produce a log entry to /var/log/messages, such as:

Configure syslog-ng
Logging will be written by default to messages file and will fill up the file with annoying information. Based on using the prefix, the syslog-ng filters will be used to redirect those to its own file nft.log.

Examples
See the Nftables examples article.

Troubleshooting
Before loading new or edited rules check them with

No such file or directory
If this error is printed for every chain of a table definition make sure, that the table's family is available through the kernel. This happens for example if the table uses family inet and the kernel configuration did not enable mixed IPv4 and IPv6 rules (CONFIG_NF_TABLES_INET).

Conflicting intervals
A set definition of IP ranges causes this error if ranges overlap. For example 224.0.0.0/3 and 240.0.0.0/5 overlap completely. Either add auto-merge to the set's options, drop the range that is fully included or change syntax to 224.0.0.0-255.255.255.255.

Restart of nftables or reboot cause blocked connections
Default configuration of the save and restore function use numeric mode to store the rule set. The persisted rule set could have changed from the original upload from a manually written file. Such a transformation might break things. Therefore make sure:


 * 1) that /etc/conf.d/nftables contains the parameter -n for the SAVE_OPTIONS
 * 2) and loading your rule set as root yields a working configuration
 * 3) and the save and restore cycle of restarting nftables service causes the issue

If all three conditions are met remove the -n parameter from SAVE_OPTIONS in /etc/conf.d/nftables. Then load your rule set again from the manually written file and restart the service again. This cycles through save and restore and should create a fully working rule set.

This affected at least version 0.9.9, see.

Family netdev and ingress hook
Broken packets should be rejected early which requires an ingress hook for family netdev. This sets up a chain that acts for a dedicated network device before packets enter further processing – improved performance. The configuration looks like this:

Mind the device name enp4s0. If this changes for example when changing hardware or an upgrade changed device naming this family is broken. In turn none of the rules will be loaded. The error looks like this (filename and line numbers differ depending on the host configuration):

{{CodeBox|title=Error at chains instead of non-existing device| /etc/nftables.conf:94:9-15: Error: Could not... chain ingress { ^^^^^^^ /etc/nftables.conf:94:9-15: Error: Could not... chain ingress { ^^^^^^^ /etc/nftables.conf:94:9-15: Error: Could not... chain ingress { ^^^^^^^ /etc/nftables.conf:94:9-15: Error: Could not... chain ingress { ^^^^^^^ /etc/nftables.conf:94:9-15: Error: Could not... chain ingress { ^^^^^^^

}}

Check the device name is actually correct and exists, e.g. {{c|ip addr list}}.

External Resources

 * https://kernelnewbies.org/nftables_examples
 * https://wiki.archlinux.org/index.php/Nftables
 * https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
 * https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftables_in_10_minutes
 * https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_iptables_to_nftables