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 build upon rules which specify the 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).

It is not hard to recognize the old tables framework in these tables. The only new one is the inet table which 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.

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.

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:

Emerge
Install :

Usage
All nftable commands are done with the nft ultility 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. It is supported to add comments to the file by prefixing them with.

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:

OpenRC configuration
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 configuration
After first setup:

Examples
See the Nftables examples article.

External Resources

 * http://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