NFTables Framework

The nftables framework classifies packets and it is the successor to

the iptables, ip6tables, arptables, ebtables, and ipset utilities. It offers numerous
improvements in convenience, features, and performance over previous packet-
filtering tools, most notably:
• Built-in lookup tables instead of linear processing
• A single framework for both the IPv4 and IPv6 protocols
• All rules applied atomically instead of fetching, updating, and storing a
complete rule set
• Support for debugging and tracing in the rule set (nftrace) and monitoring
trace events (in the nft tool)
• More consistent and compact syntax, no protocol-specific extensions
• A Netlink API for third-party applications
The nftables framework uses tables to store chains. The chains contain individual
rules for performing actions. The nft utility replaces all tools from the previous
packet-filtering frameworks. You can use the libnftnl library for low-level
interaction with nftables Netlink API through the libmnl library.
To display the effect of rule set changes, use the nft list ruleset command. Because
these utilities add tables, chains, rules, sets, and other objects to the nftables rule
set, be aware that nftables rule-set operations, such as the nft flush
ruleset command, might affect rule sets installed using the iptables command.
Basics of nftables tables
A table in nftables is a namespace that contains a collection of chains, rules, sets,
and other objects.
Each table must have an address family assigned. The address family defines the
packet types that this table processes. You can set one of the following address
families when you create a table:
• ip: Matches only IPv4 packets. This is the default if you do not specify an
address family.
• ip6: Matches only IPv6 packets.
• inet: Matches both IPv4 and IPv6 packets.
• arp: Matches IPv4 address resolution protocol (ARP) packets.
• bridge: Matches packets that pass through a bridge device.
 • netdev: Matches packets from ingress.
If you want to add a table, the format to use depends on your firewall script:
• In scripts in native syntax, use:
• table <table_address_family> <table_name> {
}
• In shell scripts, use:
nft add table <table_address_family> <table_name>

Basics of nftables chains

Tables consist of chains which in turn are containers for rules. The following two
rule types exists:
• Base chain: You can use base chains as an entry point for packets from the
networking stack.
• Regular chain: You can use regular chains as a jump target to better organize
rules.
If you want to add a base chain to a table, the format to use depends on your
firewall script:
• In scripts in native syntax, use:
• table <table_address_family> <table_name> {
• chain <chain_name> {
• type <type> hook <hook> priority <priority>
• policy <policy> ;
• }
}
• In shell scripts, use:
nft add chain <table_address_family> <table_name> <chain_name> { type <type>
hook <hook> priority <priority> \; policy <policy> \; }
To avoid that the shell interprets the semicolons as the end of the command, place
the \ escape character in front of the semicolons.
Both examples create base chains. To create a regular chain, do not set any
parameters in the curly brackets.
Chain types
The following are the chain types and an overview with which address families and
hooks you can use them:

Type Address Hooks Description

families

filter all All Standard chain type

nat ip, ip6, inet prerouting, input, output, postrouting Chains of this type
perform native
address translation
based on connection tracking entries.
Only the first packet traverses this chain

route ip, ip6 output Accepted packets that traverse this cha
cause a new route lookup if relevant pa
the IP header have changed.

Chain priorities
The priority parameter specifies the order in which packets traverse chains with
the same hook value. You can set this parameter to an integer value or use a
standard priority name.
The following matrix is an overview of the standard priority names and their
numeric values, and with which address families and hooks you can use them:

Textual value Numeric value Address families

raw -300 ip, ip6, inet

mangle -150 ip, ip6, inet

dstnat -100 ip, ip6, inet

-300 bridge
Textual value Numeric value Address families

filter 0 ip, ip6, inet, arp, netdev

-200 bridge

security 50 ip, ip6, inet

srcnat 100 ip, ip6, inet

300 Bridge

out 100 Bridge

Chain policies
The chain policy defines whether nftables should accept or drop packets if rules in
this chain do not specify any action. You can set one of the following policies in a
chain:
• accept (default)
• drop

Basics of nftables rules

Rules define actions to perform on packets that pass a chain that contains this
rule. If the rule also contains matching expressions, nftables performs the actions
only if all previous expressions apply.
If you want to add a rule to a chain, the format to use depends on your firewall
script:
• In scripts in native syntax, use:
• table <table_address_family> <table_name> {
• chain <chain_name> {
• type <type> hook <hook> priority <priority> ; policy <policy> ;
• <rule>
• }
}
• In shell scripts, use:
nft add rule <table_address_family> <table_name> <chain_name> <rule>
This shell command appends the new rule at the end of the chain. If you prefer to
add a rule at the beginning of the chain, use the nft insert command instead of nft
add.

Managing tables, chains, and rules using nft commands

To manage an nftables firewall on the command line or in shell scripts, use
the nft utility.
Important
The commands in this procedure do not represent a typical workflow and are not
optimized. This procedure only demonstrates how to use nft commands to manage
tables, chains, and rules in general.
Procedure
1. Create a table named nftables_svc with the inet address family so that the
table can process both IPv4 and IPv6 packets:
# nft add table inet nftables_svc
2. Add a base chain named INPUT, that processes incoming network traffic, to
the inet nftables_svc table:
# nft add chain inet nftables_svc INPUT { type filter hook input priority filter \;
policy accept \; }
To avoid that the shell interprets the semicolons as the end of the command,
escape the semicolons using the \ character.
3. Add rules to the INPUT chain. For example, allow incoming TCP traffic on
port 22 and 443, and, as the last rule of the INPUT chain, reject other
incoming traffic with an Internet Control Message Protocol (ICMP) port
unreachable message:
4. # nft add rule inet nftables_svc INPUT tcp dport 22 accept
5. # nft add rule inet nftables_svc INPUT tcp dport 443 accept
# nft add rule inet nftables_svc INPUT reject with icmpx type port-unreachable
If you enter the nft add rule commands as shown, nft adds the rules in the same
order to the chain as you run the commands.
6. Display the current rule set including handles:
7. # nft -a list table inet nftables_svc
 8. table inet nftables_svc { # handle 13
9. chain INPUT { # handle 1
10. type filter hook input priority filter; policy accept;
11. tcp dport 22 accept # handle 2
12. tcp dport 443 accept # handle 3
13. reject # handle 4
14. }
}
15. Insert a rule before the existing rule with handle 3. For example, to insert a
rule that allows TCP traffic on port 636, enter:
# nft insert rule inet nftables_svc INPUT position 3 tcp dport 636 accept
16. Append a rule after the existing rule with handle 3. For example, to insert a
rule that allows TCP traffic on port 80, enter:
# nft add rule inet nftables_svc INPUT position 3 tcp dport 80 accept
17. Display the rule set again with handles. Verify that the later added rules have
been added to the specified positions:
18. # nft -a list table inet nftables_svc
19. table inet nftables_svc { # handle 13
20. chain INPUT { # handle 1
21. type filter hook input priority filter; policy accept;
22. tcp dport 22 accept # handle 2
23. tcp dport 636 accept # handle 5
24. tcp dport 443 accept # handle 3
25. tcp dport 80 accept # handle 6
26. reject # handle 4
27. }
}
28. Remove the rule with handle 6:
# nft delete rule inet nftables_svc INPUT handle 6
To remove a rule, you must specify the handle.
29. Display the rule set, and verify that the removed rule is no longer
present:
30. # nft -a list table inet nftables_svc
31. table inet nftables_svc { # handle 13
32. chain INPUT { # handle 1
33. type filter hook input priority filter; policy accept;
34. tcp dport 22 accept # handle 2
35. tcp dport 636 accept # handle 5
36. tcp dport 443 accept # handle 3
37. reject # handle 4
38. }
}
39. Remove all remaining rules from the INPUT chain:
# nft flush chain inet nftables_svc INPUT
40. Display the rule set, and verify that the INPUT chain is empty:
41. # nft list table inet nftables_svc
42. table inet nftables_svc {
43. chain INPUT {
44. type filter hook input priority filter; policy accept
45. }
}
46. Delete the INPUT chain:
# nft delete chain inet nftables_svc INPUT
You can also use this command to delete chains that still contain rules.
47. Display the rule set, and verify that the INPUT chain has been deleted:
48. # nft list table inet nftables_svc
49. table inet nftables_svc {
}
50. Delete the nftables_svc table:
# nft delete table inet nftables_svc
You can also use this command to delete tables that still contain chains.
Note
To delete the entire rule set, use the nft flush ruleset command instead of manually
deleting all rules, chains, and tables in separate commands.
Additional resources
nft(8) man page on your system

Migrating from iptables to nftables

If your firewall configuration still uses iptables rules, you can migrate
your iptables rules to nftables.

When to use firewalld, nftables, or iptables

The following is a brief overview in which scenario you should use one of the
following utilities:
• firewalld: Use the firewalld utility for simple firewall use cases. The utility is
easy to use and covers the typical use cases for these scenarios.
• nftables: Use the nftables utility to set up complex and performance-critical
firewalls, such as for a whole network.
• iptables: The iptables utility on Red Hat Enterprise Linux uses
the nftables kernel API instead of the legacy back end. The nftables API
provides backward compatibility so that scripts that use iptables commands
still work on Red Hat Enterprise Linux. For new firewall scripts, Red Hat
recommends to use nftables.
Important
To prevent the different firewall-related services (firewalld, nftables, or iptables)
from influencing each other, run only one of them on a RHEL host, and disable the
other services.
Concepts in the nftables framework
Compared to the iptables framework, nftables offers a more modern, efficient, and
flexible alternative. There are several concepts and features that provide advanced
capabilities and improvements over iptables. These enhancements simplify the rule
management and improve performance to make nftables a modern alternative for
complex and high-performance networking environments.
The nftables framework contains the following components:
Tables and namespaces
In nftables, tables represent organizational units or namespaces that group
together related firewall chains, sets, flowtables, and other objects. In nftables,
tables provide a more flexible way to structure firewall rules and related
components. While in iptables, the tables were more rigidly defined with specific
purposes.
Table families
Each table in nftables is associated with a specific family (ip, ip6, inet, arp, bridge,
or netdev). This association determines which packets the table can process. For
example, a table in the ip family handles only IPv4 packets. On the other
hand, inet is a special case of table family. It offers a unified approach across
protocols, because it can process both IPv4 and IPv6 packets. Another case of a
special table family is netdev, because it is used for rules that apply directly to
network devices, enabling filtering at the device level.
Base chains
Base chains in nftables are highly configurable entry-points in the packet
processing pipeline that enable users to specify the following:
• Type of chain, for example "filter"
• The hook point in the packet processing path, for example "input", "output",
"forward"
• Priority of the chain
This flexibility enables precise control over when and how the rules are applied to
packets as they pass through the network stack. A special case of a chain is
the route chain, which is used to influence the routing decisions made by the
kernel, based on packet headers.
Virtual machine for rule processing
The nftables framework uses an internal virtual machine to process rules. This
virtual machine executes instructions that are similar to assembly language
operations (loading data into registers, performing comparisons, and so on). Such
a mechanism allows for highly flexible and efficient rule processing.
Enhancements in nftables can be introduced as new instructions for that virtual
machine. This typically requires a new kernel module and updates to
the libnftnl library and the nft command-line utility.
Alternatively, you can introduce new features by combining existing instructions in
innovative ways without a need for kernel modifications. The syntax
of nftables rules reflects the flexibility of the underlying virtual machine. For
example, the rule meta mark set tcp dport map { 22: 1, 80: 2 } sets a packet’s firewall
mark to 1 if the TCP destination port is 22, and to 2 if the port is 80. This
demonstrates how complex logic can be expressed concisely.
Lessons learned and enhancements
The nftables framework integrates and extends the functionality of
the ipset utility, which is used in iptables for bulk matching on IP addresses, ports,
other data types and, most importantly, combinations thereof. This integration
makes it easier to manage large and dynamic sets of data directly within nftables.
Next, nftables natively supports matching packets based on multiple values or
ranges for any data type, which enhances its capability to handle complex filtering
requirements. With nftables you can manipulate any field within a packet.
In nftables, sets can be either named or anonymous. The named sets can be
referenced by multiple rules and modified dynamically. The anonymous sets are
defined inline within a rule and are immutable. Sets can contain elements that are
combinations of different types, for example IP address and port number pairs. This
feature provides greater flexibility in matching complex criteria. To manage sets,
the kernel can select the most appropriate backend based on the specific
requirements (performance, memory efficiency, and others). Sets can also function
as maps with key-value pairs. The value part can be used as data points (values to
write into packet headers), or as verdicts or chains to jump to. This enables complex
and dynamic rule behaviors, known as "verdict maps".
Flexible rule format
The structure of nftables rules is straightforward. The conditions and actions are
applied sequentially from left to right. This intuitive format simplifies rule creating
and troubleshooting.
Conditions in a rule are logically connected (with the AND operator) together,
which means that all conditions must be evaluated as "true" for the rule to match.
If any condition fails, the evaluation moves to the next rule.
Actions in nftables can be final, such as drop or accept, which stop further rule
processing for the packet. Non-terminal actions, such as counter log meta mark set
0x3, perform specific tasks (counting packets, logging, setting a mark, and others),
but allow subsequent rules to be evaluated.