The nftables framework provides a highly customizable packet filtering firewall service. It is part of the Linux kernel. It allows you to create complex firewall rules to enhance the system's security. This tutorial explains the basic concepts, fundamentals, and essential configuration steps of the nftables framework.
The nftables is the successor of the iptables, ip6tables, arptables, ebtables, and ipset frameworks. It introduced several new features and updated many existing ones to meet the requirements of modern networks. The following outlines summarize these changes.
- It uses a single framework for both IPv4 and IPv6 protocols.
- Instead of linear processing, it uses built-in lookup tables.
- It introduced a new API, called Netlink, for third-party applications.
- Instead of modifying the entire rule set, it updates the kernel rule set in place through transactions.
- It uses more consistent, compact, and straightforward syntax for rules.
- It does not need protocol-specific extensions.
- It added many new tools for debugging, tracing, and monitoring rule sets, such as nftrace and nft tools.
The tables, chains, and rules
Rules are the entries the nftables framework uses to filter the traffic. Chains are the containers for the rules. Tables save chains.

Tables
A table in the nftables framework contains chains and other objects. Unlike iptables, the nftables framework does not have predefined tables. You can create any number of tables with any names. However, each table can belong to only one type. The type defines the packet type that a table can filter. A table can process only packets belonging to the type assigned to it. A type is also known as an address family. There are five address families. The following table describes them.
| Table type (address family) | Description |
| ip | It is the default address family. It matches only IPv4 traffic. |
| ip6 | It matches only IPv6 traffic. |
| inet | It matches both IPv4 and IPv6 traffic. It simplifies dual-stack support. The rule in this family applies only to its related packets. For example, an IPv4 rule processes only IPv4 packets. It does not affect IPv6 traffic. Similarly, an IPv6 rule applies only to IPv6 packets. |
| arp | It matches ARP packets for IPv4. |
| bridge | It matches traffic that passes through a bridge device. If you use a Linux system as a router, you can use it to filter the traffic passing through it. |
| netdev | It matches the incoming traffic on an interface. You can use it to filter all types of traffic, including IPv4, IPv6, ARP, and bridge. It filters the packets just after the NIC driver passes them up to the networking stack. You can use it to place rules that protect the system from DDoS attacks. |
Chains
A chain store rules. The nftables framework does not provide any predefined chains. To filter packets at a specific processing step, you must create a chain and attach it to that particular hook. You can choose any name for the chain. There are two types of chains: base and regular.
Base chains
Base chains are the chains you can register to hook. These chains see and process data packets flowing through the system's TCP/IP stack. These chains work as an entry point for packets from the networking stack.
Regular chains
Regular chains are user-defined chains. You can not attach them to hooks. However, you can use them to arrange base chains. Rules in base chains support two options: jump and goto. Both options allow you to process the base chain rules in regular chains.
The goto and jump options
The goto and jump options allow you to process a base chain rule in a regular chain. If you use the jump option, it sends the packet to the specified chain, processes it there, and returns the processed packet to the original chain. If the original chain has further rules for the packet, it processes them. If you use the goto option, it sends the packet to the specified chain and processes it there. It does not return the processed packet to the original chain.

Base chain types
There are three types of base chains.
| Base chain type | Supported table types | Supported hooks | Description |
| filter | all | all | It filters data packets. |
| route | ip, ip6 | output | It reroutes packets if any relevant IP header field is modified. It causes a new route lookup. |
| nat | ip, ip6, inet | prerouting, input, output, postrouting | It performs Network Address Translation (NAT) for incoming packets. It conducts this translation only for the first packet of a given data stream. It bypasses all remaining packets of the stream. It speeds up the translation process. |
Hooks
A hook defines the place where you can place a rule. It supports the following hooks.
| ingress | It is the first hook. It sees traffic as soon as it enters the system. The NIC driver passes traffic to it. It works before the prerouting hook. It is available only for the netdev table. |
| prerouting | It sees all incoming traffic before the system makes the routing decision. Incoming traffic can be for the local system or a remote system if the system is configured as a router. |
| input | It processes the incoming traffic that crosses the prerouting hook and goes to the local system. |
| forward | It processes the incoming traffic that crosses the prerouting hook and goes to the remote system. |
| output | It processes traffic originating from the local system and destined for another system in the network. |
| postrouting | It processes traffic leaving the system. |

Chain priorities
The priority option defines the order in which it processes the packets with the same hook value. It accepts values in both names and numbers. The following table lists the standard priority names, their numerical values, and their supported tables and hooks.
| Name | Numerical value | Table type | Hook |
| raw | -300 | ip, ip6, inet | all |
| mangle | -150 | ip, ip6, inet | all |
| dstnat | -100 | ip, ip6, inet | prerouting |
| -300 | bridge | prerouting | |
| filter | 0 | ip, ip6, inet, arp, netdev | all |
| -200 | bridge | all | |
| security | 50 | ip, ip6, inet | all |
| srcnat | 100 | ip, ip6, inet | postrouting |
| 300 | bridge | postrouting | |
| out | 100 | bridge | output |
Chain policies
The chain policy defines the default behaviour for the chain. The default rule applies to a packet when it does not match any rule described in the chain. You can specify only two values here: 'accept' and 'drop'. The 'accept' is the default.
Rules
Rules define the actions that nftables take on matching packets. Chains save rules in lists. The firewall processes rules from top to bottom for every packet until it finds a match. Once it finds a match, it does not check the remaining rules for that packet.
Managing tables, chains, and rules
Unlike its predecessors, the nftables framework uses a single tool, called nft, for all management-related tasks. This section presents examples of all essential tasks you can perform with the nft command.
The following command lists all tables.

The following command creates a table named test_table of the inet address family. A table in inet address family can process both IPv4 and IPv6 packets.
#nft add table inet test_table
To verify the new table, you can list all tables again.

You cannot place rules directly in a table. A table saves chains. A chain saves the rules. You must create a chain before you can use it to save rules. The following command adds a base chain named INPUT to the test_table table.
#nft add chain inet test_table INPUT {type filter hook input priority filter; policy accept;}
The shell interprets a semicolon as the end of the command. If you use the above command, it returns an error. To fix it, escape the semicolons using the \ character.
#nft add chain inet test_table INPUT {type filter hook input priority filter \; policy accept \;}

A chain is a container. The above command adds a blank chain to the table. To use it for packet filtering, you must add rules to it.
The following commands add three rules.
The first rule accepts packets on port 21. Port 21 is associated with the FTP protocol.
The second rule allows traffic on port 80. Port 80 is related to the HTTP protocol.
The third rule rejects the ICMP echo requests with the port-unreachable message.
#nft add rule inet test_table INPUT tcp dport 21 accept #nft add rule inet test_table INPUT tcp dport 80 accept #nft add rule inet test_table INPUT reject with icmpx type port-unreachable
To verify the rules, you can list the chain.
#nft -a list table inet test_table

By default, it adds the new rule at the end of the chain. Use the 'insert' option to place it at the top of the chain. The difference between the 'add' and 'insert' options is that the first places the rule at the end of the chain, while the second inserts it at the top of the chain.
#nft add rule inet test_table INPUT tcp dport 22 accept #nft insert rule inet test_table INPUT tcp dport 107 reject #nft -a list table inet test_table

It assigns a sequence number, called a handle, to each rule. You can use it to add a rule at a particular place. For example, the following command adds a rule before rule number 3.
#nft insert rule inet test_table INPUT position 3 tcp dport 636 accept
The following command adds a rule after rule number 3.
#nft add rule inet test_table INPUT position 3 tcp dport 443 accept
You can list all rules again to verify that the new rules are placed at the custom location.
#nft -a list table inet test_table

To delete a rule, use its handle number. For example, the following command deletes rule number 6.
#nft delete rule inet test_table INPUT handle 6

To delete all rules from a chain, flush it. The following command deletes all rules from the INPUT chain.
#nft flush chain inet test_table INPUT
List the chain again to verify it.
#nft -a list table inet test_table

The following command deletes the INPUT chain from the test_table table.
#nft delete chain inet test_table INPUT
The following command verifies it.
#nft list table inet test_table

The following command deletes the test_table table.
#nft delete table inet test_table
Use the following command to verify it.

Conlcusion
The nftables framework provides a low-level firewall on Linux. It lets you create custom firewall rules tailored to complex network requirements. The tutorial explains the basic concepts and steps required to create, implement, and manage firewall rules in the nftables framework.