nftables wiki - User contributions [en]

Netfilter hooks

2023-03-09T15:07:20Z

Fmyhr: /* Priority within hook */ Add lower priority limit for nat type chains.

''nftables'' uses mostly the same Netfilter infrastructure as legacy ''iptables''. The hook infrastructure, [http://people.netfilter.org/pablo/docs/login.pdf Connection Tracking System], NAT engine, logging infrastructure, and userspace queueing remain the same. Only the packet classification framework is new.

__TOC__

== Netfilter hooks into Linux networking packet flows ==

The following schematic shows packet flows through Linux networking:

https://people.netfilter.org/pablo/nf-hooks.png

Traffic flowing to the local machine in the input path sees the prerouting and input hooks. Then, the traffic that is generated by local processes follows the output and postrouting path.

If you configure your Linux box to behave as a router, do not forget to enable forwarding via:

echo 1 > /proc/sys/net/ipv4/ip_forward

Then packets that are not addressed to your local system will be seen from the forward hook. Such forwarded packets follow the path: prerouting, forward and postrouting.

In a major change from iptables, which predefines chains at '''every''' hook (i.e. ''INPUT'' chain in ''filter'' table), nftables predefines '''no''' chains at all. You must must explicitly create a [[Configuring_chains#Base_chain_hooks | base chain]] at each hook at which you want to filter traffic.

=== Ingress hook ===

The ingress hook was added in Linux kernel 4.2. Unlike the other netfilter hooks, the ingress hook is attached to a particular network interface.

You can use ''nftables'' with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.

The ingress hook provides an alternative to ''tc'' ingress filtering. You still need ''tc'' for traffic shaping/queue management.

== Hooks by family and chain type ==

The following table lists available hooks by [[Nftables_families|family]] and [[Configuring_chains#Base_chain_types|chain type]]. Minimum nftables and Linux kernel versions are shown for recently-added hooks.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" rowspan="2" | Chain type
! colspan="7" | Hooks

|-
! ingress
! prerouting
! forward
! input
! output
! postrouting
! egress

|- style="vertical-align:bottom;"
! colspan="8" | <br>inet family

|- style="vertical-align:top;"
| filter
| {{yes|1=[https://marc.info/?l=netfilter&m=160379555303808&w=2 0.9.7] / [https://kernelnewbies.org/Linux_5.10 5.10]}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| nat
| {{no}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| route
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}

|- style="vertical-align:bottom;"
! colspan="8" | <br>ip6 family

|- style="vertical-align:top;"
| filter
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| nat
| {{no}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| route
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}

|- style="vertical-align:bottom;"
! colspan="8" | <br>ip family

|- style="vertical-align:top;"
| filter
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| nat
| {{no}}
| {{yes}}
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| route
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{no}}
| {{no}}

|- style="vertical-align:bottom;"
! colspan="8" | <br>arp family

|- style="vertical-align:top;"
| filter
| {{no}}
| {{no}}
| {{no}}
| {{yes}}
| {{yes}}
| {{no}}
| {{no}}

|- style="vertical-align:top;"
| nat
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}

|- style="vertical-align:top;"
| route
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}

|- style="vertical-align:bottom;"
! colspan="8" | <br>bridge family

|- style="vertical-align:top;"
| filter
| {{no}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{yes}}
| {{no}}

|- style="vertical-align:top;"
| nat
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}

|- style="vertical-align:top;"
| route
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}

|- style="vertical-align:bottom;"
! colspan="8" | <br>netdev family

|- style="vertical-align:top;"
| filter
| {{yes|1=[https://marc.info/?l=netfilter&m=146488681521497&w=2 0.6] / [https://kernelnewbies.org/Linux_4.2 4.2]}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no|- / [https://kernelnewbies.org/Linux_5.7 5.7]}}

|- style="vertical-align:top;"
| nat
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}

|- style="vertical-align:top;"
| route
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}
| {{no}}

|}

== Priority within hook ==

Within a given hook, Netfilter performs operations in order of increasing numerical priority. Each nftables [[Configuring_chains#Base_chain_hooks | base chain]] and [[Flowtables|flowtable]] is assigned a priority that defines its ordering among other base chains and flowtables and Netfilter internal operations at the same hook. For example, a chain on the ''prerouting'' hook with priority ''-300'' will be placed before connection tracking operations.

The following table shows Netfilter priority values, check the nft manpage for reference.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | nftables [[Nftables_families|Families]]
! style="text-align:left;" | Typical hooks
! style="text-align:left;" | ''nft'' Keyword
! style="text-align:right;" | Value
! style="text-align:left;" | Netfilter Internal Priority
! style="text-align:left;" | Description

|- style="vertical-align:top;"
|
| prerouting
|
| style="text-align:right;" | -450
| NF_IP_PRI_RAW_BEFORE_DEFRAG
|

|- style="vertical-align:top;"
| inet, ip, ip6
| prerouting
|
| style="text-align:right;" | -400
| NF_IP_PRI_CONNTRACK_DEFRAG
| Packet defragmentation / datagram reassembly

|- style="vertical-align:top;"
| inet, ip, ip6
| all
| '''raw'''
| style="text-align:right;" | -300
| NF_IP_PRI_RAW
| Traditional priority of the raw table placed before connection tracking operation

|- style="vertical-align:top;"
|
|
|
| style="text-align:right;" | -225
| NF_IP_PRI_SELINUX_FIRST
| SELinux operations

|- style="vertical-align:top;"
| inet, ip, ip6
| prerouting, output
|
| style="text-align:right;" | -200
| NF_IP_PRI_CONNTRACK
| [[Connection_Tracking_System | Connection tracking]] processes run early in prerouting and output hooks to associate packets with tracked connections.

|- style="vertical-align:top;"
| inet, ip, ip6
| all
| '''mangle'''
| style="text-align:right;" | -150
| NF_IP_PRI_MANGLE
| Mangle operation

|- style="vertical-align:top;"
| inet, ip, ip6
| prerouting
| '''dstnat'''
| style="text-align:right;" | -100
| NF_IP_PRI_NAT_DST
| Destination NAT

|- style="vertical-align:top;"
| inet, ip, ip6, arp, netdev
| all
| '''filter'''
| style="text-align:right;" | 0
| NF_IP_PRI_FILTER
| Filtering operation, the filter table

|- style="vertical-align:top;"
| inet, ip, ip6
| all
| '''security'''
| style="text-align:right;" | 50
| NF_IP_PRI_SECURITY
| Place of security table, where secmark can be set for example

|- style="vertical-align:top;"
| inet, ip, ip6
| postrouting
| '''srcnat'''
| style="text-align:right;" | 100
| NF_IP_PRI_NAT_SRC
| Source NAT

|- style="vertical-align:top;"
|
| postrouting
|
| style="text-align:right;" | 225
| NF_IP_PRI_SELINUX_LAST
| SELinux at packet exit

|- style="vertical-align:top;"
| inet, ip, ip6
| postrouting
|
| style="text-align:right;" | 300
| NF_IP_PRI_CONNTRACK_HELPER
| Connection tracking helpers, which identify expected and related packets.

|- style="vertical-align:top;"
| inet, ip, ip6
| input, postrouting
|
| style="text-align:right;" | INT_MAX
| NF_IP_PRI_CONNTRACK_CONFIRM
| Connection tracking adds new tracked connections at final step in input & postrouting hooks.

|- style="vertical-align:top;"
| colspan="6" |  

|- style="vertical-align:top;"
| bridge
| prerouting
| '''dstnat'''
| style="text-align:right;" | -300
| NF_BR_PRI_NAT_DST_BRIDGED
|

|- style="vertical-align:top;"
| bridge
| all
| '''filter'''
| style="text-align:right;" | -200
| NF_BR_PRI_FILTER_BRIDGED
|

|- style="vertical-align:top;"
| bridge
|
|
| style="text-align:right;" | 0
| NF_BR_PRI_BRNF
|

|- style="vertical-align:top;"
| bridge
| output
| '''out'''
| style="text-align:right;" | 100
| NF_BR_PRI_NAT_DST_OTHER
|

|- style="vertical-align:top;"
| bridge
|
|
| style="text-align:right;" | 200
| NF_BR_PRI_FILTER_OTHER
|

|- style="vertical-align:top;"
| bridge
| postrouting
| '''srcnat'''
| style="text-align:right;" | 300
| NF_BR_PRI_NAT_SRC
|

|}

Starting with nftables 0.9.6 you may set priority using keywords instead of numbers. (Note that the same keyword maps to different numerical priorities in the bridge family vs. the other families.) You can also specify priority as an integral offset from a keyword, i.e. ''mangle - 5'' is equivalent to numerical priority -155.

It's possible to specify keyword priorities even in family/hook combinations where they don't make logical sense. Recall that the relative numerical ordering of priorities within a given hook is all that matters as far as Netfilter is concerned. Keep in mind that this relative ordering includes packet defragmentation, connection tracking and other Netfilter operations as well as your nftables base chains and flowtables.

NOTE: nat type chains must use priority > -200, which is used by conntrack hooks.

Talk:Simple ruleset for a server

2022-07-12T20:46:19Z

Fmyhr: Created page with "== Ping flood from single IP address not rate-limited by this ruleset == As [https://marc.info/?t=165710014500005&r=1&w=2 reported] in the netfilter mailing list, if the ping..."

== Ping flood from single IP address not rate-limited by this ruleset ==
As [https://marc.info/?t=165710014500005&r=1&w=2 reported] in the netfilter mailing list, if the ping rules in inbound_ipv4 and inbound_ipv6 are uncommented, the ct accept rule in the inbound chain accepts all pings from a single IP address, regardless of the rate limit in the ping rules. If ping floods from a single IP address are of concern in your installation, you will need to modify this ruleset. One way to do so is suggested in the linked mailing list thread.

News

2022-03-30T08:29:39Z

Fmyhr: /* Independent media coverage */ 2022-03-28 nftables security fixes

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2022-02-21
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.2]
| [https://marc.info/?l=netfilter&m=164546566103765&w=2 announcement]
| [https://packages.debian.org/bookworm/nftables bookworm]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.1]
| [https://marc.info/?l=netfilter&m=163723236100842&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2022-03-20
| [https://www.kernel.org/ 5.17]
|
* [https://lkml.org/lkml/2022/3/20/213 announcement]
* [https://lwn.net/Articles/887679/ LWN.net]
* [https://kernelnewbies.org/Linux_5.17 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 experimental]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Item

|- style="vertical-align:top;"
| 2022-03-28
| [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Some nftables security vulnerabilities], Jonathan Corbet, LWN.net

|- style="vertical-align:top;"
| 2021-08-27
| [https://lwn.net/Articles/889502/ Nftables reaches 1.0], Jonathan Corbet, LWN.net

|}

News

2022-03-30T08:18:53Z

Fmyhr: /* Linux kernel */ kernel 5.17

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2022-02-21
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.2]
| [https://marc.info/?l=netfilter&m=164546566103765&w=2 announcement]
| [https://packages.debian.org/bookworm/nftables bookworm]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.1]
| [https://marc.info/?l=netfilter&m=163723236100842&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2022-03-20
| [https://www.kernel.org/ 5.17]
|
* [https://lkml.org/lkml/2022/3/20/213 announcement]
* [https://lwn.net/Articles/887679/ LWN.net]
* [https://kernelnewbies.org/Linux_5.17 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 experimental]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2022-03-10T12:35:57Z

Fmyhr: /* Code Releases */ nftables 1.0.2, kernel 5.16

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2022-02-21
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.2]
| [https://marc.info/?l=netfilter&m=164546566103765&w=2 announcement]
| [https://packages.debian.org/bookworm/nftables bookworm]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.1]
| [https://marc.info/?l=netfilter&m=163723236100842&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2022-01-09
| [https://www.kernel.org/ 5.16]
|
* [https://lkml.org/lkml/2022/1/9/294 announcement]
* [https://lwn.net/Articles/880775/ LWN.net]
* [https://kernelnewbies.org/Linux_5.16 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 sid]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

List of updates in the nft command line tool

2022-03-10T12:16:06Z

Fmyhr: Add 1.0.2

This page contains links to nftables release announcements. In addition to a summary of bug fixes and new features, each announcement typically includes examples of how to use new features.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Release Announcement
! style="text-align:left;" | Comments

|- style="vertical-align:top;"
| 2022-02-21
| [https://marc.info/?l=netfilter&m=164546566103765&w=2 nftables 1.0.2]
|

|- style="vertical-align:top;"
| 2021-11-18
| [https://marc.info/?l=netfilter&m=163724233607275&w=2 nftables 1.0.1]
|

|- style="vertical-align:top;"
| 2021-08-19
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 nftables 1.0.0]
|

|- style="vertical-align:top;"
| 2021-05-25
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 nftables 0.9.9]
|

|- style="vertical-align:top;"
| 2021-01-15
| [https://marc.info/?l=netfilter&m=161074809318720&w=2 nftables 0.9.8]
|

|- style="vertical-align:top;"
| 2020-10-27
| [https://marc.info/?l=netfilter&m=160379555303808&w=2 nftables 0.9.7]
|

|- style="vertical-align:top;"
| 2020-06-15
| [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6]
|

|- style="vertical-align:top;"
| 2020-06-06
| [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5]
| This release broke ''vmap'' support, this is fixed in 0.9.6.

|- style="vertical-align:top;"
| 2020-04-01
| [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4]
|

|- style="vertical-align:top;"
| 2019-12-02
| [https://marc.info/?l=netfilter&m=157532146917292&w=2 nftables 0.9.3]
|

|- style="vertical-align:top;"
| 2019-08-19
| [https://marc.info/?l=netfilter&m=156621590113089&w=2 nftables 0.9.2]
|

|- style="vertical-align:top;"
| 2019-06-24
| [https://marc.info/?l=netfilter&m=156139496810281&w=2 nftables 0.9.1]
|

|- style="vertical-align:top;"
| 2019-06-08
| [https://marc.info/?l=netfilter&m=152849974510956&w=2 nftables 0.9.0]
|

|- style="vertical-align:top;"
| 2018-05-10
| [https://marc.info/?l=netfilter&m=152595594524056&w=2 nftables 0.8.5]
|

|- style="vertical-align:top;"
| 2018-05-01
| [https://marc.info/?l=netfilter&m=152521206028754&w=2 nftables 0.8.4]
|

|- style="vertical-align:top;"
| 2018-03-03
| [https://marc.info/?l=netfilter&m=152009279821556&w=2 nftables 0.8.3]
|

|- style="vertical-align:top;"
| 2018-02-02
| [https://marc.info/?l=netfilter&m=151759567102838&w=2 nftables 0.8.2]
|

|- style="vertical-align:top;"
| 2018-01-16
| [https://marc.info/?l=netfilter&m=151610774011377&w=2 nftables 0.8.1]
|

|- style="vertical-align:top;"
| 2017-10-12
| [https://marc.info/?l=netfilter&m=150785219810541&w=2 nftables 0.8]
|

|- style="vertical-align:top;"
| 2016-12-20
| [https://marc.info/?l=netfilter&m=148226682025890&w=2 nftables 0.7]
|

|- style="vertical-align:top;"
| 2016-06-02
| [https://marc.info/?l=netfilter&m=146488681521497&w=2 nftables 0.6]
|

|- style="vertical-align:top;"
| 2015-09-17
| [https://marc.info/?l=netfilter&m=144251853500774&w=2 nftables 0.5]
|

|- style="vertical-align:top;"
| 2014-12-16
| [https://marc.info/?l=netfilter&m=141869063212230&w=2 nftables 0.4]
|

|- style="vertical-align:top;"
| 2014-06-25
| [https://marc.info/?l=netfilter&m=140371155009356&w=2 nftables 0.3]
|

|- style="vertical-align:top;"
| 2014-04-14
| [https://marc.info/?l=netfilter&m=139747559724664&w=2 nftables 0.2]
|

|- style="vertical-align:top;"
| 2014-01-20
| [https://marc.info/?l=netfilter&m=139022350623824&w=2 nftables 0.099]
| The first released intended for users.

|- style="vertical-align:top;"
| 2009-03-18
| [https://marc.info/?l=netfilter-devel&m=123735060518576&w=2 nftables first alpha]
| First full public release, alpha quality not meant for users.
Release notes include design summary, with differences from iptables.

|}

List of updates in the nft command line tool

2021-11-23T16:03:11Z

Fmyhr: Add 1.0.1

This page contains links to nftables release announcements. In addition to a summary of bug fixes and new features, each announcement typically includes examples of how to use new features.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Release Announcement
! style="text-align:left;" | Comments

|- style="vertical-align:top;"
| 2021-11-18
| [https://marc.info/?l=netfilter&m=163724233607275&w=2 nftables 1.0.1]
|

|- style="vertical-align:top;"
| 2021-08-19
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 nftables 1.0.0]
|

|- style="vertical-align:top;"
| 2021-05-25
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 nftables 0.9.9]
|

|- style="vertical-align:top;"
| 2021-01-15
| [https://marc.info/?l=netfilter&m=161074809318720&w=2 nftables 0.9.8]
|

|- style="vertical-align:top;"
| 2020-10-27
| [https://marc.info/?l=netfilter&m=160379555303808&w=2 nftables 0.9.7]
|

|- style="vertical-align:top;"
| 2020-06-15
| [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6]
|

|- style="vertical-align:top;"
| 2020-06-06
| [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5]
| This release broke ''vmap'' support, this is fixed in 0.9.6.

|- style="vertical-align:top;"
| 2020-04-01
| [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4]
|

|- style="vertical-align:top;"
| 2019-12-02
| [https://marc.info/?l=netfilter&m=157532146917292&w=2 nftables 0.9.3]
|

|- style="vertical-align:top;"
| 2019-08-19
| [https://marc.info/?l=netfilter&m=156621590113089&w=2 nftables 0.9.2]
|

|- style="vertical-align:top;"
| 2019-06-24
| [https://marc.info/?l=netfilter&m=156139496810281&w=2 nftables 0.9.1]
|

|- style="vertical-align:top;"
| 2019-06-08
| [https://marc.info/?l=netfilter&m=152849974510956&w=2 nftables 0.9.0]
|

|- style="vertical-align:top;"
| 2018-05-10
| [https://marc.info/?l=netfilter&m=152595594524056&w=2 nftables 0.8.5]
|

|- style="vertical-align:top;"
| 2018-05-01
| [https://marc.info/?l=netfilter&m=152521206028754&w=2 nftables 0.8.4]
|

|- style="vertical-align:top;"
| 2018-03-03
| [https://marc.info/?l=netfilter&m=152009279821556&w=2 nftables 0.8.3]
|

|- style="vertical-align:top;"
| 2018-02-02
| [https://marc.info/?l=netfilter&m=151759567102838&w=2 nftables 0.8.2]
|

|- style="vertical-align:top;"
| 2018-01-16
| [https://marc.info/?l=netfilter&m=151610774011377&w=2 nftables 0.8.1]
|

|- style="vertical-align:top;"
| 2017-10-12
| [https://marc.info/?l=netfilter&m=150785219810541&w=2 nftables 0.8]
|

|- style="vertical-align:top;"
| 2016-12-20
| [https://marc.info/?l=netfilter&m=148226682025890&w=2 nftables 0.7]
|

|- style="vertical-align:top;"
| 2016-06-02
| [https://marc.info/?l=netfilter&m=146488681521497&w=2 nftables 0.6]
|

|- style="vertical-align:top;"
| 2015-09-17
| [https://marc.info/?l=netfilter&m=144251853500774&w=2 nftables 0.5]
|

|- style="vertical-align:top;"
| 2014-12-16
| [https://marc.info/?l=netfilter&m=141869063212230&w=2 nftables 0.4]
|

|- style="vertical-align:top;"
| 2014-06-25
| [https://marc.info/?l=netfilter&m=140371155009356&w=2 nftables 0.3]
|

|- style="vertical-align:top;"
| 2014-04-14
| [https://marc.info/?l=netfilter&m=139747559724664&w=2 nftables 0.2]
|

|- style="vertical-align:top;"
| 2014-01-20
| [https://marc.info/?l=netfilter&m=139022350623824&w=2 nftables 0.099]
| The first released intended for users.

|- style="vertical-align:top;"
| 2009-03-18
| [https://marc.info/?l=netfilter-devel&m=123735060518576&w=2 nftables first alpha]
| First full public release, alpha quality not meant for users.
Release notes include design summary, with differences from iptables.

|}

News

2021-11-23T16:00:59Z

Fmyhr: /* Linux kernel */ sid now has 5.15

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.1]
| [https://marc.info/?l=netfilter&m=163724233607275&w=2 announcement]
| [https://packages.debian.org/sid/nftables sid]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.1]
| [https://marc.info/?l=netfilter&m=163723236100842&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-10-31
| [https://www.kernel.org/ 5.15]
|
* [https://lkml.org/lkml/2021/10/31/203 announcement]
* [https://lwn.net/Articles/874493/ LWN.net]
* [https://kernelnewbies.org/Linux_5.15 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 sid]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-11-20T20:08:52Z

Fmyhr: /* libnftnl */ libnftnl 1.2.1

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.1]
| [https://marc.info/?l=netfilter&m=163724233607275&w=2 announcement]
| [https://packages.debian.org/sid/nftables sid]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.1]
| [https://marc.info/?l=netfilter&m=163723236100842&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-10-31
| [https://www.kernel.org/ 5.15]
|
* [https://lkml.org/lkml/2021/10/31/203 announcement]
* [https://lwn.net/Articles/874493/ LWN.net]
* [https://kernelnewbies.org/Linux_5.15 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 sid 5.4.12-1]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-11-20T20:07:05Z

Fmyhr: /* nft */ nftables 1.0.1

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-11-18
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.1]
| [https://marc.info/?l=netfilter&m=163724233607275&w=2 announcement]
| [https://packages.debian.org/sid/nftables sid]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/bookworm/libnftnl11 bookworm]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-10-31
| [https://www.kernel.org/ 5.15]
|
* [https://lkml.org/lkml/2021/10/31/203 announcement]
* [https://lwn.net/Articles/874493/ LWN.net]
* [https://kernelnewbies.org/Linux_5.15 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 sid 5.4.12-1]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

Limits

2021-11-01T17:46:44Z

Fmyhr: /* Declaring and using named limits */ Add optional text comment attribute.

A limit uses a [https://en.wikipedia.org/wiki/Token_bucket token bucket] filter to match packets:

* only until its rate is exceeded; or
* only after its rate is exceeded, if defined as an ''over'' limit.

= [[Rate_limiting_matchings|Anonymous limits]] =

= Named limits =

== Declaring and using named limits ==

<source>
table inet limit_demo {

limit lim_400ppm { rate 400/minute ; comment "use to limit incoming icmp" ; }
limit lim_1kbps { rate over 1024 bytes/second burst 512 bytes ; comment "use to limit incoming smtp" ; }

chain IN {
type filter hook input priority filter; policy drop;

meta l4proto icmp limit name "lim_400ppm" accept
tcp dport 25 limit name "lim_1kbps" accept
}
}
</source>

The above ruleset defines a per-packet named limit ''lim_400ppm'' and a per-byte named limit ''lim_1kbps''. The rules in input chain ''IN'' use these named limits to:
* Accept icmp packets, of all icmp types, up to a maximum rate of 400 packets / minute.
* Accept traffic to port tcp/25 (smtp), up to a maximum rate of 1024 bytes / second. Up to 512 bytes of such traffic arriving faster than this is accepted.
* Drop all other traffic.
The optional ''comment'' attribute requires at least nftables 0.9.7 and kernel 5.10.

== Listing named limits ==

''nft list [limit | limits]'' (as per below) returns the limit(s) with current byte count.

* List a particular limit:
<source>
% nft list limit [family] [table_name] [limit_name]
</source>

* List all limits in a particular table:
<source>
% nft list limits table [family] [table_name]
</source>

* List all limits in ruleset:
<source>
% nft list limits
</source>

Quotas

2021-11-01T17:42:24Z

Fmyhr: /* Declaring and using named quotas */ Add optional comment attribute.

A ''quota'':
<ol>
<li>defines a threshold number of bytes;</li>
<li>sets an initial byte count (defaults to 0 bytes if not specified);</li>
<li>counts the total number of bytes, starting from the initial count; and</li>
<li>matches either:
<ol style="list-style-type:lower-alpha">
<li>only ''until'' the byte count exceeds the threshold, or</li>
<li>only after the byte count is ''over'' the threshold.</li>
</ol>
</ol>

= Anonymous quotas =

An anonymous quota is local to the single rule in which it appears. The following example uses an anonymous quota to allow only up to 100 mbytes to port udp/5060:

<source>
table inet anon_quota_demo {
chain IN {
type filter hook input priority filter; policy drop;

udp dport 5060 quota until 100 mbytes accept
}
}
</source>

= Named quotas =

== Declaring and using named quotas ==

You can also declare named quotas, which can be used in multiple rules and maps (only as values, not as keys), as well as reset. For example:

<source>
table inet quota_demo {
quota q_until_sip { until 100 mbytes used 0 bytes }
quota q_over_http { over 500 mbytes ; comment "cap http (but not https)" ; }

chain IN {
type filter hook input priority filter; policy drop;

udp dport 5060 quota name "q_until_sip" accept
tcp dport 80 quota name "q_over_http" drop
tcp dport { 80, 443 } accept
}

}
</source>

The above ruleset defines a couple named quotas, each with initial count of 0 bytes. The rules in input chain ''IN'' use these named quotas to:
* accept only up to 100 mbytes total to udp/5060, then drop any additional packets to this (sip) port;
* accept only up to 500 mbytes total to tcp/80, then drop any additional packets to this (http) port;
* accept unlimited packets to tcp/443 (https);
* drop any other packets (note drop policy).
The optional ''comment'' attribute requires at least nftables 0.9.7 and kernel 5.10.

== Listing named quotas ==

''nft list [quota | quotas]'' (as per below) returns the quota(s) with current byte count.

* List a particular quota:
<source>
% nft list quota inet quota_demo q_over_http
</source>

* List all quotas in a particular table:
<source>
% nft list quotas table inet quota_demo
</source>

* List all quotas in ruleset:
<source>
% nft list quotas
</source>

== Resetting named quotas ==

Resetting a quota dumps its current byte count and then resets the byte count to its initial value.

* Reset a particular quota:
<source>
% nft reset quota inet quota_demo q_until_sip
</source>

* Reset all quotas in a particular table:
<source>
% nft reset quotas table inet quota_demo
</source>

* Reset all quotas in ruleset:
<source>
% nft reset quotas
</source>

'''Note:''' Resetting quotas does not reset anonymous quotas, see [https://bugzilla.netfilter.org/show_bug.cgi?id=1314 bug #1314].

Counters

2021-11-01T17:35:49Z

Fmyhr: /* Declaring and using named counters */ Add optional comment attribute.

A counter counts both the total number of packets and the total bytes it has seen since it was last reset. With nftables you need to explicitly specify a counter for each rule you want to count.

= Anonymous counters =

An anonymous counter is local to the single rule in which it appears. The following example uses an anonymous counter to count all tcp traffic routed to the local host:

<source>
table ip counter_demo {
chain IN {
type filter hook input priority filter; policy drop;

protocol tcp counter
}
}
</source>

'''Note''' that the position of the ''counter'' statement within your rule is significant, because nftables evaluates expressions and statements linearly from left to right. If the above rule were written instead:
<source>
counter protocol tcp
</source>

then '''every packet''' routed to your host (not just tcp packets) will update the counter!

= Named counters =

== Declaring and using named counters ==

You can also declare named counters, which can be used in multiple rules, e.g.:
<source>
table inet named_counter_demo {

counter cnt_http {
comment "count both http and https packets"
}

counter cnt_smtp {
}

chain IN {
type filter hook input priority filter; policy drop;

tcp dport 25 counter name cnt_smtp
tcp dport 80 counter name cnt_http
tcp dport 443 counter name cnt_http
}
}
</source>

The above example defines two counters named ''cnt_http'' and ''cnt_smtp'' and uses them in rules to count http(s) and smtp packets routed to the local host. (This example is contrived to show using a single named counter in multiple rules; the two rules using cnt_http can easily be combined by using an anonymous [[Sets|set]].) The optional ''comment'' attribute requires at least nftables 0.9.7 and kernel 5.10.

== Listing / reading named counters ==

=== Listing named counters from nft command line ===

''nft list [counter | counters]'' (as per below) returns the current value(s) of the selected counter(s).

* List a particular counter:
<source>
% nft list counter inet named_counter_demo cnt_http
</source>

* List all counters in a particular table:
<source>
% nft list counters table inet named_counter_demo
</source>

* List all counters in ruleset:
<source>
% nft list counters
</source>

=== Reading named counters from Python ===

The following partial ruleset (note the absence of a [[Configuring_chains#Adding_base_chains|base chain]]) defines two named counters ''voip1'' and ''voip2'' and uses them to count VoIP traffic to udp/5160 and udp/5161. The commented-out rules show how to do this in simple fashion, while the 2 final rules in the ''FORWARD'' chain do the same thing using the ''voipcounters'' [[Maps|map]]. The approach using the map becomes increasingly advantageous when more ports (map elements) are added.

<source>
define ipvoipbox=192.168.0.8

table ip filter {
counter voip1 {
}
counter voip2 {
}
map voipcounters {
type inet_service : counter
elements = {
5160 : "voip1",
5161 : "voip2"
}
}
chain FORWARD {
#ip saddr $ipvoipbox udp dport 5160 counter name voip1 comment "counting packets for SIP1"
#ip daddr $ipvoipbox udp dport 5160 counter name voip1 comment "counting packets for SIP1"
#ip saddr $ipvoipbox udp sport 5161 counter name voip2 comment "counting packets for SIP2"
#ip daddr $ipvoipbox udp dport 5161 counter name voip2 comment "counting packets for SIP2"
ip saddr $ipvoipbox counter name udp sport map @voipcounters
ip daddr $ipvoipbox counter name udp dport map @voipcounters
}
}
</source>

We can read current counter values from [[Scripting#Using_nftables_from_Python|Python using the libnftables library]]:

<source>
from nftables import Nftables
from nftables import json

def getCounter(countername, family='ip'):
nft = Nftables()
nft.set_json_output(True)
_, output, _ = nft.cmd(f"list counter {family} filter {countername}")
j = json.loads(output)
return j['nftables'][1]["counter"]["bytes"]

print(getCounter('voip1'), 'bytes')
print(getCounter('voip2'), 'bytes')
</source>

== Resetting named counters ==

Resetting a counter dumps its current packet and byte counts and then resets the counts to their initial values.

* Reset a particular counter:
<source>
% nft reset counter inet named_counter_demo cnt_http
</source>

* Reset all counters in a particular table:
<source>
% nft reset counters table inet named_counter_demo
</source>

* Reset all counters in ruleset:
<source>
% nft reset counters
</source>

'''Note:''' Resetting counters does not reset anonymous counters, see [https://bugzilla.netfilter.org/show_bug.cgi?id=1401 bug #1401].
A workaround to achieve that is to restore the current ruleset with all stateful information dropped:
<source>
% (echo "flush ruleset"; nft --stateless list ruleset) | nft -f -
</source>
Obviously, this drops all state so might have undesired side-effects, like, e.g. resetting quotas.

Sets

2021-11-01T17:26:06Z

Fmyhr: /* Named sets */ Add optional set comment attribute, with nft and kernel requirements.

''nftables'' comes with a built-in generic set infrastructure that allows you to use '''any''' supported selector to build sets. This infrastructure makes possible the representation of [[maps]] and [[Verdict_Maps_(vmaps) | verdict maps]].

The set elements are internally represented using performance data structures such as hashtables and red-black trees.

= Anonymous sets =

Anonymous sets are those that are:

* Bound to a rule, if the rule is removed, that set is released too.
* They have no specific name, the kernel internally allocates an identifier.
* They cannot be updated. So you cannot add and delete elements from it once it is bound to a rule.

The following example shows how to create a simple set.

<source lang="bash">
% nft add rule ip filter output tcp dport { 22, 23 } counter
</source>

This rule above catches all traffic going to TCP ports 22 and 23, in case of matching the counters are updated.

Eric Leblond in his [https://home.regit.org/2014/01/why-you-will-love-nftables/ Why you will love nftables] article shows a very simple example to compare iptables with nftables:

<source lang="bash">
ip6tables -A INPUT -p tcp -m multiport --dports 23,80,443 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT
</source>

Which can be expressed in ''nftables'' with a couple of rules that provide a set:

<source lang="bash">
% nft add rule ip6 filter input tcp dport {telnet, http, https} accept
% nft add rule ip6 filter input icmpv6 type { nd-neighbor-solicit, echo-request, nd-router-advert, nd-neighbor-advert } accept
</source>

= Named sets =

You can use ''nft add set'' to create a named set. For example:

<source lang="bash">
% nft add set ip filter blackhole { type ipv4_addr\; comment \"drop all packets from these hosts\" \; }
</source>

creates a set named ''blackhole''. Set names must be 16 characters or less. The optional set ''comment'' attribute requires at least nftables 0.9.7 and kernel 5.10. The ''type'' keyword indicates the data type of elements to be stored in the set. In this case ''blackhole'' stores IPv4 addresses, which you can add using ''nft add element'':

<source lang="bash">
% nft add element ip filter blackhole { 192.168.3.4 }
% nft add element ip filter blackhole { 192.168.1.4, 192.168.1.5 }
</source>

You can use named sets from rules, as for example:

<source lang="bash">
% nft add rule ip filter input ip saddr @blackhole drop
% nft add rule ip filter output ip daddr != @blackhole accept
</source>

Named sets can be updated anytime.

== nftables.conf syntax ==

When working with nftables.conf, you can define sets in a number of ways. You can then reference those sets later on using <code>$VARIABLE_NAME</code> notation.

Here are some examples showing sets defined in one line, spanning multiple lines, and sets referencing other sets. The set is then used in a rule to allow incoming traffic from certain IP ranges.

<source lang="bash">
define SIMPLE_SET = { 192.168.1.1, 192.168.1.2 }

define CDN_EDGE = {
192.168.1.1,
192.168.1.2,
192.168.1.3,
10.0.0.0/8
}

define CDN_MONITORS = {
192.168.1.10,
192.168.1.20
}

define CDN = {
$CDN_EDGE,
$CDN_MONITORS
}

# Allow HTTP(S) from approved IP ranges only
tcp dport { http, https } ip saddr $CDN accept
udp dport { http, https } ip saddr $CDN accept
</source>

= Named sets specifications =

Sets specifications are:

* '''type''' or '''typeof''', is obligatory and determines the data type of the set elements.

Supported data types if using the '''type''' keyword are:
** ''ipv4_addr'': IPv4 address
** ''ipv6_addr'': IPv6 address.
** ''ether_addr'': Ethernet address.
** ''inet_proto'': Inet protocol type.
** ''inet_service'': Internet service (read tcp port for example)
** ''mark'': Mark type.
** ''ifname'': Network interface name (eth0, eth1..)

The '''typeof''' keyword is available since '''0.9.4''' and allows you to use a high level expression, then let nftables resolve the base type for you:
<source lang="bash">
table inet mytable {
set s1 {
typeof osf name
elements = { "Linux" }
}
set s2 {
typeof vlan id
elements = { 2, 3, 103 }
}
set s3 {
typeof ip daddr
elements = { 1.1.1.1 }
}
}
</source>

* '''timeout''', it determines how long an element stays in the set. The time string respects the format: ''"v<sub>1</sub>dv<sub>2</sub>hv<sub>3</sub>mv<sub>4</sub>s"'':

<source lang="bash">
% nft add table ip filter
% nft add set ip filter ports {type inet_service \; timeout 3h45s \;}
</source>

These commands create a table named ''filter'' and add a set named ''ports'' to it, where elements are deleted after 3 hours and 45 seconds of being added.

* '''flags''', the available flags are:
** ''constant'' - set content may not change while bound
** ''interval'' - set contains intervals
** ''timeout'' - elements can be added with a timeout

Multiple flags should be separated by comma:

<source lang="bash">
% nft add set ip filter flags_set {type ipv4_addr\; flags constant, interval\;}
</source>

* '''gc-interval''', stands for garbage collection interval, can only be used if ''timeout'' or ''flags timeout'' are active. The interval follows the same format of ''timeouts'' time string ''"v<sub>1</sub>dv<sub>2</sub>hv<sub>3</sub>mv<sub>4</sub>s"''.

* '''elements''', initialize the set with some elements in it:

<source lang="bash">
% nft add set ip filter daddrs {type ipv4_addr \; flags timeout \; elements={192.168.1.1 timeout 10s, 192.168.1.2 timeout 30s} \;}
</source>

This command creates a set name ''daddrs'' with elements ''192.168.1.1'', which stays in it for 10s, and ''192.168.1.2'', which stays for 30s.

* '''size''', limits the maximum number of elements of the set. To create a set with maximum 2 elements type:

<source lang="bash">
% nft add set ip filter saddrs {type ipv4_addr \; size 2 \;}
</source>

* '''policy''', determines set selection policy. Available values are:
** ''performance'' [default]
** ''memory''

* '''counter''', (available since version '''0.9.5''') which enables a counter per element:
<source lang="bash">
table inet mytable {
set s {
typeof ip saddr
counter
elements = { 1.1.1.1 counter packets 0 bytes 0, 1.1.1.2 counter packets 0 bytes 0,
1.1.1.3 counter packets 0 bytes 0, 1.1.1.4 counter packets 0 bytes 0 }
}
}
</source>

= Listing named sets =

You can list the content of a named set via:

<source lang="bash">
% nft list set ip filter myset
</source>

= Query for element membership in a set =

You can also check if an element exists in the set from its key:

<source lang="bash">
% nft get element ip filter myset { 1.1.1.1 }
</source>

The example above checks if the IPv4 address 1.1.1.1 exists in the ''myset'' set.

Configuring chains

2021-11-01T17:14:40Z

Fmyhr: /* Adding base chains */ Add optional text comment parameter to base chain

As in ''iptables'', with ''nftables'' you attach your [[Simple rule management|rules]] to chains. Unlike in ''iptables'', there are no predefined chains like INPUT, OUTPUT, etc. Instead, to filter packets at a particular processing step, you explicitly create a '''base chain''' with name of your choosing, and attach it to the appropriate [[Netfilter hooks | Netfilter hook]]. This allows very flexible configurations without slowing Netfilter down with built-in chains not needed by your ruleset.

= Adding base chains =

Base chains are those that are registered into the [[Netfilter hooks]], i.e. these chains see packets flowing through your Linux TCP/IP stack.

The syntax to add a base chain is:

<source lang="bash">
% nft add chain [<family>] <table_name> <chain_name> { type <type> hook <hook> priority <value> \; [policy <policy> \;] [comment \"text comment\" \;] }
</source>

The following example shows how to add a new base chain ''input'' to the ''foo'' table (which must have been previously created):

<source lang="bash">
% nft 'add chain ip foo input { type filter hook input priority 0 ; }'
</source>

'''Important''': ''nft'' re-uses special characters, such as curly braces and the semicolon. If you are running these commands from a shell such as ''bash'', all the special characters need to be escaped. The simplest way to prevent the shell from attempting to parse the ''nft'' syntax is to quote everything within single quotes. Alternatively, you can run the command

<source lang="bash">
% nft -i
</source>

and run nft in interactive mode.

The ''add chain'' command registers the ''input'' chain, that it attached to the ''input'' hook so it will see packets that are addressed to the local processes.

The ''priority'' is important since it determines the ordering of the chains, thus, if you have several chains in the ''input'' hook, you can decide which one sees packets before another. For example, input chains with priorities -12, -1, 0, 10 would be consulted exactly in that order. It's possible to give two base chains the same priority, but there is no guaranteed evaluation order of base chains with identical priority that are attached to the same hook location.

If you want to use ''nftables'' to filter traffic for desktop Linux computers, i.e. a computer which does not forward traffic, you can also register the output chain:

<source lang="bash">
% nft 'add chain ip foo output { type filter hook output priority 0 ; }'
</source>

Now you are ready to filter incoming (directed to local processes) and outgoing (generated by local processes) traffic.

'''Important note''': If you don't include the chain configuration that is specified enclosed in the curly braces, you are creating a regular chain that will not see any packets (similar to ''iptables -N chain-name'').

Since nftables 0.5, you can also specify the default policy for base chains as in ''iptables'':

<source lang="bash">
% nft 'add chain ip foo output { type filter hook output priority 0 ; policy accept; }'
</source>

As in ''iptables'', the two possible default policies are ''accept'' and ''drop''.

When adding a chain on '''ingress''' hook, it is mandatory to specify the device where the chain will be attached:
<source lang="bash">
% nft 'add chain netdev foo dev0filter { type filter hook ingress device eth0 priority 0 ; }'
</source>

== Base chain types ==

The possible chain types are:

* '''filter''', which is used to filter packets. This is supported by the arp, bridge, ip, ip6 and inet table families.
* '''route''', which is used to reroute packets if any relevant IP header field or the packet mark is modified. If you are familiar with ''iptables'', this chain type provides equivalent semantics to the ''mangle'' table but only for the ''output'' hook (for other hooks use type ''filter'' instead). This is supported by the ip, ip6 and inet table families.
* '''nat''', which is used to perform Networking Address Translation (NAT). Only the first packet of a given flow hits this chain; subsequent packets bypass it. Therefore, never use this chain for filtering. The ''nat'' chain type is supported by the ip, ip6 and inet table families.

== Base chain hooks ==

The possible [[Netfilter_hooks | '''hooks''']] that you can use when you configure your base chain are:

* '''ingress''' (only in ''netdev'' family since Linux kernel 4.2, and ''inet'' family since Linux kernel 5.10): sees packets immediately after they are passed up from the NIC driver, before even prerouting. So you have an alternative to ''tc''.
* '''prerouting''': sees all incoming packets, before any routing decision has been made. Packets may be addressed to the local or remote systems.
* '''input''': sees incoming packets that are addressed to and have now been routed to the local system and processes running there.
* '''forward''': sees incoming packets that are not addressed to the local system.
* '''output''': sees packets that originated from processes in the local machine.
* '''postrouting''': sees all packets after routing, just before they leave the local system.

== Base chain priority ==

Each nftables base chain is assigned a [[Netfilter_hooks#Priority_within_hook|'''priority''']] that defines its ordering among other base chains, flowtables, and Netfilter internal operations at the same hook. For example, a chain on the ''prerouting'' hook with priority ''-300'' will be placed before connection tracking operations.

'''NOTE''': If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn't necessarily final. However, the same is ''not'' true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.

The following ruleset demonstrates this potentially surprising distinction in behaviour:

<pre>
table inet filter {
# This chain is evaluated first due to priority
chain services {
type filter hook input priority 0; policy accept;

# If matched, this rule will prevent any further evaluation
tcp dport http drop

# If matched, and despite the accept verdict, the packet proceeds to enter the chain below
tcp dport ssh accept

# Likewise for any packets that get this far and hit the default policy
}

# This chain is evaluated last due to priority
chain input {
type filter hook input priority 1; policy drop;
# All ingress packets end up being dropped here!
}
}
</pre>

If the priority of the 'input' chain above were to be changed to -1, the only difference would be that no packets have the opportunity to enter the 'services' chain. Either way, this ruleset will result in all ingress packets being dropped.

In summary, packets will traverse all of the chains within the scope of a given hook until they are either dropped or no more base chains exist. An accept verdict is only guaranteed to be final in the case that there is no later chain bearing the same type of hook as the chain that the packet originally entered.

Netfilter's hook execution mechanism is described in more detail in [http://people.netfilter.org/pablo/docs/login.pdf Pablo's paper on connection tracking].

== Base chain policy ==

This is the default verdict that will be applied to packets reaching the end of the chain (i.e, no more rules to be evaluated against).

Currently there are 2 policies: '''accept''' (default) or '''drop'''.

* The ''accept'' verdict means that the packet will keep traversing the network stack (default).
* The ''drop'' verdict means that the packet is discarded if the packet reaches the end of the base chain.

'''NOTE''': If no policy is explicitly selected, the default policy '''accept''' will be used.

= Adding regular chains =

You can also create regular chains, analogous to ''iptables'' user-defined chains:

<source>
# nft -i
nft> add chain [family] <table_name> <chain_name> [{ [policy <policy> ;] [comment "text comment about this chain" ;] }]
</source>

The chain name is an arbitrary string, with arbitrary case.

Note that no ''hook'' keyword is included when adding a regular chain. Because it is not attached to a Netfilter hook, '''by itself a regular chain does not see any traffic'''. But one or more base chains can include rules that [[jumping to chain|jump]] or goto this chain -- following which, the regular chain processes packets in exactly the same way as the calling base chain. It can be very useful to arrange your ruleset into a tree of base and regular chains by using the [[jumping to chain|jump]] and/or goto actions. (Though we're getting a bit ahead of ourselves, nftables [[Verdict_Maps_(vmaps)|vmaps]] provide an even more powerful way to construct highly-efficient branched rulesets.)

= Deleting chains =

You can delete chains as:

<source lang="bash">
% nft delete chain [family] <table_name> <chain_name>
</source>

The only condition is that the chain you want to delete needs to be empty, otherwise the kernel will complain that the chain is still in use.

<source lang="bash">
% nft delete chain ip foo input
<cmdline>:1:1-28: Error: Could not delete chain: Device or resource busy
delete chain ip foo input
^^^^^^^^^^^^^^^^^^^^^^^^^
</source>

You will have to [[Simple rule management|flush the ruleset]] in that chain before you can remove the chain.

= Flushing chains =

To flush (delete all of the rules in) the chain ''input'' of the ''foo'' table:

<source lang="bash">
nft flush chain foo input
</source>

= Example configuration: Filtering traffic for your standalone computer =

You can create a table with two base chains to define rule to filter traffic coming to and leaving from your computer, asumming IPv4 connectivity:

<source lang="bash">
% nft add table ip filter
% nft 'add chain ip filter input { type filter hook input priority 0 ; }'
% nft 'add chain ip filter output { type filter hook output priority 0 ; }'
</source>

Now, you can start attaching [[Simple rule management|rules]] to these two base chains. Note that you don't need the ''forward'' chain in this case since this example assumes that you're configuring nftables to filter traffic for a standalone computer that doesn't behave as router.

Configuring chains

2021-11-01T17:05:13Z

Fmyhr: /* Deleting chains */ generalize delete chain statement

As in ''iptables'', with ''nftables'' you attach your [[Simple rule management|rules]] to chains. Unlike in ''iptables'', there are no predefined chains like INPUT, OUTPUT, etc. Instead, to filter packets at a particular processing step, you explicitly create a '''base chain''' with name of your choosing, and attach it to the appropriate [[Netfilter hooks | Netfilter hook]]. This allows very flexible configurations without slowing Netfilter down with built-in chains not needed by your ruleset.

= Adding base chains =

Base chains are those that are registered into the [[Netfilter hooks]], i.e. these chains see packets flowing through your Linux TCP/IP stack.

The syntax to add a base chain is:

<source lang="bash">
% nft add chain [<family>] <table-name> <chain-name> { type <type> hook <hook> priority <value> \; [policy <policy>] }
</source>

The following example shows how to add a new base chain ''input'' to the ''foo'' table (which must have been previously created):

<source lang="bash">
% nft 'add chain ip foo input { type filter hook input priority 0 ; }'
</source>

'''Important''': ''nft'' re-uses special characters, such as curly braces and the semicolon. If you are running these commands from a shell such as ''bash'', all the special characters need to be escaped. The simplest way to prevent the shell from attempting to parse the ''nft'' syntax is to quote everything within single quotes. Alternatively, you can run the command

<source lang="bash">
% nft -i
</source>

and run nft in interactive mode.

The ''add chain'' command registers the ''input'' chain, that it attached to the ''input'' hook so it will see packets that are addressed to the local processes.

The ''priority'' is important since it determines the ordering of the chains, thus, if you have several chains in the ''input'' hook, you can decide which one sees packets before another. For example, input chains with priorities -12, -1, 0, 10 would be consulted exactly in that order. It's possible to give two base chains the same priority, but there is no guaranteed evaluation order of base chains with identical priority that are attached to the same hook location.

If you want to use ''nftables'' to filter traffic for desktop Linux computers, i.e. a computer which does not forward traffic, you can also register the output chain:

<source lang="bash">
% nft 'add chain ip foo output { type filter hook output priority 0 ; }'
</source>

Now you are ready to filter incoming (directed to local processes) and outgoing (generated by local processes) traffic.

'''Important note''': If you don't include the chain configuration that is specified enclosed in the curly braces, you are creating a regular chain that will not see any packets (similar to ''iptables -N chain-name'').

Since nftables 0.5, you can also specify the default policy for base chains as in ''iptables'':

<source lang="bash">
% nft 'add chain ip foo output { type filter hook output priority 0 ; policy accept; }'
</source>

As in ''iptables'', the two possible default policies are ''accept'' and ''drop''.

When adding a chain on '''ingress''' hook, it is mandatory to specify the device where the chain will be attached:
<source lang="bash">
% nft 'add chain netdev foo dev0filter { type filter hook ingress device eth0 priority 0 ; }'
</source>

== Base chain types ==

The possible chain types are:

* '''filter''', which is used to filter packets. This is supported by the arp, bridge, ip, ip6 and inet table families.
* '''route''', which is used to reroute packets if any relevant IP header field or the packet mark is modified. If you are familiar with ''iptables'', this chain type provides equivalent semantics to the ''mangle'' table but only for the ''output'' hook (for other hooks use type ''filter'' instead). This is supported by the ip, ip6 and inet table families.
* '''nat''', which is used to perform Networking Address Translation (NAT). Only the first packet of a given flow hits this chain; subsequent packets bypass it. Therefore, never use this chain for filtering. The ''nat'' chain type is supported by the ip, ip6 and inet table families.

== Base chain hooks ==

The possible [[Netfilter_hooks | '''hooks''']] that you can use when you configure your base chain are:

* '''ingress''' (only in ''netdev'' family since Linux kernel 4.2, and ''inet'' family since Linux kernel 5.10): sees packets immediately after they are passed up from the NIC driver, before even prerouting. So you have an alternative to ''tc''.
* '''prerouting''': sees all incoming packets, before any routing decision has been made. Packets may be addressed to the local or remote systems.
* '''input''': sees incoming packets that are addressed to and have now been routed to the local system and processes running there.
* '''forward''': sees incoming packets that are not addressed to the local system.
* '''output''': sees packets that originated from processes in the local machine.
* '''postrouting''': sees all packets after routing, just before they leave the local system.

== Base chain priority ==

Each nftables base chain is assigned a [[Netfilter_hooks#Priority_within_hook|'''priority''']] that defines its ordering among other base chains, flowtables, and Netfilter internal operations at the same hook. For example, a chain on the ''prerouting'' hook with priority ''-300'' will be placed before connection tracking operations.

'''NOTE''': If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn't necessarily final. However, the same is ''not'' true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.

The following ruleset demonstrates this potentially surprising distinction in behaviour:

<pre>
table inet filter {
# This chain is evaluated first due to priority
chain services {
type filter hook input priority 0; policy accept;

# If matched, this rule will prevent any further evaluation
tcp dport http drop

# If matched, and despite the accept verdict, the packet proceeds to enter the chain below
tcp dport ssh accept

# Likewise for any packets that get this far and hit the default policy
}

# This chain is evaluated last due to priority
chain input {
type filter hook input priority 1; policy drop;
# All ingress packets end up being dropped here!
}
}
</pre>

If the priority of the 'input' chain above were to be changed to -1, the only difference would be that no packets have the opportunity to enter the 'services' chain. Either way, this ruleset will result in all ingress packets being dropped.

In summary, packets will traverse all of the chains within the scope of a given hook until they are either dropped or no more base chains exist. An accept verdict is only guaranteed to be final in the case that there is no later chain bearing the same type of hook as the chain that the packet originally entered.

Netfilter's hook execution mechanism is described in more detail in [http://people.netfilter.org/pablo/docs/login.pdf Pablo's paper on connection tracking].

== Base chain policy ==

This is the default verdict that will be applied to packets reaching the end of the chain (i.e, no more rules to be evaluated against).

Currently there are 2 policies: '''accept''' (default) or '''drop'''.

* The ''accept'' verdict means that the packet will keep traversing the network stack (default).
* The ''drop'' verdict means that the packet is discarded if the packet reaches the end of the base chain.

'''NOTE''': If no policy is explicitly selected, the default policy '''accept''' will be used.

= Adding regular chains =

You can also create regular chains, analogous to ''iptables'' user-defined chains:

<source>
# nft -i
nft> add chain [family] <table_name> <chain_name> [{ [policy <policy> ;] [comment "text comment about this chain" ;] }]
</source>

The chain name is an arbitrary string, with arbitrary case.

Note that no ''hook'' keyword is included when adding a regular chain. Because it is not attached to a Netfilter hook, '''by itself a regular chain does not see any traffic'''. But one or more base chains can include rules that [[jumping to chain|jump]] or goto this chain -- following which, the regular chain processes packets in exactly the same way as the calling base chain. It can be very useful to arrange your ruleset into a tree of base and regular chains by using the [[jumping to chain|jump]] and/or goto actions. (Though we're getting a bit ahead of ourselves, nftables [[Verdict_Maps_(vmaps)|vmaps]] provide an even more powerful way to construct highly-efficient branched rulesets.)

= Deleting chains =

You can delete chains as:

<source lang="bash">
% nft delete chain [family] <table_name> <chain_name>
</source>

The only condition is that the chain you want to delete needs to be empty, otherwise the kernel will complain that the chain is still in use.

<source lang="bash">
% nft delete chain ip foo input
<cmdline>:1:1-28: Error: Could not delete chain: Device or resource busy
delete chain ip foo input
^^^^^^^^^^^^^^^^^^^^^^^^^
</source>

You will have to [[Simple rule management|flush the ruleset]] in that chain before you can remove the chain.

= Flushing chains =

To flush (delete all of the rules in) the chain ''input'' of the ''foo'' table:

<source lang="bash">
nft flush chain foo input
</source>

= Example configuration: Filtering traffic for your standalone computer =

You can create a table with two base chains to define rule to filter traffic coming to and leaving from your computer, asumming IPv4 connectivity:

<source lang="bash">
% nft add table ip filter
% nft 'add chain ip filter input { type filter hook input priority 0 ; }'
% nft 'add chain ip filter output { type filter hook output priority 0 ; }'
</source>

Now, you can start attaching [[Simple rule management|rules]] to these two base chains. Note that you don't need the ''forward'' chain in this case since this example assumes that you're configuring nftables to filter traffic for a standalone computer that doesn't behave as router.

Configuring chains

2021-11-01T17:02:14Z

Fmyhr: /* Adding regular chains */ Show optional family, policy and comment attributes.

As in ''iptables'', with ''nftables'' you attach your [[Simple rule management|rules]] to chains. Unlike in ''iptables'', there are no predefined chains like INPUT, OUTPUT, etc. Instead, to filter packets at a particular processing step, you explicitly create a '''base chain''' with name of your choosing, and attach it to the appropriate [[Netfilter hooks | Netfilter hook]]. This allows very flexible configurations without slowing Netfilter down with built-in chains not needed by your ruleset.

= Adding base chains =

Base chains are those that are registered into the [[Netfilter hooks]], i.e. these chains see packets flowing through your Linux TCP/IP stack.

The syntax to add a base chain is:

<source lang="bash">
% nft add chain [<family>] <table-name> <chain-name> { type <type> hook <hook> priority <value> \; [policy <policy>] }
</source>

The following example shows how to add a new base chain ''input'' to the ''foo'' table (which must have been previously created):

<source lang="bash">
% nft 'add chain ip foo input { type filter hook input priority 0 ; }'
</source>

'''Important''': ''nft'' re-uses special characters, such as curly braces and the semicolon. If you are running these commands from a shell such as ''bash'', all the special characters need to be escaped. The simplest way to prevent the shell from attempting to parse the ''nft'' syntax is to quote everything within single quotes. Alternatively, you can run the command

<source lang="bash">
% nft -i
</source>

and run nft in interactive mode.

The ''add chain'' command registers the ''input'' chain, that it attached to the ''input'' hook so it will see packets that are addressed to the local processes.

The ''priority'' is important since it determines the ordering of the chains, thus, if you have several chains in the ''input'' hook, you can decide which one sees packets before another. For example, input chains with priorities -12, -1, 0, 10 would be consulted exactly in that order. It's possible to give two base chains the same priority, but there is no guaranteed evaluation order of base chains with identical priority that are attached to the same hook location.

If you want to use ''nftables'' to filter traffic for desktop Linux computers, i.e. a computer which does not forward traffic, you can also register the output chain:

<source lang="bash">
% nft 'add chain ip foo output { type filter hook output priority 0 ; }'
</source>

Now you are ready to filter incoming (directed to local processes) and outgoing (generated by local processes) traffic.

'''Important note''': If you don't include the chain configuration that is specified enclosed in the curly braces, you are creating a regular chain that will not see any packets (similar to ''iptables -N chain-name'').

Since nftables 0.5, you can also specify the default policy for base chains as in ''iptables'':

<source lang="bash">
% nft 'add chain ip foo output { type filter hook output priority 0 ; policy accept; }'
</source>

As in ''iptables'', the two possible default policies are ''accept'' and ''drop''.

When adding a chain on '''ingress''' hook, it is mandatory to specify the device where the chain will be attached:
<source lang="bash">
% nft 'add chain netdev foo dev0filter { type filter hook ingress device eth0 priority 0 ; }'
</source>

== Base chain types ==

The possible chain types are:

* '''filter''', which is used to filter packets. This is supported by the arp, bridge, ip, ip6 and inet table families.
* '''route''', which is used to reroute packets if any relevant IP header field or the packet mark is modified. If you are familiar with ''iptables'', this chain type provides equivalent semantics to the ''mangle'' table but only for the ''output'' hook (for other hooks use type ''filter'' instead). This is supported by the ip, ip6 and inet table families.
* '''nat''', which is used to perform Networking Address Translation (NAT). Only the first packet of a given flow hits this chain; subsequent packets bypass it. Therefore, never use this chain for filtering. The ''nat'' chain type is supported by the ip, ip6 and inet table families.

== Base chain hooks ==

The possible [[Netfilter_hooks | '''hooks''']] that you can use when you configure your base chain are:

* '''ingress''' (only in ''netdev'' family since Linux kernel 4.2, and ''inet'' family since Linux kernel 5.10): sees packets immediately after they are passed up from the NIC driver, before even prerouting. So you have an alternative to ''tc''.
* '''prerouting''': sees all incoming packets, before any routing decision has been made. Packets may be addressed to the local or remote systems.
* '''input''': sees incoming packets that are addressed to and have now been routed to the local system and processes running there.
* '''forward''': sees incoming packets that are not addressed to the local system.
* '''output''': sees packets that originated from processes in the local machine.
* '''postrouting''': sees all packets after routing, just before they leave the local system.

== Base chain priority ==

Each nftables base chain is assigned a [[Netfilter_hooks#Priority_within_hook|'''priority''']] that defines its ordering among other base chains, flowtables, and Netfilter internal operations at the same hook. For example, a chain on the ''prerouting'' hook with priority ''-300'' will be placed before connection tracking operations.

'''NOTE''': If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn't necessarily final. However, the same is ''not'' true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.

The following ruleset demonstrates this potentially surprising distinction in behaviour:

<pre>
table inet filter {
# This chain is evaluated first due to priority
chain services {
type filter hook input priority 0; policy accept;

# If matched, this rule will prevent any further evaluation
tcp dport http drop

# If matched, and despite the accept verdict, the packet proceeds to enter the chain below
tcp dport ssh accept

# Likewise for any packets that get this far and hit the default policy
}

# This chain is evaluated last due to priority
chain input {
type filter hook input priority 1; policy drop;
# All ingress packets end up being dropped here!
}
}
</pre>

If the priority of the 'input' chain above were to be changed to -1, the only difference would be that no packets have the opportunity to enter the 'services' chain. Either way, this ruleset will result in all ingress packets being dropped.

In summary, packets will traverse all of the chains within the scope of a given hook until they are either dropped or no more base chains exist. An accept verdict is only guaranteed to be final in the case that there is no later chain bearing the same type of hook as the chain that the packet originally entered.

Netfilter's hook execution mechanism is described in more detail in [http://people.netfilter.org/pablo/docs/login.pdf Pablo's paper on connection tracking].

== Base chain policy ==

This is the default verdict that will be applied to packets reaching the end of the chain (i.e, no more rules to be evaluated against).

Currently there are 2 policies: '''accept''' (default) or '''drop'''.

* The ''accept'' verdict means that the packet will keep traversing the network stack (default).
* The ''drop'' verdict means that the packet is discarded if the packet reaches the end of the base chain.

'''NOTE''': If no policy is explicitly selected, the default policy '''accept''' will be used.

= Adding regular chains =

You can also create regular chains, analogous to ''iptables'' user-defined chains:

<source>
# nft -i
nft> add chain [family] <table_name> <chain_name> [{ [policy <policy> ;] [comment "text comment about this chain" ;] }]
</source>

The chain name is an arbitrary string, with arbitrary case.

Note that no ''hook'' keyword is included when adding a regular chain. Because it is not attached to a Netfilter hook, '''by itself a regular chain does not see any traffic'''. But one or more base chains can include rules that [[jumping to chain|jump]] or goto this chain -- following which, the regular chain processes packets in exactly the same way as the calling base chain. It can be very useful to arrange your ruleset into a tree of base and regular chains by using the [[jumping to chain|jump]] and/or goto actions. (Though we're getting a bit ahead of ourselves, nftables [[Verdict_Maps_(vmaps)|vmaps]] provide an even more powerful way to construct highly-efficient branched rulesets.)

= Deleting chains =

You can delete chains as:

<source lang="bash">
% nft delete chain ip foo input
</source>

The only condition is that the chain you want to delete needs to be empty, otherwise the kernel will complain that the chain is still in use.

<source lang="bash">
% nft delete chain ip foo input
<cmdline>:1:1-28: Error: Could not delete chain: Device or resource busy
delete chain ip foo input
^^^^^^^^^^^^^^^^^^^^^^^^^
</source>

You will have to [[Simple rule management|flush the ruleset]] in that chain before you can remove the chain.

= Flushing chains =

To flush (delete all of the rules in) the chain ''input'' of the ''foo'' table:

<source lang="bash">
nft flush chain foo input
</source>

= Example configuration: Filtering traffic for your standalone computer =

You can create a table with two base chains to define rule to filter traffic coming to and leaving from your computer, asumming IPv4 connectivity:

<source lang="bash">
% nft add table ip filter
% nft 'add chain ip filter input { type filter hook input priority 0 ; }'
% nft 'add chain ip filter output { type filter hook output priority 0 ; }'
</source>

Now, you can start attaching [[Simple rule management|rules]] to these two base chains. Note that you don't need the ''forward'' chain in this case since this example assumes that you're configuring nftables to filter traffic for a standalone computer that doesn't behave as router.

News

2021-11-01T15:59:20Z

Fmyhr: /* Linux kernel */ kernel 5.15 released

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/bookworm/nftables bookworm]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/bookworm/libnftnl11 bookworm]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-10-31
| [https://www.kernel.org/ 5.15]
|
* [https://lkml.org/lkml/2021/10/31/203 announcement]
* [https://lwn.net/Articles/874493/ LWN.net]
* [https://kernelnewbies.org/Linux_5.15 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 sid 5.4.12-1]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-09-15T08:52:42Z

Fmyhr: /* Linux kernel */ Kernel 5.14 now in experimental

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/bookworm/nftables bookworm]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/bookworm/libnftnl11 bookworm]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 experimental]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-09-13T15:24:28Z

Fmyhr: /* nft */ nft 1.0.0 now in bookworm

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/bookworm/nftables bookworm]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/bookworm/libnftnl11 bookworm]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 5.13 experimental as of 2021-09-07]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-09-13T15:23:19Z

Fmyhr: /* libnftnl */ libnftnl 1.2.0 now in bookworm

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/sid/nftables sid]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/bookworm/libnftnl11 bookworm]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 5.13 experimental as of 2021-09-07]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-09-07T22:01:42Z

Fmyhr: /* Linux kernel */

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/sid/nftables sid]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 5.13 experimental as of 2021-09-07]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-09-07T22:00:55Z

Fmyhr: /* nft */ nft 1.0.0 in sid

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/sid/nftables sid]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 5.13 experimental as of 2021-08-30]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-09-04T21:32:41Z

Fmyhr: /* libnftnl */ libnftnl 1.2.0 graduated to sid

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental, 0.9.9 as of 2021-08-26]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/sid/libnftnl11 sid]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 5.13 experimental as of 2021-08-30]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-08-30T14:10:19Z

Fmyhr: /* Linux kernel */ Kernel 5.14

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental, 0.9.9 as of 2021-08-26]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.14]
|
* [https://lkml.org/lkml/2021/8/29/382 announcement]
* [https://lwn.net/Articles/867706/ LWN.net]
* [https://kernelnewbies.org/Linux_5.14 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 5.13 experimental as of 2021-08-30]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

News

2021-08-30T13:59:00Z

Fmyhr: Added Independent media coverage section.

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental, 0.9.9 as of 2021-08-26]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.13]
|
* [https://lore.kernel.org/lkml/CAHk-=wj7E9iTGHbqfgtaTAM09WrVzwXjda2_D59MT8D_1=54Rg@mail.gmail.com/ announcement]
* [https://lwn.net/Articles/861145/ lwn]
* [https://kernelnewbies.org/Linux_5.13 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 experimental]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

== Independent media coverage ==
* [https://lwn.net/SubscriberLink/867185/31fb43f2f1ff4641/ Nftables reaches 1.0], Jonathan Corbet, [https://lwn.net/ LWN.net], 2021-08-27.

List of updates in the nft command line tool

2021-08-27T21:42:48Z

Fmyhr: Clearer column headers

This page contains links to nftables release announcements. In addition to a summary of bug fixes and new features, each announcement typically includes examples of how to use new features.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Release Announcement
! style="text-align:left;" | Comments

|- style="vertical-align:top;"
| 2021-08-19
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 nftables 1.0.0]
|

|- style="vertical-align:top;"
| 2021-05-25
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 nftables 0.9.9]
|

|- style="vertical-align:top;"
| 2021-01-15
| [https://marc.info/?l=netfilter&m=161074809318720&w=2 nftables 0.9.8]
|

|- style="vertical-align:top;"
| 2020-10-27
| [https://marc.info/?l=netfilter&m=160379555303808&w=2 nftables 0.9.7]
|

|- style="vertical-align:top;"
| 2020-06-15
| [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6]
|

|- style="vertical-align:top;"
| 2020-06-06
| [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5]
| This release broke ''vmap'' support, this is fixed in 0.9.6.

|- style="vertical-align:top;"
| 2020-04-01
| [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4]
|

|- style="vertical-align:top;"
| 2019-12-02
| [https://marc.info/?l=netfilter&m=157532146917292&w=2 nftables 0.9.3]
|

|- style="vertical-align:top;"
| 2019-08-19
| [https://marc.info/?l=netfilter&m=156621590113089&w=2 nftables 0.9.2]
|

|- style="vertical-align:top;"
| 2019-06-24
| [https://marc.info/?l=netfilter&m=156139496810281&w=2 nftables 0.9.1]
|

|- style="vertical-align:top;"
| 2019-06-08
| [https://marc.info/?l=netfilter&m=152849974510956&w=2 nftables 0.9.0]
|

|- style="vertical-align:top;"
| 2018-05-10
| [https://marc.info/?l=netfilter&m=152595594524056&w=2 nftables 0.8.5]
|

|- style="vertical-align:top;"
| 2018-05-01
| [https://marc.info/?l=netfilter&m=152521206028754&w=2 nftables 0.8.4]
|

|- style="vertical-align:top;"
| 2018-03-03
| [https://marc.info/?l=netfilter&m=152009279821556&w=2 nftables 0.8.3]
|

|- style="vertical-align:top;"
| 2018-02-02
| [https://marc.info/?l=netfilter&m=151759567102838&w=2 nftables 0.8.2]
|

|- style="vertical-align:top;"
| 2018-01-16
| [https://marc.info/?l=netfilter&m=151610774011377&w=2 nftables 0.8.1]
|

|- style="vertical-align:top;"
| 2017-10-12
| [https://marc.info/?l=netfilter&m=150785219810541&w=2 nftables 0.8]
|

|- style="vertical-align:top;"
| 2016-12-20
| [https://marc.info/?l=netfilter&m=148226682025890&w=2 nftables 0.7]
|

|- style="vertical-align:top;"
| 2016-06-02
| [https://marc.info/?l=netfilter&m=146488681521497&w=2 nftables 0.6]
|

|- style="vertical-align:top;"
| 2015-09-17
| [https://marc.info/?l=netfilter&m=144251853500774&w=2 nftables 0.5]
|

|- style="vertical-align:top;"
| 2014-12-16
| [https://marc.info/?l=netfilter&m=141869063212230&w=2 nftables 0.4]
|

|- style="vertical-align:top;"
| 2014-06-25
| [https://marc.info/?l=netfilter&m=140371155009356&w=2 nftables 0.3]
|

|- style="vertical-align:top;"
| 2014-04-14
| [https://marc.info/?l=netfilter&m=139747559724664&w=2 nftables 0.2]
|

|- style="vertical-align:top;"
| 2014-01-20
| [https://marc.info/?l=netfilter&m=139022350623824&w=2 nftables 0.099]
| The first released intended for users.

|- style="vertical-align:top;"
| 2009-03-18
| [https://marc.info/?l=netfilter-devel&m=123735060518576&w=2 nftables first alpha]
| First full public release, alpha quality not meant for users.
Release notes include design summary, with differences from iptables.

|}

Matching packet headers

2021-08-27T18:20:52Z

Fmyhr: /* Matching UDP/TCP headers in the same rule */ link man page for raw payload expression

The ''nft'' command line utility supports the following layer 4 protocols: AH, ESP, UDP, UDPlite, TCP, DCCP, SCTP and IPComp.

= Matching ethernet headers =

You can match packets on [https://en.wikipedia.org/wiki/Ethernet ethernet] source or destination address or on [https://en.wikipedia.org/wiki/EtherType EtherType]:
* ''ether'' {''saddr'' | ''daddr''} «[[Data_types#Ethernet_types|ether_addr]]»
* ''ether type'' «[[Data_types#Ethernet_types|ether_type]]»

If you want to match ethernet traffic whose destination address is ff:ff:ff:ff:ff:ff, you can type the following command:

<source lang="bash">
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
</source>

You can also match packets on [https://en.wikipedia.org/wiki/IEEE_802.1Q IEEE 802.1Q] VLAN fields, if present:
* ''vlan type'' «[[Data_types#Ethernet_types|ether_type]]» - always ''vlan'' for 802.1Q
* ''vlan id'' «12-bit integer» - match VID, the VLAN ID
* ''vlan cfi'' «1-bit integer» - match DEI, Drop Eligible Indicator (formerly CFI, Canonical Format Indicator)
* ''vlan pcp'' «3-bit integer» - match [https://en.wikipedia.org/wiki/IEEE_P802.1p IEEE P802.1p PCP, Priority Code Point]

Do not forget that the [https://en.wikipedia.org/wiki/Link_layer layer 2] header information is only available in the input path.

= Matching ARP headers =

You can match [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP] headers:
* ''arp htype'' «[[Data_types#ARP_types|16-bit integer HTYPE]]» - match hardware link protocol type (1 for ethernet)
* ''arp ptype'' «[[Data_types#Ethernet_types|ether_type]]» - match EtherType
* ''arp hlen'' «[[Data_types#ARP_types|8-bit integer HLEN]]» - match hardware address length in octets (6 for ethernet)
* ''arp plen'' «[[Data_types#ARP_types|8-bit integer PLEN]]» - match internetwork protocol address length in octets (4 for IPv4)
* ''arp operation'' «[[Data_types#ARP_types|arp_op]]» - match ARP operation
* ''arp'' {''saddr'' | ''daddr ''} ''ether'' «[[Data_types#Ethernet_types|ether_addr]]» - ''saddr'' matches SHA, Sender Hardware Address; ''daddr'' matches THA, Target Hardware Address
* ''arp'' {''saddr'' | ''daddr ''} ''ip'' «[[Data_types#IP_types|ipv4_addr]]» - ''saddr'' matches SPA, Sender Protocol Address; ''daddr'' matches TPA, Target Protocol Address

= Matching IPv4 headers =

You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:

<source lang="bash">
% nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter
</source>

Note that, since the rule is attached to the input chain, your local machine needs to use the 192.168.1.1 address, otherwise you won't see any matching ;-).

To filter on a layer 4 protocol like TCP, you can use the ''protocol'' keyword:
<source lang="bash">
% nft add rule filter input protocol tcp counter
</source>

= Matching ICMP traffic =

You can drop all [https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] echo requests (popularly known as ''pings'') via:

<source lang="bash">
% nft add rule filter input icmp type echo-request counter drop
</source>

You can use ''nft describe'' to find ''nft'''s available ''icmp type'' keywords:
<source lang="bash">
% nft describe icmp type
payload expression, datatype icmp_type (ICMP type) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
echo-reply 0
destination-unreachable 3
source-quench 4
redirect 5
echo-request 8
router-advertisement 9
router-solicitation 10
time-exceeded 11
parameter-problem 12
timestamp-request 13
timestamp-reply 14
info-request 15
info-reply 16
address-mask-request 17
address-mask-reply 18
</source>

You can also be more specific by matching a single icmp code:
<source lang="bash">
% nft describe icmp code
payload expression, datatype icmp_code (icmp code) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
net-unreachable 0
host-unreachable 1
prot-unreachable 2
port-unreachable 3
net-prohibited 9
host-prohibited 10
admin-prohibited 13
frag-needed 4

% nft add rule filter output icmp code frag-needed counter accept
</source>

= Matching IPv6 headers =

If you want to account IPv6 traffic that is addressed to ''abcd::100'', you can type the following command:

<source lang="bash">
% nft add rule filter output ip6 daddr abcd::100 counter
</source>

To filter on a layer 4 protocol like TCP, you can use the ''nexthdr'' keyword:

<source lang="bash">
% nft add rule filter input ip6 nexthdr tcp counter
</source>

Do not forget to create an ''ip6'' [[Configuring tables|table]] and register the corresponding [[Configuring chains|chains]] to run the examples.

NOTE: the syntax mixing IPv6/IPv4 notation is not supported yet: '::ffff:192.168.1.0'

= Matching transport protocol =

The following rule shows how to match any kind of ''TCP'' traffic:

<source lang="bash">
% nft add rule filter output ip protocol tcp
</source>

If you are on the ''inet'' family, then use ''meta l4proto'':

<source lang="bash">
% nft add rule inet filter output meta l4proto tcp
</source>

This allows you to match on the transport protocol regardless the packet is either IPv4 or IPv6.

= Matching TCP/UDP/UDPlite traffic =

The following examples show how to drop all tcp traffic for low TCP ports (1-1024):

<source lang="bash">
% nft add rule filter input tcp dport 1-1024 counter drop
</source>

Note that this rule is using an [[intervals|interval]] (from 1 to 1024).

To match on TCP flags, you need to use a binary operation. For example, to count packets that are not SYN ones:

<source lang="bash">
% nft add rule filter input tcp flags != syn counter
</source>

More complex filters can be used. For example, to count and log TCP packets with flags SYN and ACK set:

<source lang="bash">
% nft -i
nft> add rule filter output tcp flags & (syn | ack) == syn | ack counter log
</source>

This example drops TCP SYN packets which a MSS lower than 500:

<source lang="bash">
% nft add rule inet filter input tcp flags syn tcp option maxseg size 1-500 drop
</source>

= Matching UDP/TCP headers in the same rule =

The following example uses an anonymous l4proto [[Sets|set]] and a ''th'' (transport header) expression to match both TCP and UDP packets directed to port 53 (DNS):

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } th dport 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Note: Before nftables 0.9.2 and Linux kernel 5.3 the ''th'' expression is not available. In this case you can use a [https://www.mankier.com/8/nft#Payload_Expressions-Raw_Payload_Expression raw payload expression] to do the same job:

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } @th,16,16 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

News

2021-08-26T21:18:00Z

Fmyhr: /* Linux kernel */ Debian experimental kernel 5.13

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental, 0.9.9 as of 2021-08-26]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.13]
|
* [https://lore.kernel.org/lkml/CAHk-=wj7E9iTGHbqfgtaTAM09WrVzwXjda2_D59MT8D_1=54Rg@mail.gmail.com/ announcement]
* [https://lwn.net/Articles/861145/ lwn]
* [https://kernelnewbies.org/Linux_5.13 KernelNewbies]
| [https://packages.debian.org/experimental/linux-image-amd64 experimental]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

News

2021-08-26T21:14:50Z

Fmyhr: /* nft */ release 1.0.0

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://www.netfilter.org/projects/nftables/downloads.html 1.0.0]
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental, 0.9.9 as of 2021-08-26]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.13]
|
* [https://lore.kernel.org/lkml/CAHk-=wj7E9iTGHbqfgtaTAM09WrVzwXjda2_D59MT8D_1=54Rg@mail.gmail.com/ announcement]
* [https://lwn.net/Articles/861145/ lwn]
* [https://kernelnewbies.org/Linux_5.13 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 5.10.46 as of 2021-06-28]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

List of updates in the nft command line tool

2021-08-26T21:11:29Z

Fmyhr: nftables 1.0.0

This page contains links to nftables release announcements. In addition to a summary of bug fixes and new features, each announcement typically includes examples of how to use new features.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Release
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-08-19
| [https://marc.info/?l=netfilter&m=162939459210790&w=2 nftables 1.0.0]
|

|- style="vertical-align:top;"
| 2021-05-25
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 nftables 0.9.9]
|

|- style="vertical-align:top;"
| 2021-01-15
| [https://marc.info/?l=netfilter&m=161074809318720&w=2 nftables 0.9.8]
|

|- style="vertical-align:top;"
| 2020-10-27
| [https://marc.info/?l=netfilter&m=160379555303808&w=2 nftables 0.9.7]
|

|- style="vertical-align:top;"
| 2020-06-15
| [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6]
|

|- style="vertical-align:top;"
| 2020-06-06
| [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5]
| This release broke ''vmap'' support, this is fixed in 0.9.6.

|- style="vertical-align:top;"
| 2020-04-01
| [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4]
|

|- style="vertical-align:top;"
| 2019-12-02
| [https://marc.info/?l=netfilter&m=157532146917292&w=2 nftables 0.9.3]
|

|- style="vertical-align:top;"
| 2019-08-19
| [https://marc.info/?l=netfilter&m=156621590113089&w=2 nftables 0.9.2]
|

|- style="vertical-align:top;"
| 2019-06-24
| [https://marc.info/?l=netfilter&m=156139496810281&w=2 nftables 0.9.1]
|

|- style="vertical-align:top;"
| 2019-06-08
| [https://marc.info/?l=netfilter&m=152849974510956&w=2 nftables 0.9.0]
|

|- style="vertical-align:top;"
| 2018-05-10
| [https://marc.info/?l=netfilter&m=152595594524056&w=2 nftables 0.8.5]
|

|- style="vertical-align:top;"
| 2018-05-01
| [https://marc.info/?l=netfilter&m=152521206028754&w=2 nftables 0.8.4]
|

|- style="vertical-align:top;"
| 2018-03-03
| [https://marc.info/?l=netfilter&m=152009279821556&w=2 nftables 0.8.3]
|

|- style="vertical-align:top;"
| 2018-02-02
| [https://marc.info/?l=netfilter&m=151759567102838&w=2 nftables 0.8.2]
|

|- style="vertical-align:top;"
| 2018-01-16
| [https://marc.info/?l=netfilter&m=151610774011377&w=2 nftables 0.8.1]
|

|- style="vertical-align:top;"
| 2017-10-12
| [https://marc.info/?l=netfilter&m=150785219810541&w=2 nftables 0.8]
|

|- style="vertical-align:top;"
| 2016-12-20
| [https://marc.info/?l=netfilter&m=148226682025890&w=2 nftables 0.7]
|

|- style="vertical-align:top;"
| 2016-06-02
| [https://marc.info/?l=netfilter&m=146488681521497&w=2 nftables 0.6]
|

|- style="vertical-align:top;"
| 2015-09-17
| [https://marc.info/?l=netfilter&m=144251853500774&w=2 nftables 0.5]
|

|- style="vertical-align:top;"
| 2014-12-16
| [https://marc.info/?l=netfilter&m=141869063212230&w=2 nftables 0.4]
|

|- style="vertical-align:top;"
| 2014-06-25
| [https://marc.info/?l=netfilter&m=140371155009356&w=2 nftables 0.3]
|

|- style="vertical-align:top;"
| 2014-04-14
| [https://marc.info/?l=netfilter&m=139747559724664&w=2 nftables 0.2]
|

|- style="vertical-align:top;"
| 2014-01-20
| [https://marc.info/?l=netfilter&m=139022350623824&w=2 nftables 0.099]
| The first released intended for users.

|- style="vertical-align:top;"
| 2009-03-18
| [https://marc.info/?l=netfilter-devel&m=123735060518576&w=2 nftables first alpha]
| First full public release, alpha quality not meant for users.
Release notes include design summary, with differences from iptables.

|}

News

2021-06-28T13:35:43Z

Fmyhr: /* Linux kernel */ kernel 5.13 released

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/nftables/downloads.html 0.9.9]
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-06-27
| [https://www.kernel.org/ 5.13]
|
* [https://lore.kernel.org/lkml/CAHk-=wj7E9iTGHbqfgtaTAM09WrVzwXjda2_D59MT8D_1=54Rg@mail.gmail.com/ announcement]
* [https://lwn.net/Articles/861145/ lwn]
* [https://kernelnewbies.org/Linux_5.13 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 5.10.46 as of 2021-06-28]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

News

2021-06-07T11:13:36Z

Fmyhr: /* Code Releases */ Fix date of nft 0.9.9 release

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/nftables/downloads.html 0.9.9]
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-02-14
| [https://www.kernel.org/ 5.12]
|
* [https://lore.kernel.org/lkml/CAHk-=wj3ANm8QrkC7GTAxQyXyurS0_yxMR3WwjhD9r7kTiOSTw@mail.gmail.com/ announcement]
* [https://lwn.net/Articles/853289/ lwn]
* [https://kernelnewbies.org/Linux_5.12 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 5.10.38 as of 2021-05-28]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

News

2021-05-28T11:22:18Z

Fmyhr: /* Code Releases */ New releases of nft, libnftnl and kernel

__NOTOC__
== Code Releases ==

=== nft ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-01-15
| [https://www.netfilter.org/projects/nftables/downloads.html 0.9.9]
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 announcement]
| [https://packages.debian.org/experimental/nftables experimental]
|
* [http://git.netfilter.org/nftables/log/?showmsg=1 newest commits]
* [[List_of_updates_in_the_nft_command_line_tool|previous releases]]
|}

=== libnftnl ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://www.netfilter.org/projects/libnftnl/downloads.html 1.2.0]
| [https://marc.info/?l=netfilter&m=162194376520385&w=2 announcement]
| [https://packages.debian.org/experimental/libnftnl11 experimental]
|
* [http://git.netfilter.org/libnftnl/log/ newest commits]
|}

=== Linux kernel ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-02-14
| [https://www.kernel.org/ 5.12]
|
* [https://lore.kernel.org/lkml/CAHk-=wj3ANm8QrkC7GTAxQyXyurS0_yxMR3WwjhD9r7kTiOSTw@mail.gmail.com/ announcement]
* [https://lwn.net/Articles/853289/ lwn]
* [https://kernelnewbies.org/Linux_5.12 KernelNewbies]
| [https://packages.debian.org/sid/linux-image-amd64 5.10.38 as of 2021-05-28]
|
* [[List_of_updates_since_Linux_kernel_3.13|previous releases]]
* Often, newest ''nft'' doesn't require newest kernel; check ''nft'' release notes.
|}

=== conntrack-tools ===
{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Source
! style="text-align:left;" | Release Notes
! style="text-align:left;" | Debian Pkg
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2020-04-01
| [http://www.netfilter.org/projects/conntrack-tools/downloads.html 1.4.6]
| [https://marc.info/?l=netfilter&m=158576302510982&w=2 announcement]
| [https://packages.debian.org/bullseye/conntrack bullseye]
|
* [http://www.netfilter.org/projects/conntrack-tools/downloads.html previous releases]
|}

== [https://bugzilla.netfilter.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&chfieldfrom=-90d&chfieldto=Now&component=iptables%20over%20nftable&component=kernel&component=nft&list_id=3971&product=nftables&query_format=advanced&resolution=--- Bug activity, past 90 days] ==

== [https://www.spinics.net/lists/netfilter/ Latest discussion in netfilter mailing list] ==

== [https://www.netfilter.org/news.html Netfilter news] ==

== Wiki ==
Notice [[Special:RecentChanges|''Recent changes'']] in the ''navigation'' panel at upper left. :-)

List of updates in the nft command line tool

2021-05-28T11:06:45Z

Fmyhr: Add nftables 0.9.9

This page contains links to nftables release announcements. In addition to a summary of bug fixes and new features, each announcement typically includes examples of how to use new features.

{| class="wikitable"
|- style="vertical-align:bottom;"
! style="text-align:left;" | Date
! style="text-align:left;" | Release
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| 2021-05-25
| [https://marc.info/?l=netfilter&m=162197756905358&w=2 nftables 0.9.9]
|

|- style="vertical-align:top;"
| 2021-01-15
| [https://marc.info/?l=netfilter&m=161074809318720&w=2 nftables 0.9.8]
|

|- style="vertical-align:top;"
| 2020-10-27
| [https://marc.info/?l=netfilter&m=160379555303808&w=2 nftables 0.9.7]
|

|- style="vertical-align:top;"
| 2020-06-15
| [https://marc.info/?l=netfilter&m=159225380419197&w=2 nftables 0.9.6]
|

|- style="vertical-align:top;"
| 2020-06-06
| [https://marc.info/?l=netfilter&m=159144250132190&w=2 nftables 0.9.5]
| This release broke ''vmap'' support, this is fixed in 0.9.6.

|- style="vertical-align:top;"
| 2020-04-01
| [https://marc.info/?l=netfilter&m=158575148505527&w=2 nftables 0.9.4]
|

|- style="vertical-align:top;"
| 2019-12-02
| [https://marc.info/?l=netfilter&m=157532146917292&w=2 nftables 0.9.3]
|

|- style="vertical-align:top;"
| 2019-08-19
| [https://marc.info/?l=netfilter&m=156621590113089&w=2 nftables 0.9.2]
|

|- style="vertical-align:top;"
| 2019-06-24
| [https://marc.info/?l=netfilter&m=156139496810281&w=2 nftables 0.9.1]
|

|- style="vertical-align:top;"
| 2019-06-08
| [https://marc.info/?l=netfilter&m=152849974510956&w=2 nftables 0.9.0]
|

|- style="vertical-align:top;"
| 2018-05-10
| [https://marc.info/?l=netfilter&m=152595594524056&w=2 nftables 0.8.5]
|

|- style="vertical-align:top;"
| 2018-05-01
| [https://marc.info/?l=netfilter&m=152521206028754&w=2 nftables 0.8.4]
|

|- style="vertical-align:top;"
| 2018-03-03
| [https://marc.info/?l=netfilter&m=152009279821556&w=2 nftables 0.8.3]
|

|- style="vertical-align:top;"
| 2018-02-02
| [https://marc.info/?l=netfilter&m=151759567102838&w=2 nftables 0.8.2]
|

|- style="vertical-align:top;"
| 2018-01-16
| [https://marc.info/?l=netfilter&m=151610774011377&w=2 nftables 0.8.1]
|

|- style="vertical-align:top;"
| 2017-10-12
| [https://marc.info/?l=netfilter&m=150785219810541&w=2 nftables 0.8]
|

|- style="vertical-align:top;"
| 2016-12-20
| [https://marc.info/?l=netfilter&m=148226682025890&w=2 nftables 0.7]
|

|- style="vertical-align:top;"
| 2016-06-02
| [https://marc.info/?l=netfilter&m=146488681521497&w=2 nftables 0.6]
|

|- style="vertical-align:top;"
| 2015-09-17
| [https://marc.info/?l=netfilter&m=144251853500774&w=2 nftables 0.5]
|

|- style="vertical-align:top;"
| 2014-12-16
| [https://marc.info/?l=netfilter&m=141869063212230&w=2 nftables 0.4]
|

|- style="vertical-align:top;"
| 2014-06-25
| [https://marc.info/?l=netfilter&m=140371155009356&w=2 nftables 0.3]
|

|- style="vertical-align:top;"
| 2014-04-14
| [https://marc.info/?l=netfilter&m=139747559724664&w=2 nftables 0.2]
|

|- style="vertical-align:top;"
| 2014-01-20
| [https://marc.info/?l=netfilter&m=139022350623824&w=2 nftables 0.099]
| The first released intended for users.

|- style="vertical-align:top;"
| 2009-03-18
| [https://marc.info/?l=netfilter-devel&m=123735060518576&w=2 nftables first alpha]
| First full public release, alpha quality not meant for users.
Release notes include design summary, with differences from iptables.

|}

Main Page

2021-04-21T02:07:28Z

Fmyhr: Expressions: moved meta expressions to first topic.

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= [[News]] =

= Introduction =
* [[What is nftables?]]
* [[How to obtain help/support]]

= Reference =
* [https://www.netfilter.org/projects/nftables/manpage.html man nft - netfilter website]
* [https://www.mankier.com/8/nft man nft - mankier.com]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[Netfilter hooks]] and nftables integration with existing Netfilter components
* [[nftables families|Understanding nftables families]]
* [[Data_types|Data types]]
* [[Connection_Tracking_System|Connection tracking system (conntrack)]], used for stateful firewalling and NAT
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Further_documentation|Additional documentation]]

= Installing nftables =
* [[nftables from distributions|Using nftables from distributions]]
* [[Building and installing nftables from sources]]

= Upgrading from xtables to nftables =
* [[Legacy xtables tools]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]

= Basic operation =
* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Output text modifiers]]

= Expressions: Matching packets =
* [[Matching packet metainformation]]
* [[Matching packet headers]]
* [[Matching connection tracking stateful metainformation]]
* [[Matching routing information]]
* [[Rate limiting matchings]]

= Statements: Acting on packet matches =
* [[Accepting and dropping packets]]
* [[Rejecting traffic]]
* [[Jumping to chain]]
* [[Counters]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Setting packet connection tracking metainformation]]
* [[Mangling packet headers]] (including stateless NAT)
* [[Duplicating packets]]
* [[Load balancing]]
* [[Queueing to userspace]]

= Advanced data structures for performance packet classification =
* [[Intervals]]
* [[Concatenations]]
* [[Math operations]]
* [[Stateful objects]]
** [[Counters]]
** [[Quotas]]
** [[Limits]]
** [[Connlimits]] (''ct count'')
* Other objects
** [[Conntrack helpers]] (''ct helper'', Layer 7 ALG)
** [[Ct_timeout|Conntrack timeout policies]] (''ct timeout'')
** [[Ct_expectation|Conntrack expectations]] (''ct expectation'')
** [[Synproxy]]
** [[Secmark|Secmarks]]
* Generic set infrastructure
** [[Sets]]
** [[Element timeouts]]
** [[Updating sets from the packet path]]
** [[Maps]]
** [[Verdict_Maps_(vmaps) | Verdict maps]]
** [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1)
* [[Flowtables]] (the fastpath network stack bypass)

= Examples =
* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter mini-workshop (2017)]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop (2018)]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop (2019)]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter mini-Workshop (2020)]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]
* Article [https://ral-arturo.org/2020/11/22/python-nftables-tutorial.html How to use nftables from python] and git repository [https://github.com/aborrero/python-nftables-tutorial python-nftables-tutorial.git]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Main Page

2021-04-20T15:08:46Z

Fmyhr: References: added conntrack link.

Welcome to the ''nftables'' HOWTO documentation page. Here you will find documentation on how to build, install, configure and use nftables.

If you have any suggestion to improve it, please send your comments to Netfilter users mailing list <netfilter@vger.kernel.org>.

= [[News]] =

= Introduction =
* [[What is nftables?]]
* [[How to obtain help/support]]

= Reference =
* [https://www.netfilter.org/projects/nftables/manpage.html man nft - netfilter website]
* [https://www.mankier.com/8/nft man nft - mankier.com]
* [[Quick reference-nftables in 10 minutes|Quick reference, nftables in 10 minutes]]
* [[Netfilter hooks]] and nftables integration with existing Netfilter components
* [[nftables families|Understanding nftables families]]
* [[Data_types|Data types]]
* [[Connection_Tracking_System|Connection tracking system (conntrack)]], used for stateful firewalling and NAT
* [[Troubleshooting|Troubleshooting and FAQ]]
* [[Further_documentation|Additional documentation]]

= Installing nftables =
* [[nftables from distributions|Using nftables from distributions]]
* [[Building and installing nftables from sources]]

= Upgrading from xtables to nftables =
* [[Legacy xtables tools]]
* [[Moving from iptables to nftables]]
* [[Moving from ipset to nftables]]

= Basic operation =
* [[Configuring tables]]
* [[Configuring chains]]
* [[Simple rule management]]
* [[Atomic rule replacement]]
* [[Error reporting from the command line]]
* [[Building rules through expressions]]
* [[Operations at ruleset level]]
* [[Monitoring ruleset updates]]
* [[Scripting]]
* [[Ruleset debug/tracing]]
* [[Output text modifiers]]

= Expressions: Matching packets =
* [[Matching packet headers]]
* [[Matching packet metainformation]]
* [[Matching connection tracking stateful metainformation]]
* [[Matching routing information]]
* [[Rate limiting matchings]]

= Statements: Acting on packet matches =
* [[Accepting and dropping packets]]
* [[Rejecting traffic]]
* [[Jumping to chain]]
* [[Counters]]
* [[Logging traffic]]
* [[Performing Network Address Translation (NAT)]]
* [[Setting packet metainformation]]
* [[Setting packet connection tracking metainformation]]
* [[Mangling packet headers]] (including stateless NAT)
* [[Duplicating packets]]
* [[Load balancing]]
* [[Queueing to userspace]]

= Advanced data structures for performance packet classification =
* [[Intervals]]
* [[Concatenations]]
* [[Math operations]]
* [[Stateful objects]]
** [[Counters]]
** [[Quotas]]
** [[Limits]]
** [[Connlimits]] (''ct count'')
* Other objects
** [[Conntrack helpers]] (''ct helper'', Layer 7 ALG)
** [[Ct_timeout|Conntrack timeout policies]] (''ct timeout'')
** [[Ct_expectation|Conntrack expectations]] (''ct expectation'')
** [[Synproxy]]
** [[Secmark|Secmarks]]
* Generic set infrastructure
** [[Sets]]
** [[Element timeouts]]
** [[Updating sets from the packet path]]
** [[Maps]]
** [[Verdict_Maps_(vmaps) | Verdict maps]]
** [[Meters|Metering]] (formerly known as flow tables before nftables 0.8.1)
* [[Flowtables]] (the fastpath network stack bypass)

= Examples =
* [[Simple ruleset for a workstation]]
* [[Simple ruleset for a server]]
* [[Bridge filtering]]
* [[Multiple NATs using nftables maps]]
* [[Classic perimetral firewall example]]
* [[Port knocking example]]
* [[Classification to tc structure example]]
* [[Using configuration management systems]] (like puppet, ansible, etc)
* [[GeoIP matching]]

= Development =

Check [[Portal:DeveloperDocs|Portal:DeveloperDocs - documentation for netfilter developers]].

Some hints on the general development progress:

* [[List of updates since Linux kernel 3.13]]
* [[List of updates in the nft command line tool]]
* [[Supported features compared to xtables|Supported features compared to {ip,ip6,eb,arp}tables]]
* [[List of available translations via iptables-translate tool]]

= External links =

Watch some videos:

* Watch [https://www.youtube.com/watch?v=FXTRRwXi3b4 Getting a grasp of nftables], thanks to [https://www.nluug.nl/index-en.html NLUUG association] for recording this.
* Watch [https://www.youtube.com/watch?v=CaYp0d2wiuU#t=1m47s The ultimate packet classifier for GNU/Linux], thanks to the FSFE for paying my trip to Barcelona and for recommending me as speaker to the KDE Spanish branch.
* [https://www.youtube.com/watch?v=Sy0JDX451ns Florian Westphal - Why nftables?]
* Watch [https://www.youtube.com/watch?v=0wQfSfDVN94 NLUUG - Goodbye iptables, Hello nftables]
* Watch [https://www.youtube.com/watch?v=Uf5ULkEWPL0 LCA2018 - nftables from a user perspective]

Watch videos to track updates:

* Watch [https://www.youtube.com/watch?v=qXVOA2MKA1s Netdev 2.1 - Netfilter mini-workshop (2017)]
* Watch [https://youtu.be/iCj10vEKPrw Netdev 2.2 - Netf‌ilter mini-workshop (2018)]
* Watch [https://youtu.be/0hqfzp6tpZo Netdev 0x12 - Netf‌ilter mini-workshop (2019)]
* Watch [https://www.youtube.com/watch?v=GqGGo4svj7s&feature=youtu.be Netdev 0x14 - Netfilter mini-Workshop (2020)]

Additional documentations and articles:

* Tutorial [https://zasdfgbnm.github.io/2017/09/07/Extending-nftables/ Extending nftables by Xiang Gao]
* Article [http://ral-arturo.org/2017/05/05/debian-stretch-stable-nftables.html New in Debian stable Stretch: nftables]
* Article [https://ral-arturo.org/2020/11/22/python-nftables-tutorial.html How to use nftables from python] and git repository [https://github.com/aborrero/python-nftables-tutorial python-nftables-tutorial.git]

= Thanks =

To the NLnet foundation for initial sponsorship of this HOWTO:

[https://nlnet.nl https://nlnet.nl/image/logo.gif]

To Eric Leblond, for boostrapping the [https://home.regit.org/netfilter-en/nftables-quick-howto/ Nftables quick howto] in 2013.

Data types

2021-04-20T15:05:08Z

Fmyhr: Linked ethernet & IP Wikipedia pages, and conntrack page.

= ''nft describe'' =

You can use ''nft describe'' to get information about a data type, to find out the data type of a particular selector, and to list predefined symbolic constants for that selector. Some examples:

<nowiki>% nft describe iif
meta expression, datatype iface_index (network interface index) (basetype integer), 32 bits

% nft describe iifname
meta expression, datatype ifname (network interface name) (basetype string), 16 characters

% nft describe tcp flags
payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits

pre-defined symbolic constants (in hexadecimal):
fin 0x01
syn 0x02
rst 0x04
psh 0x08
ack 0x10
urg 0x20
ecn 0x40
cwr 0x80</nowiki>

= List of data types =

== Date and time types ==

{| class="wikitable"
!colspan="4"|Date and time types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| day
| Day of week of packet reception (8 bit integer, with pre-defined symbolic constants):
* ''Sunday''
* ''Monday''
* ''Tuesday''
* ''Wednesday''
* ''Thursday''
* ''Friday''
* ''Saturday''
| [[Matching_packet_metainformation|''meta day'']]
| ''Sunday'' = 0, ''Saturday'' = 6.
Symbolic constants are case insensitive, and unique abbreviations are accepted: ''Sun'' = ''sun'' = ''Sunday'' = 0.

|- style="vertical-align:top;"
| hour
| Hour of day of packet reception (32 bit integer).
Specify as string in 24-hour format, hh:mm[:ss].
| [[Matching_packet_metainformation|''meta hour'']]
| Seconds are optional: ''17:00'' = ''17:00:00''.

|- style="vertical-align:top;"
| time
| Relative time of packet reception (64 bit integer).
| [[Matching_packet_metainformation |''meta time'']]
| Can be specified as a date in ISO format, i.e. "2019-06-06 17:00". Hour and seconds are optional and can be omitted if desired. If omitted, midnight will be assumed. The following three are equivalent: "2019-06-06" = "2019-06-06 00:00" = "2019-06-06 00:00:00".
When an integer is specified, it is assumed to be a UNIX timestamp.

|}

== Network interface types ==

{| class="wikitable"
!colspan="4"|Network interface types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| devgroup
| Device group (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iifgroup'' | ''oifgroup''}]]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/group.

|- style="vertical-align:top;"
| iface_index
| Interface index (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iif'' | ''oif''}]]
| Can be specified numerically or as name of an existing interface.
Use ifname instead for interfaces whose name and/or index can change (i.e. those that appear / disappear dynamically).

|- style="vertical-align:top;"
| iface_type
| Interface type (16 bit integer, with pre-defined symbolic constants):
* ''ether''
* ''ppp''
* ''ipip''
* ''ipip6''
* ''loopback''
* ''sit''
* ''ipgre''
| [[Matching_packet_metainformation|''meta'' {''iiftype'' | ''oiftype''}]]
|

|- style="vertical-align:top;"
| ifkind
| Interface kind name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifkind'' | ''oifkind''}]]
| dev->rtnl_link_ops->kind
The ''man 8 ip-link'' TYPES section lists valid ifkinds. It's missing at least one: ''tun''.

|- style="vertical-align:top;"
| ifname
| Interface name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifname'' | ''oifname''}]]
| Does not have to exist.
Slower than iface_index but good for interfaces that can dynamically appear / disappear.

|}

== Ethernet types ==

{| class="wikitable"
!colspan="4"|[https://en.wikipedia.org/wiki/Ethernet Ethernet] types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ether_addr
| Ethernet address (48 bit integer).
|
* [[Matching_packet_headers#Matching_ethernet_headers|''ether'' {''saddr'' | ''daddr''}]]
* ''arp'' {''saddr'' | ''daddr''} ''ether''
|

|- style="vertical-align:top;"
| ether_type
| [https://en.wikipedia.org/wiki/EtherType EtherType] (16 bit integer, with pre-defined symbolic constants):
* ''arp''
* ''ip''
* ''ip6''
* ''vlan''
| [[Matching_packet_metainformation|''meta protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_ether.h ether.h] has known types.
NOTE that ether.h lists EtherTypes in [https://en.wikipedia.org/wiki/Endianness#Networking network order], while nft uses little-endian order on x86. (Check output of ''nft describe ether_type''.)

|}

== ARP types ==

{| class="wikitable"
!colspan="4"|[https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP] types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
|
| ARP HLEN, hardware address length in octets (8 bit integer)
| [[Matching_packet_headers#Matching_ARP_headers|''arp hlen'' «HLEN»]]
| Unnamed 8-bit integer in nftables.
For ethernet HLEN = 6.

|- style="vertical-align:top;"
|
| ARP HTYPE, hardware type (16 bit integer)
| [[Matching_packet_headers#Matching_ARP_headers|''arp htype'' «HTYPE»]]
| Unnamed 16-bit integer in nftables.
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_arp.h if_arp.h] has known types.

|- style="vertical-align:top;"
|
| ARP PLEN, internetwork address length in octets (8 bit integer)
| [[Matching_packet_headers#Matching_ARP_headers|''arp plen'' «PLEN»]]
| Unnamed 8-bit integer in nftables.
For IPv4 PLEN = 4.

|- style="vertical-align:top;"
| arp_op
| ARP operation (16 bit integer, with pre-defined symbolic constants):
* ''request'' = 1
* ''reply'' = 2
* ''rrequest'' = 3
* ''rreply'' = 4
* ''inrequest'' = 8
* ''inreply'' = 9
* ''nak'' = 10
| [[Matching_packet_headers#Matching_ARP_headers|''arp operation'' «arp_op»]]
|

|}

== IP types ==

{| class="wikitable"
!colspan="4"|[https://en.wikipedia.org/wiki/Internet_Protocol IP] types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| inet_proto
| Internet protocol (8 bit integer, with pre-defined symbolic constants):
* ''tcp''
* ''udp''
* ''udplite''
* ''esp''
* ''ah''
* ''icmp''
* ''icmpv6''
* ''comp''
* ''dccp''
* ''sctp''
|
* [[Matching_packet_headers#Matching_transport_protocol|''ip protocol'']]
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6 nexthdr'']]
* ''ah nexthdr''
* ''comp nexthdr''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/in.h in.h] has known types.

|- style="vertical-align:top;"
| inet_service
| Network service port number (16 bit integer).
|
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''tcp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udplite'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''sctp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''dccp'' {''sport'' | ''dport''}]]
|

|- style="vertical-align:top;"
| ipv4_addr
| IPv4 address (32 bit integer).
|
* [[Matching_packet_headers#Matching_IPv4_headers|''ip'' {''saddr'' | ''daddr''} ]]
* ''arp'' {''saddr'' | ''daddr''} ''ip''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip'' {''saddr'' | ''daddr''}
|

|- style="vertical-align:top;"
| ipv6_addr
| IPv6 address (128 bit integer).
|
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6'' {''saddr'' | ''daddr''} ]]
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip6'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip6 nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip6'' {''saddr'' | ''daddr''}
|

|}

== Conntrack types ==

{| class="wikitable"
!colspan="4"|[[Connection_Tracking_System|Conntrack]] types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ct_dir
| Conntrack direction (8 bit integer).
|
| Symbolic constants:
<pre>
original 0
reply 1
</pre>

|- style="vertical-align:top;"
| ct_event
| Conntrack event bits (4 byte bitmask).
|
| Symbolic constants:
<pre>
new 1
related 2
destroy 4
reply 8
assured 16
protoinfo 32
helper 64
mark 128
seqadj 256
secmark 512
label 1024
</pre>

|- style="vertical-align:top;"
| ct_label
| Conntrack label (128 bit bitmask).
|
|

|- style="vertical-align:top;"
| ct_state
| Conntrack state (4 byte bitmask).
|
| Symbolic constants:
<pre>
invalid 1
established 2
related 4
new 8
untracked 64
</pre>

|- style="vertical-align:top;"
| ct_status
| Conntrack status (4 byte bitmask).
|
| Symbolic constants:
<pre>
expected 1
seen-reply 2
assured 4
confirmed 8
snat 16
dnat 32
dying 512
</pre>

|}

== Other types ==

{| class="wikitable"
!colspan="4"|Other types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| gid
| Group ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skgid'']]
| Can be specified numerically or as group name.

|- style="vertical-align:top;"
| mark
| Packet mark (32 bit integer).
|
* [[Matching_packet_metainformation#Matching_by_packet_mark.2C_routing_class_and_realm|''meta mark'']]
* ''socket mark''
* [[Matching routing information|''fib mark . ''{''saddr'' | ''daddr'' | ''iif'' | ''oif''} [. ...] {''oif'' | ''oifname'' | ''type''}]]
* [[Matching_connection_tracking_stateful_metainformation|''ct mark'']]
|

|- style="vertical-align:top;"
| pkt_type
| Packet type (8 bit integer, with pre-defined symbolic constants):
* ''host'' or ''unicast'' - addressed to local host
* ''broadcast'' - to all
* ''multicast'' - to group
* ''other'' - addressed to another host
| [[Matching_packet_metainformation |''meta pkttype'']]
|

|- style="vertical-align:top;"
| realm
| Routing Realm (32 bit integer).
| [[Matching_packet_metainformation |''meta rtclassid'']]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/rt_realms.
Routing realm references:
<ul>
<li>[http://linux-ip.net/gl/ip-cref/ip-cref-node172.html linux-ip.net]
<li>[http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH07.web.html policyrouting.org]
</ul>

|- style="vertical-align:top;"
| uid
| User ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skuid'']]
| Can be specified numerically or as user name.

|}

Data types

2021-04-20T15:00:19Z

Fmyhr: ARP types: added example expression links and Wikipedia protocol link.

= ''nft describe'' =

You can use ''nft describe'' to get information about a data type, to find out the data type of a particular selector, and to list predefined symbolic constants for that selector. Some examples:

<nowiki>% nft describe iif
meta expression, datatype iface_index (network interface index) (basetype integer), 32 bits

% nft describe iifname
meta expression, datatype ifname (network interface name) (basetype string), 16 characters

% nft describe tcp flags
payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits

pre-defined symbolic constants (in hexadecimal):
fin 0x01
syn 0x02
rst 0x04
psh 0x08
ack 0x10
urg 0x20
ecn 0x40
cwr 0x80</nowiki>

= List of data types =

== Date and time types ==

{| class="wikitable"
!colspan="4"|Date and time types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| day
| Day of week of packet reception (8 bit integer, with pre-defined symbolic constants):
* ''Sunday''
* ''Monday''
* ''Tuesday''
* ''Wednesday''
* ''Thursday''
* ''Friday''
* ''Saturday''
| [[Matching_packet_metainformation|''meta day'']]
| ''Sunday'' = 0, ''Saturday'' = 6.
Symbolic constants are case insensitive, and unique abbreviations are accepted: ''Sun'' = ''sun'' = ''Sunday'' = 0.

|- style="vertical-align:top;"
| hour
| Hour of day of packet reception (32 bit integer).
Specify as string in 24-hour format, hh:mm[:ss].
| [[Matching_packet_metainformation|''meta hour'']]
| Seconds are optional: ''17:00'' = ''17:00:00''.

|- style="vertical-align:top;"
| time
| Relative time of packet reception (64 bit integer).
| [[Matching_packet_metainformation |''meta time'']]
| Can be specified as a date in ISO format, i.e. "2019-06-06 17:00". Hour and seconds are optional and can be omitted if desired. If omitted, midnight will be assumed. The following three are equivalent: "2019-06-06" = "2019-06-06 00:00" = "2019-06-06 00:00:00".
When an integer is specified, it is assumed to be a UNIX timestamp.

|}

== Network interface types ==

{| class="wikitable"
!colspan="4"|Network interface types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| devgroup
| Device group (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iifgroup'' | ''oifgroup''}]]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/group.

|- style="vertical-align:top;"
| iface_index
| Interface index (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iif'' | ''oif''}]]
| Can be specified numerically or as name of an existing interface.
Use ifname instead for interfaces whose name and/or index can change (i.e. those that appear / disappear dynamically).

|- style="vertical-align:top;"
| iface_type
| Interface type (16 bit integer, with pre-defined symbolic constants):
* ''ether''
* ''ppp''
* ''ipip''
* ''ipip6''
* ''loopback''
* ''sit''
* ''ipgre''
| [[Matching_packet_metainformation|''meta'' {''iiftype'' | ''oiftype''}]]
|

|- style="vertical-align:top;"
| ifkind
| Interface kind name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifkind'' | ''oifkind''}]]
| dev->rtnl_link_ops->kind
The ''man 8 ip-link'' TYPES section lists valid ifkinds. It's missing at least one: ''tun''.

|- style="vertical-align:top;"
| ifname
| Interface name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifname'' | ''oifname''}]]
| Does not have to exist.
Slower than iface_index but good for interfaces that can dynamically appear / disappear.

|}

== Ethernet types ==

{| class="wikitable"
!colspan="4"|Ethernet types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ether_addr
| Ethernet address (48 bit integer).
|
* [[Matching_packet_headers#Matching_ethernet_headers|''ether'' {''saddr'' | ''daddr''}]]
* ''arp'' {''saddr'' | ''daddr''} ''ether''
|

|- style="vertical-align:top;"
| ether_type
| [https://en.wikipedia.org/wiki/EtherType EtherType] (16 bit integer, with pre-defined symbolic constants):
* ''arp''
* ''ip''
* ''ip6''
* ''vlan''
| [[Matching_packet_metainformation|''meta protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_ether.h ether.h] has known types.
NOTE that ether.h lists EtherTypes in [https://en.wikipedia.org/wiki/Endianness#Networking network order], while nft uses little-endian order on x86. (Check output of ''nft describe ether_type''.)

|}

== ARP types ==

{| class="wikitable"
!colspan="4"|[https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP] types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
|
| ARP HLEN, hardware address length in octets (8 bit integer)
| [[Matching_packet_headers#Matching_ARP_headers|''arp hlen'' «HLEN»]]
| Unnamed 8-bit integer in nftables.
For ethernet HLEN = 6.

|- style="vertical-align:top;"
|
| ARP HTYPE, hardware type (16 bit integer)
| [[Matching_packet_headers#Matching_ARP_headers|''arp htype'' «HTYPE»]]
| Unnamed 16-bit integer in nftables.
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_arp.h if_arp.h] has known types.

|- style="vertical-align:top;"
|
| ARP PLEN, internetwork address length in octets (8 bit integer)
| [[Matching_packet_headers#Matching_ARP_headers|''arp plen'' «PLEN»]]
| Unnamed 8-bit integer in nftables.
For IPv4 PLEN = 4.

|- style="vertical-align:top;"
| arp_op
| ARP operation (16 bit integer, with pre-defined symbolic constants):
* ''request'' = 1
* ''reply'' = 2
* ''rrequest'' = 3
* ''rreply'' = 4
* ''inrequest'' = 8
* ''inreply'' = 9
* ''nak'' = 10
| [[Matching_packet_headers#Matching_ARP_headers|''arp operation'' «arp_op»]]
|

|}

== IP types ==

{| class="wikitable"
!colspan="4"|IP types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| inet_proto
| Internet protocol (8 bit integer, with pre-defined symbolic constants):
* ''tcp''
* ''udp''
* ''udplite''
* ''esp''
* ''ah''
* ''icmp''
* ''icmpv6''
* ''comp''
* ''dccp''
* ''sctp''
|
* [[Matching_packet_headers#Matching_transport_protocol|''ip protocol'']]
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6 nexthdr'']]
* ''ah nexthdr''
* ''comp nexthdr''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/in.h in.h] has known types.

|- style="vertical-align:top;"
| inet_service
| Network service port number (16 bit integer).
|
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''tcp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udplite'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''sctp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''dccp'' {''sport'' | ''dport''}]]
|

|- style="vertical-align:top;"
| ipv4_addr
| IPv4 address (32 bit integer).
|
* [[Matching_packet_headers#Matching_IPv4_headers|''ip'' {''saddr'' | ''daddr''} ]]
* ''arp'' {''saddr'' | ''daddr''} ''ip''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip'' {''saddr'' | ''daddr''}
|

|- style="vertical-align:top;"
| ipv6_addr
| IPv6 address (128 bit integer).
|
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6'' {''saddr'' | ''daddr''} ]]
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip6'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip6 nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip6'' {''saddr'' | ''daddr''}
|

|}

== Conntrack types ==

{| class="wikitable"
!colspan="4"|Conntrack types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ct_dir
| Conntrack direction (8 bit integer).
|
| Symbolic constants:
<pre>
original 0
reply 1
</pre>

|- style="vertical-align:top;"
| ct_event
| Conntrack event bits (4 byte bitmask).
|
| Symbolic constants:
<pre>
new 1
related 2
destroy 4
reply 8
assured 16
protoinfo 32
helper 64
mark 128
seqadj 256
secmark 512
label 1024
</pre>

|- style="vertical-align:top;"
| ct_label
| Conntrack label (128 bit bitmask).
|
|

|- style="vertical-align:top;"
| ct_state
| Conntrack state (4 byte bitmask).
|
| Symbolic constants:
<pre>
invalid 1
established 2
related 4
new 8
untracked 64
</pre>

|- style="vertical-align:top;"
| ct_status
| Conntrack status (4 byte bitmask).
|
| Symbolic constants:
<pre>
expected 1
seen-reply 2
assured 4
confirmed 8
snat 16
dnat 32
dying 512
</pre>

|}

== Other types ==

{| class="wikitable"
!colspan="4"|Other types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| gid
| Group ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skgid'']]
| Can be specified numerically or as group name.

|- style="vertical-align:top;"
| mark
| Packet mark (32 bit integer).
|
* [[Matching_packet_metainformation#Matching_by_packet_mark.2C_routing_class_and_realm|''meta mark'']]
* ''socket mark''
* [[Matching routing information|''fib mark . ''{''saddr'' | ''daddr'' | ''iif'' | ''oif''} [. ...] {''oif'' | ''oifname'' | ''type''}]]
* [[Matching_connection_tracking_stateful_metainformation|''ct mark'']]
|

|- style="vertical-align:top;"
| pkt_type
| Packet type (8 bit integer, with pre-defined symbolic constants):
* ''host'' or ''unicast'' - addressed to local host
* ''broadcast'' - to all
* ''multicast'' - to group
* ''other'' - addressed to another host
| [[Matching_packet_metainformation |''meta pkttype'']]
|

|- style="vertical-align:top;"
| realm
| Routing Realm (32 bit integer).
| [[Matching_packet_metainformation |''meta rtclassid'']]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/rt_realms.
Routing realm references:
<ul>
<li>[http://linux-ip.net/gl/ip-cref/ip-cref-node172.html linux-ip.net]
<li>[http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH07.web.html policyrouting.org]
</ul>

|- style="vertical-align:top;"
| uid
| User ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skuid'']]
| Can be specified numerically or as user name.

|}

Matching packet headers

2021-04-20T14:55:09Z

Fmyhr: Matching ARP headers: added brief descriptions.

The ''nft'' command line utility supports the following layer 4 protocols: AH, ESP, UDP, UDPlite, TCP, DCCP, SCTP and IPComp.

= Matching ethernet headers =

You can match packets on [https://en.wikipedia.org/wiki/Ethernet ethernet] source or destination address or on [https://en.wikipedia.org/wiki/EtherType EtherType]:
* ''ether'' {''saddr'' | ''daddr''} «[[Data_types#Ethernet_types|ether_addr]]»
* ''ether type'' «[[Data_types#Ethernet_types|ether_type]]»

If you want to match ethernet traffic whose destination address is ff:ff:ff:ff:ff:ff, you can type the following command:

<source lang="bash">
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
</source>

You can also match packets on [https://en.wikipedia.org/wiki/IEEE_802.1Q IEEE 802.1Q] VLAN fields, if present:
* ''vlan type'' «[[Data_types#Ethernet_types|ether_type]]» - always ''vlan'' for 802.1Q
* ''vlan id'' «12-bit integer» - match VID, the VLAN ID
* ''vlan cfi'' «1-bit integer» - match DEI, Drop Eligible Indicator (formerly CFI, Canonical Format Indicator)
* ''vlan pcp'' «3-bit integer» - match [https://en.wikipedia.org/wiki/IEEE_P802.1p IEEE P802.1p PCP, Priority Code Point]

Do not forget that the [https://en.wikipedia.org/wiki/Link_layer layer 2] header information is only available in the input path.

= Matching ARP headers =

You can match [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP] headers:
* ''arp htype'' «[[Data_types#ARP_types|16-bit integer HTYPE]]» - match hardware link protocol type (1 for ethernet)
* ''arp ptype'' «[[Data_types#Ethernet_types|ether_type]]» - match EtherType
* ''arp hlen'' «[[Data_types#ARP_types|8-bit integer HLEN]]» - match hardware address length in octets (6 for ethernet)
* ''arp plen'' «[[Data_types#ARP_types|8-bit integer PLEN]]» - match internetwork protocol address length in octets (4 for IPv4)
* ''arp operation'' «[[Data_types#ARP_types|arp_op]]» - match ARP operation
* ''arp'' {''saddr'' | ''daddr ''} ''ether'' «[[Data_types#Ethernet_types|ether_addr]]» - ''saddr'' matches SHA, Sender Hardware Address; ''daddr'' matches THA, Target Hardware Address
* ''arp'' {''saddr'' | ''daddr ''} ''ip'' «[[Data_types#IP_types|ipv4_addr]]» - ''saddr'' matches SPA, Sender Protocol Address; ''daddr'' matches TPA, Target Protocol Address

= Matching IPv4 headers =

You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:

<source lang="bash">
% nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter
</source>

Note that, since the rule is attached to the input chain, your local machine needs to use the 192.168.1.1 address, otherwise you won't see any matching ;-).

To filter on a layer 4 protocol like TCP, you can use the ''protocol'' keyword:
<source lang="bash">
% nft add rule filter input protocol tcp counter
</source>

= Matching ICMP traffic =

You can drop all [https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] echo requests (popularly known as ''pings'') via:

<source lang="bash">
% nft add rule filter input icmp type echo-request counter drop
</source>

You can use ''nft describe'' to find ''nft'''s available ''icmp type'' keywords:
<source lang="bash">
% nft describe icmp type
payload expression, datatype icmp_type (ICMP type) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
echo-reply 0
destination-unreachable 3
source-quench 4
redirect 5
echo-request 8
router-advertisement 9
router-solicitation 10
time-exceeded 11
parameter-problem 12
timestamp-request 13
timestamp-reply 14
info-request 15
info-reply 16
address-mask-request 17
address-mask-reply 18
</source>

You can also be more specific by matching a single icmp code:
<source lang="bash">
% nft describe icmp code
payload expression, datatype icmp_code (icmp code) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
net-unreachable 0
host-unreachable 1
prot-unreachable 2
port-unreachable 3
net-prohibited 9
host-prohibited 10
admin-prohibited 13
frag-needed 4

% nft add rule filter output icmp code frag-needed counter accept
</source>

= Matching IPv6 headers =

If you want to account IPv6 traffic that is addressed to ''abcd::100'', you can type the following command:

<source lang="bash">
% nft add rule filter output ip6 daddr abcd::100 counter
</source>

To filter on a layer 4 protocol like TCP, you can use the ''nexthdr'' keyword:

<source lang="bash">
% nft add rule filter input ip6 nexthdr tcp counter
</source>

Do not forget to create an ''ip6'' [[Configuring tables|table]] and register the corresponding [[Configuring chains|chains]] to run the examples.

NOTE: the syntax mixing IPv6/IPv4 notation is not supported yet: '::ffff:192.168.1.0'

= Matching transport protocol =

The following rule shows how to match any kind of ''TCP'' traffic:

<source lang="bash">
% nft add rule filter output ip protocol tcp
</source>

= Matching TCP/UDP/UDPlite traffic =

The following examples show how to drop all tcp traffic for low TCP ports (1-1024):

<source lang="bash">
% nft add rule filter input tcp dport 1-1024 counter drop
</source>

Note that this rule is using an [[intervals|interval]] (from 1 to 1024).

To match on TCP flags, you need to use a binary operation. For example, to count packets that are not SYN ones:

<source lang="bash">
% nft add rule filter input tcp flags != syn counter
</source>

More complex filters can be used. For example, to count and log TCP packets with flags SYN and ACK set:

<source lang="bash">
% nft -i
nft> add rule filter output tcp flags & (syn | ack) == syn | ack counter log
</source>

This example drops TCP SYN packets which a MSS lower than 500:

<source lang="bash">
% nft add rule inet filter input tcp flags syn tcp option maxseg size 1-500 drop
</source>

= Matching UDP/TCP headers in the same rule =

The following example uses an anonymous l4proto [[Sets|set]] and a ''th'' (transport header) expression to match both TCP and UDP packets directed to port 53 (DNS):

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } th dport 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Note: Before nftables 0.9.2 and Linux kernel 5.3 the ''th'' expression is not available. In this case you can use a raw payload expression to do the same job:

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } @th,16,16 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Matching packet headers

2021-04-20T14:34:05Z

Fmyhr: Reordered sections, moving up network layers and matching man page.

The ''nft'' command line utility supports the following layer 4 protocols: AH, ESP, UDP, UDPlite, TCP, DCCP, SCTP and IPComp.

= Matching ethernet headers =

You can match packets on [https://en.wikipedia.org/wiki/Ethernet ethernet] source or destination address or on [https://en.wikipedia.org/wiki/EtherType EtherType]:
* ''ether'' {''saddr'' | ''daddr''} «[[Data_types#Ethernet_types|ether_addr]]»
* ''ether type'' «[[Data_types#Ethernet_types|ether_type]]»

If you want to match ethernet traffic whose destination address is ff:ff:ff:ff:ff:ff, you can type the following command:

<source lang="bash">
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
</source>

You can also match packets on [https://en.wikipedia.org/wiki/IEEE_802.1Q IEEE 802.1Q] VLAN fields, if present:
* ''vlan type'' «[[Data_types#Ethernet_types|ether_type]]» - always ''vlan'' for 802.1Q
* ''vlan id'' «12-bit integer» - match VID, the VLAN ID
* ''vlan cfi'' «1-bit integer» - match DEI, Drop Eligible Indicator (formerly CFI, Canonical Format Indicator)
* ''vlan pcp'' «3-bit integer» - match [https://en.wikipedia.org/wiki/IEEE_P802.1p IEEE P802.1p PCP, Priority Code Point]

Do not forget that the [https://en.wikipedia.org/wiki/Link_layer layer 2] header information is only available in the input path.

= Matching ARP headers =

You can match [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP] headers:
* ''arp htype'' «[[Data_types#ARP_types|16-bit integer HTYPE]]»
* ''arp ptype'' «[[Data_types#Ethernet_types|ether_type]]»
* ''arp hlen'' «[[Data_types#ARP_types|8-bit integer HLEN]]»
* ''arp plen'' «[[Data_types#ARP_types|8-bit integer PLEN]]»
* ''arp operation'' «[[Data_types#ARP_types|arp_op]]»
* ''arp'' {''saddr'' | ''daddr ''} ''ether'' «[[Data_types#Ethernet_types|ether_addr]]»
* ''arp'' {''saddr'' | ''daddr ''} ''ip'' «[[Data_types#IP_types|ipv4_addr]]»

= Matching IPv4 headers =

You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:

<source lang="bash">
% nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter
</source>

Note that, since the rule is attached to the input chain, your local machine needs to use the 192.168.1.1 address, otherwise you won't see any matching ;-).

To filter on a layer 4 protocol like TCP, you can use the ''protocol'' keyword:
<source lang="bash">
% nft add rule filter input protocol tcp counter
</source>

= Matching ICMP traffic =

You can drop all [https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] echo requests (popularly known as ''pings'') via:

<source lang="bash">
% nft add rule filter input icmp type echo-request counter drop
</source>

You can use ''nft describe'' to find ''nft'''s available ''icmp type'' keywords:
<source lang="bash">
% nft describe icmp type
payload expression, datatype icmp_type (ICMP type) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
echo-reply 0
destination-unreachable 3
source-quench 4
redirect 5
echo-request 8
router-advertisement 9
router-solicitation 10
time-exceeded 11
parameter-problem 12
timestamp-request 13
timestamp-reply 14
info-request 15
info-reply 16
address-mask-request 17
address-mask-reply 18
</source>

You can also be more specific by matching a single icmp code:
<source lang="bash">
% nft describe icmp code
payload expression, datatype icmp_code (icmp code) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
net-unreachable 0
host-unreachable 1
prot-unreachable 2
port-unreachable 3
net-prohibited 9
host-prohibited 10
admin-prohibited 13
frag-needed 4

% nft add rule filter output icmp code frag-needed counter accept
</source>

= Matching IPv6 headers =

If you want to account IPv6 traffic that is addressed to ''abcd::100'', you can type the following command:

<source lang="bash">
% nft add rule filter output ip6 daddr abcd::100 counter
</source>

To filter on a layer 4 protocol like TCP, you can use the ''nexthdr'' keyword:

<source lang="bash">
% nft add rule filter input ip6 nexthdr tcp counter
</source>

Do not forget to create an ''ip6'' [[Configuring tables|table]] and register the corresponding [[Configuring chains|chains]] to run the examples.

NOTE: the syntax mixing IPv6/IPv4 notation is not supported yet: '::ffff:192.168.1.0'

= Matching transport protocol =

The following rule shows how to match any kind of ''TCP'' traffic:

<source lang="bash">
% nft add rule filter output ip protocol tcp
</source>

= Matching TCP/UDP/UDPlite traffic =

The following examples show how to drop all tcp traffic for low TCP ports (1-1024):

<source lang="bash">
% nft add rule filter input tcp dport 1-1024 counter drop
</source>

Note that this rule is using an [[intervals|interval]] (from 1 to 1024).

To match on TCP flags, you need to use a binary operation. For example, to count packets that are not SYN ones:

<source lang="bash">
% nft add rule filter input tcp flags != syn counter
</source>

More complex filters can be used. For example, to count and log TCP packets with flags SYN and ACK set:

<source lang="bash">
% nft -i
nft> add rule filter output tcp flags & (syn | ack) == syn | ack counter log
</source>

This example drops TCP SYN packets which a MSS lower than 500:

<source lang="bash">
% nft add rule inet filter input tcp flags syn tcp option maxseg size 1-500 drop
</source>

= Matching UDP/TCP headers in the same rule =

The following example uses an anonymous l4proto [[Sets|set]] and a ''th'' (transport header) expression to match both TCP and UDP packets directed to port 53 (DNS):

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } th dport 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Note: Before nftables 0.9.2 and Linux kernel 5.3 the ''th'' expression is not available. In this case you can use a raw payload expression to do the same job:

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } @th,16,16 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Matching packet headers

2021-04-20T14:28:04Z

Fmyhr: Added section: Matching ARP headers

The ''nft'' command line utility supports the following layer 4 protocols: AH, ESP, UDP, UDPlite, TCP, DCCP, SCTP and IPComp.

= Matching ethernet headers =

You can match packets on [https://en.wikipedia.org/wiki/Ethernet ethernet] source or destination address or on [https://en.wikipedia.org/wiki/EtherType EtherType]:
* ''ether'' {''saddr'' | ''daddr''} «[[Data_types#Ethernet_types|ether_addr]]»
* ''ether type'' «[[Data_types#Ethernet_types|ether_type]]»

If you want to match ethernet traffic whose destination address is ff:ff:ff:ff:ff:ff, you can type the following command:

<source lang="bash">
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
</source>

You can also match packets on [https://en.wikipedia.org/wiki/IEEE_802.1Q IEEE 802.1Q] VLAN fields, if present:
* ''vlan type'' «[[Data_types#Ethernet_types|ether_type]]» - always ''vlan'' for 802.1Q
* ''vlan id'' «12-bit integer» - match VID, the VLAN ID
* ''vlan cfi'' «1-bit integer» - match DEI, Drop Eligible Indicator (formerly CFI, Canonical Format Indicator)
* ''vlan pcp'' «3-bit integer» - match [https://en.wikipedia.org/wiki/IEEE_P802.1p IEEE P802.1p PCP, Priority Code Point]

Do not forget that the [https://en.wikipedia.org/wiki/Link_layer layer 2] header information is only available in the input path.

= Matching ARP headers =

You can match [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP] headers:
* ''arp htype'' «[[Data_types#ARP_types|16-bit integer HTYPE]]»
* ''arp ptype'' «[[Data_types#Ethernet_types|ether_type]]»
* ''arp hlen'' «[[Data_types#ARP_types|8-bit integer HLEN]]»
* ''arp plen'' «[[Data_types#ARP_types|8-bit integer PLEN]]»
* ''arp operation'' «[[Data_types#ARP_types|arp_op]]»
* ''arp'' {''saddr'' | ''daddr ''} ''ether'' «[[Data_types#Ethernet_types|ether_addr]]»
* ''arp'' {''saddr'' | ''daddr ''} ''ip'' «[[Data_types#IP_types|ipv4_addr]]»

= Matching transport protocol =

The following rule shows how to match any kind of ''TCP'' traffic:

<source lang="bash">
% nft add rule filter output ip protocol tcp
</source>

= Matching IPv4 headers =

You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:

<source lang="bash">
% nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter
</source>

Note that, since the rule is attached to the input chain, your local machine needs to use the 192.168.1.1 address, otherwise you won't see any matching ;-).

To filter on a layer 4 protocol like TCP, you can use the ''protocol'' keyword:
<source lang="bash">
% nft add rule filter input protocol tcp counter
</source>

= Matching IPv6 headers =

If you want to account IPv6 traffic that is addressed to ''abcd::100'', you can type the following command:

<source lang="bash">
% nft add rule filter output ip6 daddr abcd::100 counter
</source>

To filter on a layer 4 protocol like TCP, you can use the ''nexthdr'' keyword:

<source lang="bash">
% nft add rule filter input ip6 nexthdr tcp counter
</source>

Do not forget to create an ''ip6'' [[Configuring tables|table]] and register the corresponding [[Configuring chains|chains]] to run the examples.

NOTE: the syntax mixing IPv6/IPv4 notation is not supported yet: '::ffff:192.168.1.0'

= Matching TCP/UDP/UDPlite traffic =

The following examples show how to drop all tcp traffic for low TCP ports (1-1024):

<source lang="bash">
% nft add rule filter input tcp dport 1-1024 counter drop
</source>

Note that this rule is using an [[intervals|interval]] (from 1 to 1024).

To match on TCP flags, you need to use a binary operation. For example, to count packets that are not SYN ones:

<source lang="bash">
% nft add rule filter input tcp flags != syn counter
</source>

More complex filters can be used. For example, to count and log TCP packets with flags SYN and ACK set:

<source lang="bash">
% nft -i
nft> add rule filter output tcp flags & (syn | ack) == syn | ack counter log
</source>

This example drops TCP SYN packets which a MSS lower than 500:

<source lang="bash">
% nft add rule inet filter input tcp flags syn tcp option maxseg size 1-500 drop
</source>

= Matching ICMP traffic =

You can drop all [https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] echo requests (popularly known as ''pings'') via:

<source lang="bash">
% nft add rule filter input icmp type echo-request counter drop
</source>

You can use ''nft describe'' to find ''nft'''s available ''icmp type'' keywords:
<source lang="bash">
% nft describe icmp type
payload expression, datatype icmp_type (ICMP type) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
echo-reply 0
destination-unreachable 3
source-quench 4
redirect 5
echo-request 8
router-advertisement 9
router-solicitation 10
time-exceeded 11
parameter-problem 12
timestamp-request 13
timestamp-reply 14
info-request 15
info-reply 16
address-mask-request 17
address-mask-reply 18
</source>

You can also be more specific by matching a single icmp code:
<source lang="bash">
% nft describe icmp code
payload expression, datatype icmp_code (icmp code) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
net-unreachable 0
host-unreachable 1
prot-unreachable 2
port-unreachable 3
net-prohibited 9
host-prohibited 10
admin-prohibited 13
frag-needed 4

% nft add rule filter output icmp code frag-needed counter accept
</source>

= Matching UDP/TCP headers in the same rule =

The following example uses an anonymous l4proto [[Sets|set]] and a ''th'' (transport header) expression to match both TCP and UDP packets directed to port 53 (DNS):

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } th dport 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Note: Before nftables 0.9.2 and Linux kernel 5.3 the ''th'' expression is not available. In this case you can use a raw payload expression to do the same job:

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } @th,16,16 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Data types

2021-04-20T14:27:24Z

Fmyhr: ARP types: added descriptions of some unnamed types.

= ''nft describe'' =

You can use ''nft describe'' to get information about a data type, to find out the data type of a particular selector, and to list predefined symbolic constants for that selector. Some examples:

<nowiki>% nft describe iif
meta expression, datatype iface_index (network interface index) (basetype integer), 32 bits

% nft describe iifname
meta expression, datatype ifname (network interface name) (basetype string), 16 characters

% nft describe tcp flags
payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits

pre-defined symbolic constants (in hexadecimal):
fin 0x01
syn 0x02
rst 0x04
psh 0x08
ack 0x10
urg 0x20
ecn 0x40
cwr 0x80</nowiki>

= List of data types =

== Date and time types ==

{| class="wikitable"
!colspan="4"|Date and time types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| day
| Day of week of packet reception (8 bit integer, with pre-defined symbolic constants):
* ''Sunday''
* ''Monday''
* ''Tuesday''
* ''Wednesday''
* ''Thursday''
* ''Friday''
* ''Saturday''
| [[Matching_packet_metainformation|''meta day'']]
| ''Sunday'' = 0, ''Saturday'' = 6.
Symbolic constants are case insensitive, and unique abbreviations are accepted: ''Sun'' = ''sun'' = ''Sunday'' = 0.

|- style="vertical-align:top;"
| hour
| Hour of day of packet reception (32 bit integer).
Specify as string in 24-hour format, hh:mm[:ss].
| [[Matching_packet_metainformation|''meta hour'']]
| Seconds are optional: ''17:00'' = ''17:00:00''.

|- style="vertical-align:top;"
| time
| Relative time of packet reception (64 bit integer).
| [[Matching_packet_metainformation |''meta time'']]
| Can be specified as a date in ISO format, i.e. "2019-06-06 17:00". Hour and seconds are optional and can be omitted if desired. If omitted, midnight will be assumed. The following three are equivalent: "2019-06-06" = "2019-06-06 00:00" = "2019-06-06 00:00:00".
When an integer is specified, it is assumed to be a UNIX timestamp.

|}

== Network interface types ==

{| class="wikitable"
!colspan="4"|Network interface types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| devgroup
| Device group (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iifgroup'' | ''oifgroup''}]]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/group.

|- style="vertical-align:top;"
| iface_index
| Interface index (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iif'' | ''oif''}]]
| Can be specified numerically or as name of an existing interface.
Use ifname instead for interfaces whose name and/or index can change (i.e. those that appear / disappear dynamically).

|- style="vertical-align:top;"
| iface_type
| Interface type (16 bit integer, with pre-defined symbolic constants):
* ''ether''
* ''ppp''
* ''ipip''
* ''ipip6''
* ''loopback''
* ''sit''
* ''ipgre''
| [[Matching_packet_metainformation|''meta'' {''iiftype'' | ''oiftype''}]]
|

|- style="vertical-align:top;"
| ifkind
| Interface kind name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifkind'' | ''oifkind''}]]
| dev->rtnl_link_ops->kind
The ''man 8 ip-link'' TYPES section lists valid ifkinds. It's missing at least one: ''tun''.

|- style="vertical-align:top;"
| ifname
| Interface name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifname'' | ''oifname''}]]
| Does not have to exist.
Slower than iface_index but good for interfaces that can dynamically appear / disappear.

|}

== Ethernet types ==

{| class="wikitable"
!colspan="4"|Ethernet types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ether_addr
| Ethernet address (48 bit integer).
|
* [[Matching_packet_headers#Matching_ethernet_headers|''ether'' {''saddr'' | ''daddr''}]]
* ''arp'' {''saddr'' | ''daddr''} ''ether''
|

|- style="vertical-align:top;"
| ether_type
| [https://en.wikipedia.org/wiki/EtherType EtherType] (16 bit integer, with pre-defined symbolic constants):
* ''arp''
* ''ip''
* ''ip6''
* ''vlan''
| [[Matching_packet_metainformation|''meta protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_ether.h ether.h] has known types.
NOTE that ether.h lists EtherTypes in [https://en.wikipedia.org/wiki/Endianness#Networking network order], while nft uses little-endian order on x86. (Check output of ''nft describe ether_type''.)

|}

== ARP types ==

{| class="wikitable"
!colspan="4"|ARP types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
|
| ARP HLEN, hardware address length in octets (8 bit integer)
| ''arp hlen'' «HLEN»
| Unnamed 8-bit integer in nftables.
For ethernet HLEN = 6.

|- style="vertical-align:top;"
|
| ARP HTYPE, hardware type (16 bit integer)
| ''arp htype'' «HTYPE»
| Unnamed 16-bit integer in nftables.
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_arp.h if_arp.h] has known types.

|- style="vertical-align:top;"
|
| ARP PLEN, internetwork address length in octets (8 bit integer)
| ''arp plen'' «PLEN»
| Unnamed 8-bit integer in nftables.
For IPv4 PLEN = 4.

|- style="vertical-align:top;"
| arp_op
| ARP operation (16 bit integer, with pre-defined symbolic constants):
* ''request'' = 1
* ''reply'' = 2
* ''rrequest'' = 3
* ''rreply'' = 4
* ''inrequest'' = 8
* ''inreply'' = 9
* ''nak'' = 10
| ''arp operation'' «arp_op»
|

|}

== IP types ==

{| class="wikitable"
!colspan="4"|IP types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| inet_proto
| Internet protocol (8 bit integer, with pre-defined symbolic constants):
* ''tcp''
* ''udp''
* ''udplite''
* ''esp''
* ''ah''
* ''icmp''
* ''icmpv6''
* ''comp''
* ''dccp''
* ''sctp''
|
* [[Matching_packet_headers#Matching_transport_protocol|''ip protocol'']]
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6 nexthdr'']]
* ''ah nexthdr''
* ''comp nexthdr''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/in.h in.h] has known types.

|- style="vertical-align:top;"
| inet_service
| Network service port number (16 bit integer).
|
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''tcp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udplite'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''sctp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''dccp'' {''sport'' | ''dport''}]]
|

|- style="vertical-align:top;"
| ipv4_addr
| IPv4 address (32 bit integer).
|
* [[Matching_packet_headers#Matching_IPv4_headers|''ip'' {''saddr'' | ''daddr''} ]]
* ''arp'' {''saddr'' | ''daddr''} ''ip''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip'' {''saddr'' | ''daddr''}
|

|- style="vertical-align:top;"
| ipv6_addr
| IPv6 address (128 bit integer).
|
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6'' {''saddr'' | ''daddr''} ]]
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip6'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip6 nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip6'' {''saddr'' | ''daddr''}
|

|}

== Conntrack types ==

{| class="wikitable"
!colspan="4"|Conntrack types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ct_dir
| Conntrack direction (8 bit integer).
|
| Symbolic constants:
<pre>
original 0
reply 1
</pre>

|- style="vertical-align:top;"
| ct_event
| Conntrack event bits (4 byte bitmask).
|
| Symbolic constants:
<pre>
new 1
related 2
destroy 4
reply 8
assured 16
protoinfo 32
helper 64
mark 128
seqadj 256
secmark 512
label 1024
</pre>

|- style="vertical-align:top;"
| ct_label
| Conntrack label (128 bit bitmask).
|
|

|- style="vertical-align:top;"
| ct_state
| Conntrack state (4 byte bitmask).
|
| Symbolic constants:
<pre>
invalid 1
established 2
related 4
new 8
untracked 64
</pre>

|- style="vertical-align:top;"
| ct_status
| Conntrack status (4 byte bitmask).
|
| Symbolic constants:
<pre>
expected 1
seen-reply 2
assured 4
confirmed 8
snat 16
dnat 32
dying 512
</pre>

|}

== Other types ==

{| class="wikitable"
!colspan="4"|Other types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| gid
| Group ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skgid'']]
| Can be specified numerically or as group name.

|- style="vertical-align:top;"
| mark
| Packet mark (32 bit integer).
|
* [[Matching_packet_metainformation#Matching_by_packet_mark.2C_routing_class_and_realm|''meta mark'']]
* ''socket mark''
* [[Matching routing information|''fib mark . ''{''saddr'' | ''daddr'' | ''iif'' | ''oif''} [. ...] {''oif'' | ''oifname'' | ''type''}]]
* [[Matching_connection_tracking_stateful_metainformation|''ct mark'']]
|

|- style="vertical-align:top;"
| pkt_type
| Packet type (8 bit integer, with pre-defined symbolic constants):
* ''host'' or ''unicast'' - addressed to local host
* ''broadcast'' - to all
* ''multicast'' - to group
* ''other'' - addressed to another host
| [[Matching_packet_metainformation |''meta pkttype'']]
|

|- style="vertical-align:top;"
| realm
| Routing Realm (32 bit integer).
| [[Matching_packet_metainformation |''meta rtclassid'']]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/rt_realms.
Routing realm references:
<ul>
<li>[http://linux-ip.net/gl/ip-cref/ip-cref-node172.html linux-ip.net]
<li>[http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH07.web.html policyrouting.org]
</ul>

|- style="vertical-align:top;"
| uid
| User ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skuid'']]
| Can be specified numerically or as user name.

|}

Data types

2021-04-20T13:59:17Z

Fmyhr: Added ARP types.

= ''nft describe'' =

You can use ''nft describe'' to get information about a data type, to find out the data type of a particular selector, and to list predefined symbolic constants for that selector. Some examples:

<nowiki>% nft describe iif
meta expression, datatype iface_index (network interface index) (basetype integer), 32 bits

% nft describe iifname
meta expression, datatype ifname (network interface name) (basetype string), 16 characters

% nft describe tcp flags
payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits

pre-defined symbolic constants (in hexadecimal):
fin 0x01
syn 0x02
rst 0x04
psh 0x08
ack 0x10
urg 0x20
ecn 0x40
cwr 0x80</nowiki>

= List of data types =

== Date and time types ==

{| class="wikitable"
!colspan="4"|Date and time types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| day
| Day of week of packet reception (8 bit integer, with pre-defined symbolic constants):
* ''Sunday''
* ''Monday''
* ''Tuesday''
* ''Wednesday''
* ''Thursday''
* ''Friday''
* ''Saturday''
| [[Matching_packet_metainformation|''meta day'']]
| ''Sunday'' = 0, ''Saturday'' = 6.
Symbolic constants are case insensitive, and unique abbreviations are accepted: ''Sun'' = ''sun'' = ''Sunday'' = 0.

|- style="vertical-align:top;"
| hour
| Hour of day of packet reception (32 bit integer).
Specify as string in 24-hour format, hh:mm[:ss].
| [[Matching_packet_metainformation|''meta hour'']]
| Seconds are optional: ''17:00'' = ''17:00:00''.

|- style="vertical-align:top;"
| time
| Relative time of packet reception (64 bit integer).
| [[Matching_packet_metainformation |''meta time'']]
| Can be specified as a date in ISO format, i.e. "2019-06-06 17:00". Hour and seconds are optional and can be omitted if desired. If omitted, midnight will be assumed. The following three are equivalent: "2019-06-06" = "2019-06-06 00:00" = "2019-06-06 00:00:00".
When an integer is specified, it is assumed to be a UNIX timestamp.

|}

== Network interface types ==

{| class="wikitable"
!colspan="4"|Network interface types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| devgroup
| Device group (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iifgroup'' | ''oifgroup''}]]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/group.

|- style="vertical-align:top;"
| iface_index
| Interface index (32 bit integer).
| [[Matching_packet_metainformation|''meta'' {''iif'' | ''oif''}]]
| Can be specified numerically or as name of an existing interface.
Use ifname instead for interfaces whose name and/or index can change (i.e. those that appear / disappear dynamically).

|- style="vertical-align:top;"
| iface_type
| Interface type (16 bit integer, with pre-defined symbolic constants):
* ''ether''
* ''ppp''
* ''ipip''
* ''ipip6''
* ''loopback''
* ''sit''
* ''ipgre''
| [[Matching_packet_metainformation|''meta'' {''iiftype'' | ''oiftype''}]]
|

|- style="vertical-align:top;"
| ifkind
| Interface kind name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifkind'' | ''oifkind''}]]
| dev->rtnl_link_ops->kind
The ''man 8 ip-link'' TYPES section lists valid ifkinds. It's missing at least one: ''tun''.

|- style="vertical-align:top;"
| ifname
| Interface name (16 byte string).
| [[Matching_packet_metainformation|''meta'' {''iifname'' | ''oifname''}]]
| Does not have to exist.
Slower than iface_index but good for interfaces that can dynamically appear / disappear.

|}

== Ethernet types ==

{| class="wikitable"
!colspan="4"|Ethernet types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ether_addr
| Ethernet address (48 bit integer).
|
* [[Matching_packet_headers#Matching_ethernet_headers|''ether'' {''saddr'' | ''daddr''}]]
* ''arp'' {''saddr'' | ''daddr''} ''ether''
|

|- style="vertical-align:top;"
| ether_type
| [https://en.wikipedia.org/wiki/EtherType EtherType] (16 bit integer, with pre-defined symbolic constants):
* ''arp''
* ''ip''
* ''ip6''
* ''vlan''
| [[Matching_packet_metainformation|''meta protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/if_ether.h ether.h] has known types.
NOTE that ether.h lists EtherTypes in [https://en.wikipedia.org/wiki/Endianness#Networking network order], while nft uses little-endian order on x86. (Check output of ''nft describe ether_type''.)

|}

== ARP types ==

{| class="wikitable"
!colspan="4"|ARP types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| arp_op
| ARP operation (16 bit integer, with pre-defined symbolic constants):
* ''request'' = 1
* ''reply'' = 2
* ''rrequest'' = 3
* ''rreply'' = 4
* ''inrequest'' = 8
* ''inreply'' = 9
* ''nak'' = 10
| ''arp operation'' «arp_op»
|

|}

== IP types ==

{| class="wikitable"
!colspan="4"|IP types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| inet_proto
| Internet protocol (8 bit integer, with pre-defined symbolic constants):
* ''tcp''
* ''udp''
* ''udplite''
* ''esp''
* ''ah''
* ''icmp''
* ''icmpv6''
* ''comp''
* ''dccp''
* ''sctp''
|
* [[Matching_packet_headers#Matching_transport_protocol|''ip protocol'']]
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6 nexthdr'']]
* ''ah nexthdr''
* ''comp nexthdr''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''protocol'']]
| [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/in.h in.h] has known types.

|- style="vertical-align:top;"
| inet_service
| Network service port number (16 bit integer).
|
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''tcp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''udplite'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''sctp'' {''sport'' | ''dport''}]]
* [[Matching_packet_headers#Matching_TCP.2FUDP.2FUDPlite_traffic|''dccp'' {''sport'' | ''dport''}]]
|

|- style="vertical-align:top;"
| ipv4_addr
| IPv4 address (32 bit integer).
|
* [[Matching_packet_headers#Matching_IPv4_headers|''ip'' {''saddr'' | ''daddr''} ]]
* ''arp'' {''saddr'' | ''daddr''} ''ip''
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip'' {''saddr'' | ''daddr''}
|

|- style="vertical-align:top;"
| ipv6_addr
| IPv6 address (128 bit integer).
|
* [[Matching_packet_headers#Matching_IPv6_headers|''ip6'' {''saddr'' | ''daddr''} ]]
* [[Matching_connection_tracking_stateful_metainformation|''ct'' {''original'' | ''reply''} ''ip6'' {''saddr'' | ''daddr''}]]
* [[Matching routing information|''rt ip6 nexthop'']]
* ''ipsec'' {''in'' | ''out''} ''ip6'' {''saddr'' | ''daddr''}
|

|}

== Conntrack types ==

{| class="wikitable"
!colspan="4"|Conntrack types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| ct_dir
| Conntrack direction (8 bit integer).
|
| Symbolic constants:
<pre>
original 0
reply 1
</pre>

|- style="vertical-align:top;"
| ct_event
| Conntrack event bits (4 byte bitmask).
|
| Symbolic constants:
<pre>
new 1
related 2
destroy 4
reply 8
assured 16
protoinfo 32
helper 64
mark 128
seqadj 256
secmark 512
label 1024
</pre>

|- style="vertical-align:top;"
| ct_label
| Conntrack label (128 bit bitmask).
|
|

|- style="vertical-align:top;"
| ct_state
| Conntrack state (4 byte bitmask).
|
| Symbolic constants:
<pre>
invalid 1
established 2
related 4
new 8
untracked 64
</pre>

|- style="vertical-align:top;"
| ct_status
| Conntrack status (4 byte bitmask).
|
| Symbolic constants:
<pre>
expected 1
seen-reply 2
assured 4
confirmed 8
snat 16
dnat 32
dying 512
</pre>

|}

== Other types ==

{| class="wikitable"
!colspan="4"|Other types
|- style="vertical-align:bottom;"
! Data Type
! style="text-align:left;" | Description
! style="text-align:left;" | Expressions
! style="text-align:left;" | Notes

|- style="vertical-align:top;"
| gid
| Group ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skgid'']]
| Can be specified numerically or as group name.

|- style="vertical-align:top;"
| mark
| Packet mark (32 bit integer).
|
* [[Matching_packet_metainformation#Matching_by_packet_mark.2C_routing_class_and_realm|''meta mark'']]
* ''socket mark''
* [[Matching routing information|''fib mark . ''{''saddr'' | ''daddr'' | ''iif'' | ''oif''} [. ...] {''oif'' | ''oifname'' | ''type''}]]
* [[Matching_connection_tracking_stateful_metainformation|''ct mark'']]
|

|- style="vertical-align:top;"
| pkt_type
| Packet type (8 bit integer, with pre-defined symbolic constants):
* ''host'' or ''unicast'' - addressed to local host
* ''broadcast'' - to all
* ''multicast'' - to group
* ''other'' - addressed to another host
| [[Matching_packet_metainformation |''meta pkttype'']]
|

|- style="vertical-align:top;"
| realm
| Routing Realm (32 bit integer).
| [[Matching_packet_metainformation |''meta rtclassid'']]
| Can be specified numerically or as symbolic name defined in /etc/iproute2/rt_realms.
Routing realm references:
<ul>
<li>[http://linux-ip.net/gl/ip-cref/ip-cref-node172.html linux-ip.net]
<li>[http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH07.web.html policyrouting.org]
</ul>

|- style="vertical-align:top;"
| uid
| User ID (32 bit integer).
| [[Matching_packet_metainformation |''meta skuid'']]
| Can be specified numerically or as user name.

|}

Matching packet headers

2021-04-20T12:29:09Z

Fmyhr: Link references to ethernet, EtherType, L2.

The ''nft'' command line utility supports the following layer 4 protocols: AH, ESP, UDP, UDPlite, TCP, DCCP, SCTP and IPComp.

= Matching ethernet headers =

You can match packets on [https://en.wikipedia.org/wiki/Ethernet ethernet] source or destination address or on [https://en.wikipedia.org/wiki/EtherType EtherType]:
* ''ether'' {''saddr'' | ''daddr''} «[[Data_types#Ethernet_types|ether_addr]]»
* ''ether type'' «[[Data_types#Ethernet_types|ether_type]]»

If you want to match ethernet traffic whose destination address is ff:ff:ff:ff:ff:ff, you can type the following command:

<source lang="bash">
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
</source>

You can also match packets on [https://en.wikipedia.org/wiki/IEEE_802.1Q IEEE 802.1Q] VLAN fields, if present:
* ''vlan type'' «[[Data_types#Ethernet_types|ether_type]]» - always ''vlan'' for 802.1Q
* ''vlan id'' «12-bit integer» - match VID, the VLAN ID
* ''vlan cfi'' «1-bit integer» - match DEI, Drop Eligible Indicator (formerly CFI, Canonical Format Indicator)
* ''vlan pcp'' «3-bit integer» - match [https://en.wikipedia.org/wiki/IEEE_P802.1p IEEE P802.1p PCP, Priority Code Point]

Do not forget that the [https://en.wikipedia.org/wiki/Link_layer layer 2] header information is only available in the input path.

= Matching transport protocol =

The following rule shows how to match any kind of ''TCP'' traffic:

<source lang="bash">
% nft add rule filter output ip protocol tcp
</source>

= Matching IPv4 headers =

You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:

<source lang="bash">
% nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter
</source>

Note that, since the rule is attached to the input chain, your local machine needs to use the 192.168.1.1 address, otherwise you won't see any matching ;-).

To filter on a layer 4 protocol like TCP, you can use the ''protocol'' keyword:
<source lang="bash">
% nft add rule filter input protocol tcp counter
</source>

= Matching IPv6 headers =

If you want to account IPv6 traffic that is addressed to ''abcd::100'', you can type the following command:

<source lang="bash">
% nft add rule filter output ip6 daddr abcd::100 counter
</source>

To filter on a layer 4 protocol like TCP, you can use the ''nexthdr'' keyword:

<source lang="bash">
% nft add rule filter input ip6 nexthdr tcp counter
</source>

Do not forget to create an ''ip6'' [[Configuring tables|table]] and register the corresponding [[Configuring chains|chains]] to run the examples.

NOTE: the syntax mixing IPv6/IPv4 notation is not supported yet: '::ffff:192.168.1.0'

= Matching TCP/UDP/UDPlite traffic =

The following examples show how to drop all tcp traffic for low TCP ports (1-1024):

<source lang="bash">
% nft add rule filter input tcp dport 1-1024 counter drop
</source>

Note that this rule is using an [[intervals|interval]] (from 1 to 1024).

To match on TCP flags, you need to use a binary operation. For example, to count packets that are not SYN ones:

<source lang="bash">
% nft add rule filter input tcp flags != syn counter
</source>

More complex filters can be used. For example, to count and log TCP packets with flags SYN and ACK set:

<source lang="bash">
% nft -i
nft> add rule filter output tcp flags & (syn | ack) == syn | ack counter log
</source>

This example drops TCP SYN packets which a MSS lower than 500:

<source lang="bash">
% nft add rule inet filter input tcp flags syn tcp option maxseg size 1-500 drop
</source>

= Matching ICMP traffic =

You can drop all [https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] echo requests (popularly known as ''pings'') via:

<source lang="bash">
% nft add rule filter input icmp type echo-request counter drop
</source>

You can use ''nft describe'' to find ''nft'''s available ''icmp type'' keywords:
<source lang="bash">
% nft describe icmp type
payload expression, datatype icmp_type (ICMP type) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
echo-reply 0
destination-unreachable 3
source-quench 4
redirect 5
echo-request 8
router-advertisement 9
router-solicitation 10
time-exceeded 11
parameter-problem 12
timestamp-request 13
timestamp-reply 14
info-request 15
info-reply 16
address-mask-request 17
address-mask-reply 18
</source>

You can also be more specific by matching a single icmp code:
<source lang="bash">
% nft describe icmp code
payload expression, datatype icmp_code (icmp code) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
net-unreachable 0
host-unreachable 1
prot-unreachable 2
port-unreachable 3
net-prohibited 9
host-prohibited 10
admin-prohibited 13
frag-needed 4

% nft add rule filter output icmp code frag-needed counter accept
</source>

= Matching UDP/TCP headers in the same rule =

The following example uses an anonymous l4proto [[Sets|set]] and a ''th'' (transport header) expression to match both TCP and UDP packets directed to port 53 (DNS):

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } th dport 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Note: Before nftables 0.9.2 and Linux kernel 5.3 the ''th'' expression is not available. In this case you can use a raw payload expression to do the same job:

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } @th,16,16 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Matching packet headers

2021-04-20T12:21:00Z

Fmyhr: Use left and right angle quotes for literals.

The ''nft'' command line utility supports the following layer 4 protocols: AH, ESP, UDP, UDPlite, TCP, DCCP, SCTP and IPComp.

= Matching ethernet headers =

You can match packets on ethernet source or destination address or on EtherType:
* ''ether'' {''saddr'' | ''daddr''} «[[Data_types#Ethernet_types|ether_addr]]»
* ''ether type'' «[[Data_types#Ethernet_types|ether_type]]»

If you want to match ethernet traffic whose destination address is ff:ff:ff:ff:ff:ff, you can type the following command:

<source lang="bash">
% nft add rule filter input ether daddr ff:ff:ff:ff:ff:ff counter
</source>

You can also match packets on [https://en.wikipedia.org/wiki/IEEE_802.1Q IEEE 802.1Q] VLAN fields, if present:
* ''vlan type'' «[[Data_types#Ethernet_types|ether_type]]» - always ''vlan'' for 802.1Q
* ''vlan id'' «12-bit integer» - match VID, the VLAN ID
* ''vlan cfi'' «1-bit integer» - match DEI, Drop Eligible Indicator (formerly CFI, Canonical Format Indicator)
* ''vlan pcp'' «3-bit integer» - match [https://en.wikipedia.org/wiki/IEEE_P802.1p IEEE P802.1p PCP, Priority Code Point]

Do not forget that the layer 2 header information is only available in the input path.

= Matching transport protocol =

The following rule shows how to match any kind of ''TCP'' traffic:

<source lang="bash">
% nft add rule filter output ip protocol tcp
</source>

= Matching IPv4 headers =

You can also match traffic based on the IPv4 source and destination, the following example shows how to account all traffic that comes from 192.168.1.100 and that is addressed to 192.168.1.1:

<source lang="bash">
% nft add rule filter input ip saddr 192.168.1.100 ip daddr 192.168.1.1 counter
</source>

Note that, since the rule is attached to the input chain, your local machine needs to use the 192.168.1.1 address, otherwise you won't see any matching ;-).

To filter on a layer 4 protocol like TCP, you can use the ''protocol'' keyword:
<source lang="bash">
% nft add rule filter input protocol tcp counter
</source>

= Matching IPv6 headers =

If you want to account IPv6 traffic that is addressed to ''abcd::100'', you can type the following command:

<source lang="bash">
% nft add rule filter output ip6 daddr abcd::100 counter
</source>

To filter on a layer 4 protocol like TCP, you can use the ''nexthdr'' keyword:

<source lang="bash">
% nft add rule filter input ip6 nexthdr tcp counter
</source>

Do not forget to create an ''ip6'' [[Configuring tables|table]] and register the corresponding [[Configuring chains|chains]] to run the examples.

NOTE: the syntax mixing IPv6/IPv4 notation is not supported yet: '::ffff:192.168.1.0'

= Matching TCP/UDP/UDPlite traffic =

The following examples show how to drop all tcp traffic for low TCP ports (1-1024):

<source lang="bash">
% nft add rule filter input tcp dport 1-1024 counter drop
</source>

Note that this rule is using an [[intervals|interval]] (from 1 to 1024).

To match on TCP flags, you need to use a binary operation. For example, to count packets that are not SYN ones:

<source lang="bash">
% nft add rule filter input tcp flags != syn counter
</source>

More complex filters can be used. For example, to count and log TCP packets with flags SYN and ACK set:

<source lang="bash">
% nft -i
nft> add rule filter output tcp flags & (syn | ack) == syn | ack counter log
</source>

This example drops TCP SYN packets which a MSS lower than 500:

<source lang="bash">
% nft add rule inet filter input tcp flags syn tcp option maxseg size 1-500 drop
</source>

= Matching ICMP traffic =

You can drop all [https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] echo requests (popularly known as ''pings'') via:

<source lang="bash">
% nft add rule filter input icmp type echo-request counter drop
</source>

You can use ''nft describe'' to find ''nft'''s available ''icmp type'' keywords:
<source lang="bash">
% nft describe icmp type
payload expression, datatype icmp_type (ICMP type) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
echo-reply 0
destination-unreachable 3
source-quench 4
redirect 5
echo-request 8
router-advertisement 9
router-solicitation 10
time-exceeded 11
parameter-problem 12
timestamp-request 13
timestamp-reply 14
info-request 15
info-reply 16
address-mask-request 17
address-mask-reply 18
</source>

You can also be more specific by matching a single icmp code:
<source lang="bash">
% nft describe icmp code
payload expression, datatype icmp_code (icmp code) (basetype integer), 8 bits

pre-defined symbolic constants (in decimal):
net-unreachable 0
host-unreachable 1
prot-unreachable 2
port-unreachable 3
net-prohibited 9
host-prohibited 10
admin-prohibited 13
frag-needed 4

% nft add rule filter output icmp code frag-needed counter accept
</source>

= Matching UDP/TCP headers in the same rule =

The following example uses an anonymous l4proto [[Sets|set]] and a ''th'' (transport header) expression to match both TCP and UDP packets directed to port 53 (DNS):

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } th dport 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Note: Before nftables 0.9.2 and Linux kernel 5.3 the ''th'' expression is not available. In this case you can use a raw payload expression to do the same job:

<source lang="bash">
% nft add rule filter input meta l4proto { tcp, udp } @th,16,16 53 counter packets 0 bytes 0 accept comment \"accept DNS\"
</source>

Maps

2021-04-20T01:49:59Z

Fmyhr: Use "snat to" and "dnat to".

An nftables map stores key-value pairs, like [https://en.wikipedia.org/wiki/Associative_array associative arrays / dictionaries / hashes] do in many programming languages. In an nftables rule you can specify a packet field (e.g. ''tcp dport'') and reference a map to search for the map element whose key matches the packet field's value, and return that map element's value (or failure if the map contains no matching element). Some examples below will help clarify this general description.

You can think of a map as a [[Sets|set]] that returns a value instead of just an "in set / not in set" result. Behind the scenes both sets and maps use the same generic set infrastructure and therefore share many of the same options and semantics.

= Anonymous maps =

The following rule uses a map to [[Performing_Network_Address_Translation_(NAT)|DNAT]] packets to different destination IP addresses depending on the packet's destination tcp port:

<source lang="bash">
% nft add rule ip nat prerouting dnat to tcp dport map { 80 : 192.168.1.100, 8888 : 192.168.1.101 }
</source>

This is a very concise and efficient way to perform classical port redirection when the real servers are located behind a firewall. It can be read as it follows:

* If the TCP destination port is 80, then the packet is DNAT'ed to 192.168.1.100.
* If the TCP destination port is 8888, then the packet is DNAT'ed to 192.168.1.101.

= Named maps =

You can also declare named maps, to which you can then add or delete elements at anytime. For example, with:

<source lang="bash">
% nft add map nat porttoip { type inet_service: ipv4_addr\; }
% nft add element nat porttoip { 80 : 192.168.1.100, 8888 : 192.168.1.101 }
</source>

we first define a map ''porttoip'' which looks up an IP address based on a UDP or TCP port number, and then add a couple of elements. The map itself only cares about the [[Data_types|data types]] of its keys and values. It is up to us to use meaningful values for both, and to use the map appropriately in rules. In this example we use ''porttoip'' to map tcp destination ports to source IP addresses. Then we can perform [[Performing_Network_Address_Translation_(NAT)|SNAT]] using the rule:

<source lang="bash">
% nft add rule ip nat postrouting snat to tcp dport map @porttoip
</source>

Now outgoing packets to TCP/80 use source IP address 192.168.1.100, those to TCP/8888 are SNAT'ed to 192.168.1.101. We can easily adjust our SNAT at anytime simply by adding or deleting elements in ''porttoip''.

Concatenations

2021-04-20T01:48:36Z

Fmyhr: Use "dnat to".

Since Linux kernel 4.1, nftables supports concatenations.

This new feature allows you to put two or more selectors together to perform very fast lookups in [[sets]], [[maps]], [[Verdict_Maps_(vmaps) | vmaps]] and [[meters]].

= Anonymous sets =

<source lang="bash">
% nft add rule ip filter input ip saddr . ip daddr . ip protocol { 1.1.1.1 . 2.2.2.2 . tcp, 1.1.1.1 . 3.3.3.3 . udp} counter accept
</source>

So if the packet's source IP address AND destination IP address AND level 4 protocol match:

* 1.1.1.1 and 2.2.2.2 and TCP.

or

* 1.1.1.1 and 3.3.3.3 and UDP.

nftables updates the counter for this rule and then accepts the packet.

= Named verdict maps =

The following example creates the ''whitelist'' vmap using a concatenation of two selectors:

<source lang="bash">
% nft add map filter whitelist { type ipv4_addr . inet_service : verdict \; }
</source>

Once you create the vmap, you can use it from a rule that creates the following concatenation:

<source lang="bash">
% nft add rule filter input ip saddr . tcp dport vmap @whitelist
</source>

The rule above looks up a verdict based on the source IP address AND the TCP destination port.

The verdict map is initially empty. You can dynamically populate it with elements:

<source lang="bash">
% nft add element filter whitelist { 1.2.3.4 . 22 : accept}
</source>

When declaring concatenations, you can use [[Sets | generic sets options]], such as the '''typeof''' keyword and the '''counter''' feature:

<source lang="bash">
table inet fmytable {
set myset {
typeof ip daddr . tcp dport
counter
elements = { 1.1.1.4 . 22 counter packets 0 bytes 0,
1.1.1.5 . 23 counter packets 0 bytes 0,
1.1.1.6 . 24 counter packets 0 bytes 0 }
}
}
</source>

= Anonymous maps =

The rule below determines the destination IP address that is used to perform DNAT to the packet based on:

* the source IP address

AND

* the destination TCP port

<source lang="bash">
% nft add rule ip nat prerouting dnat to ip saddr . tcp dport map { 1.1.1.1 . 80 : 192.168.1.100, 2.2.2.2 . 8888 : 192.168.1.101 }
</source>

= Examples =

Some concrete example concatenations so you get an idea on how powerful this new feature is.

== Network addresses ==

The example below implements a vmap using network masks in each element:

<source lang="bash">
table inet mytable {
set myset {
type ipv4_addr . ipv4_addr
flags interval
elements = { 192.168.0.0/16 . 172.16.0.0/25,
10.0.0.0/30 . 192.168.1.0/24,
}
}

chain mychain {
ip saddr . ip daddr @myset counter accept
}
}
</source>

'''NOTE''': before Linux kernel 5.6 and nftables 0.9.4 the CIDR notation wasn't available, you would need to use a workaround:

<source lang="bash">
% nft add rule tablename chainname ip saddr and 255.255.255.0 . ip daddr and 255.255.255.0 vmap { 10.10.10.0 . 10.10.20.0 : accept }
</source>

Note that this is not an interval, this is masking the ip saddr and ip daddr, then concate both results. This concatenation is used to lookup for a matching of this the result in the map. This syntax may be compacted in future releases to support CIDR notation.

This could be easily implemented using a named map as well:

<source lang="bash">
% nft add map tablename myMap { type ipv4_addr . ipv4_addr : verdict \; }
% nft add rule tablename chainname ip saddr and 255.255.255.0 . ip saddr and 255.255.255.0 vmap @myMap
% nft add element tablename myMap { 10.10.10.0 . 10.10.20.0 : accept }
</source>

== Interfaces ==

The example below checks both input and output interfaces of a forwarded packet.

<source lang="bash">
% nft add rule tablename chainname iif . oif vmap { eth0 . eth1 : accept }
</source>

== Some ipset types ==

These ipset types can be implemented in nftables using concatenations. Probably more equivalences exists, it just a matter of combining data types.
Of course, you could implement these as named maps/sets as well.

See examples in the [[Moving_from_ipset_to_nftables | moving from ipset to nftables]] page.

Multiple NATs using nftables maps

2021-04-20T01:45:49Z

Fmyhr: "{snat|dnat} <ip_addr>" -> "{snat|dnat} to <ip_addr>}"

Thanks to nftables [[Maps]], if you have a previous iptables NAT (destination NAT) ruleset like this:

<source lang="bash">
% iptables -t nat -A PREROUTING -p tcp --dport 1000 -j DNAT --to-destination 1.1.1.1:1234
% iptables -t nat -A PREROUTING -p udp --dport 2000 -j DNAT --to-destination 2.2.2.2:2345
% iptables -t nat -A PREROUTING -p tcp --dport 3000 -j DNAT --to-destination 3.3.3.3:3456
</source>

It can be easily translated to nftables in a single line:

<source lang="bash">
% nft add rule nat prerouting dnat to \
tcp dport map { 1000 : 1.1.1.1, 2000 : 2.2.2.2, 3000 : 3.3.3.3} \
: tcp dport map { 1000 : 1234, 2000 : 2345, 3000 : 3456 }
</source>

Likewise, in iptables NAT (source NAT):

<source lang="bash">
% iptables -t nat -A POSTROUTING -s 192.168.1.1 -j SNAT --to-source 1.1.1.1
% iptables -t nat -A POSTROUTING -s 192.168.2.2 -j SNAT --to-source 2.2.2.2
% iptables -t nat -A POSTROUTING -s 192.168.3.3 -j SNAT --to-source 3.3.3.3
</source>

Translated to a nftables one-liner:

<source lang="bash">
% nft add rule nat postrouting snat to \
ip saddr map { 192.168.1.1 : 1.1.1.1, 192.168.2.2 : 2.2.2.2, 192.168.3.3 : 3.3.3.3 }
</source>

== See also ==

* [[Performing_Network_Address_Translation_(NAT) | Performing NAT with nftables]]

Quick reference-nftables in 10 minutes

2021-04-20T01:34:09Z

Fmyhr: /* Nat */ Missed a couple of "to"'s.

Find below some basic concepts to know before using nftables.

'''table''' refers to a container of [[Configuring chains|chains]] with no specific semantics.

'''chain''' within a [[Configuring tables|table]] refers to a container of [[Simple rule management|rules]].

'''rule''' refers to an action to be configured within a ''chain''.

= nft command line =

''nft'' is the command line tool in order to interact with nftables at userspace.

== Tables ==

'''family''' refers to a one of the following table types: ''ip'', ''arp'', ''ip6'', ''bridge'', ''inet'', ''netdev''.

<source lang="bash">
% nft list tables [<family>]
% nft list table [<family>] <name> [-n] [-a]
% nft (add | delete | flush) table [<family>] <name>
</source>

The argument ''-n'' shows the addresses and other information that uses names in numeric format. The ''-a'' argument is used to display the ''handle''.

== Chains ==

'''type''' refers to the kind of chain to be created. Possible types are:

* ''filter'': Supported by ''arp'', ''bridge'', ''ip'', ''ip6'' and ''inet'' table families.
* ''route'': Mark packets (like mangle for the ''output'' hook, for other hooks use the type ''filter'' instead), supported by ''ip'' and ''ip6''.
* ''nat'': In order to perform Network Address Translation, supported by ''ip'' and ''ip6''.

'''hook''' refers to an specific stage of the packet while it's being processed through the kernel. More info in [[Netfilter_hooks|Netfilter hooks]].

* The hooks for ''ip'', ''ip6'' and ''inet'' families are: ''prerouting'', ''input'', ''forward'', ''output'', ''postrouting''.
* The hooks for ''arp'' family are: '' input'', ''output''.
* The ''bridge'' family handles ethernet packets traversing bridge devices.
* The hook for ''netdev'' is: ''ingress''.

'''priority''' refers to a number used to order the chains or to set them between some Netfilter operations. Possible values are: ''NF_IP_PRI_CONNTRACK_DEFRAG (-400)'', ''NF_IP_PRI_RAW (-300)'', ''NF_IP_PRI_SELINUX_FIRST (-225)'', ''NF_IP_PRI_CONNTRACK (-200)'', ''NF_IP_PRI_MANGLE (-150)'', ''NF_IP_PRI_NAT_DST (-100)'', ''NF_IP_PRI_FILTER (0)'', ''NF_IP_PRI_SECURITY (50)'', ''NF_IP_PRI_NAT_SRC (100)'', ''NF_IP_PRI_SELINUX_LAST (225)'', ''NF_IP_PRI_CONNTRACK_HELPER (300)''.

'''policy''' is the default verdict statement to control the flow in the chain. Possible values are: ''accept'', ''drop'', ''queue'', ''continue'', ''return''.

<source lang="bash">
% nft (add | create) chain [<family>] <table> <name> [ { type <type> hook <hook> [device <device>] priority <priority> \; [policy <policy> \;] } ]
% nft (delete | list | flush) chain [<family>] <table> <name>
% nft rename chain [<family>] <table> <name> <newname>
</source>

== Rules ==

'''handle''' is an internal number that identifies a certain ''rule''.

'''position''' is an internal number that is used to insert a ''rule'' before a certain ''handle''.

<source lang="bash">
% nft add rule [<family>] <table> <chain> <matches> <statements>
% nft insert rule [<family>] <table> <chain> [position <position>] <matches> <statements>
% nft replace rule [<family>] <table> <chain> [handle <handle>] <matches> <statements>
% nft delete rule [<family>] <table> <chain> [handle <handle>]
</source>

=== Matches ===

'''matches''' are clues used to access to certain packet information and create filters according to them.

==== Ip ====

{| class="wikitable"
!colspan="6"|ip match
|-
| | ''dscp <value>''
|
|<source lang="bash">
ip dscp cs1
ip dscp != cs1
ip dscp 0x38
ip dscp != 0x20
ip dscp {cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, af11, af12, af13, af21,
af22, af23, af31, af32, af33, af41, af42, af43, ef}
</source>
|-
| ''length <length>''
| Total packet length
|<source lang="bash">
ip length 232
ip length != 233
ip length 333-435
ip length != 333-453
ip length { 333, 553, 673, 838}
</source>
|-
| ''id <id>''
| IP ID
|<source lang="bash">
ip id 22
ip id != 233
ip id 33-45
ip id != 33-45
ip id { 33, 55, 67, 88 }
</source>
|-
| ''frag-off <value>''
| Fragmentation offset
|<source lang="bash">
ip frag-off 222
ip frag-off != 233
ip frag-off 33-45
ip frag-off != 33-45
ip frag-off { 33, 55, 67, 88 }
</source>
|-
| ''ttl <ttl>''
| Time to live
|<source lang="bash">
ip ttl 0
ip ttl 233
ip ttl 33-55
ip ttl != 45-50
ip ttl { 43, 53, 45 }
ip ttl { 33-55 }
</source>
|-
| ''protocol <protocol>''
| Upper layer protocol
|<source lang="bash">
ip protocol tcp
ip protocol 6
ip protocol != tcp
ip protocol { icmp, esp, ah, comp, udp, udplite, tcp, dccp, sctp }
</source>
|-
| ''checksum <checksum>''
| IP header checksum
|<source lang="bash">
ip checksum 13172
ip checksum 22
ip checksum != 233
ip checksum 33-45
ip checksum != 33-45
ip checksum { 33, 55, 67, 88 }
ip checksum { 33-55 }
</source>
|-
| ''saddr <ip source address>''
| Source address
|<source lang="bash">
ip saddr 192.168.2.0/24
ip saddr != 192.168.2.0/24
ip saddr 192.168.3.1 ip daddr 192.168.3.100
ip saddr != 1.1.1.1
ip saddr 1.1.1.1
ip saddr & 0xff == 1
ip saddr & 0.0.0.255 < 0.0.0.127
</source>
|-
| ''daddr <ip destination address>''
| Destination address
|<source lang="bash">
ip daddr 192.168.0.1
ip daddr != 192.168.0.1
ip daddr 192.168.0.1-192.168.0.250
ip daddr 10.0.0.0-10.255.255.255
ip daddr 172.16.0.0-172.31.255.255
ip daddr 192.168.3.1-192.168.4.250
ip daddr != 192.168.0.1-192.168.0.250
ip daddr { 192.168.0.1-192.168.0.250 }
ip daddr { 192.168.5.1, 192.168.5.2, 192.168.5.3 }
</source>
|-
| ''version <version>''
| Ip Header version
|<source lang="bash">
ip version 4
</source>
|-
| ''hdrlength <header length>''
| IP header length
|<source lang="bash">
ip hdrlength 0
ip hdrlength 15
</source>
|}

==== Ip6 ====

{| class="wikitable"
!colspan="6"|ip6 match
|-
| ''dscp <value>''
|
|<source lang="bash">
ip6 dscp cs1
ip6 dscp != cs1
ip6 dscp 0x38
ip6 dscp != 0x20
ip6 dscp {cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, ef}
</source>
|-
| ''flowlabel <label>''
| Flow label
|<source lang="bash">
ip6 flowlabel 22
ip6 flowlabel != 233
ip6 flowlabel { 33, 55, 67, 88 }
ip6 flowlabel { 33-55 }
</source>
|-
| ''length <length>''
| Payload length
|<source lang="bash">
ip6 length 232
ip6 length != 233
ip6 length 333-435
ip6 length != 333-453
ip6 length { 333, 553, 673, 838}
</source>
|-
| ''nexthdr <header>''
| Next header type (Upper layer protocol number)
|<source lang="bash">
ip6 nexthdr {esp, udp, ah, comp, udplite, tcp, dccp, sctp, icmpv6}
ip6 nexthdr esp
ip6 nexthdr != esp
ip6 nexthdr { 33-44 }
ip6 nexthdr 33-44
ip6 nexthdr != 33-44
</source>
|-
| ''hoplimit <hoplimit>''
| Hop limit
|<source lang="bash">
ip6 hoplimit 1
ip6 hoplimit != 233
ip6 hoplimit 33-45
ip6 hoplimit != 33-45
ip6 hoplimit {33, 55, 67, 88}
ip6 hoplimit {33-55}
</source>
|-
| ''saddr <ip source address>''
| Source Address
|<source lang="bash">
ip6 saddr 1234:1234:1234:1234:1234:1234:1234:1234
ip6 saddr ::1234:1234:1234:1234:1234:1234:1234
ip6 saddr ::/64
ip6 saddr ::1 ip6 daddr ::2
</source>
|-
| ''daddr <ip destination address>''
| Destination Address
|<source lang="bash">
ip6 daddr 1234:1234:1234:1234:1234:1234:1234:1234
ip6 daddr != ::1234:1234:1234:1234:1234:1234:1234-1234:1234::1234:1234:1234:1234:1234
</source>
|-
| ''version <version>''
| IP header version
|<source lang="bash">
ip6 version 6
</source>
|}

==== Tcp ====

{| class="wikitable"
!colspan="6"|tcp match
|-
| ''dport <destination port>''
| Destination port
|<source lang="bash">
tcp dport 22
tcp dport != 33-45
tcp dport { 33-55 }
tcp dport {telnet, http, https }
tcp dport vmap { 22 : accept, 23 : drop }
tcp dport vmap { 25:accept, 28:drop }
</source>
|-
| ''sport < source port>''
| Source port
|<source lang="bash">
tcp sport 22
tcp sport != 33-45
tcp sport { 33, 55, 67, 88}
tcp sport { 33-55}
tcp sport vmap { 25:accept, 28:drop }
tcp sport 1024 tcp dport 22
</source>
|-
| ''sequence <value>''
| Sequence number
|<source lang="bash">
tcp sequence 22
tcp sequence != 33-45
</source>
|-
| ''ackseq <value>''
| Acknowledgement number
|<source lang="bash">
tcp ackseq 22
tcp ackseq != 33-45
tcp ackseq { 33, 55, 67, 88 }
tcp ackseq { 33-55 }
</source>
|-
| ''flags <flags>''
| TCP flags
|<source lang="bash">
tcp flags { fin, syn, rst, psh, ack, urg, ecn, cwr}
tcp flags cwr
tcp flags != cwr
</source>
|-
| ''window <value>''
| Window
|<source lang="bash">
tcp window 22
tcp window != 33-45
tcp window { 33, 55, 67, 88 }
tcp window { 33-55 }
</source>
|-
| ''checksum <checksum>''
| IP header checksum
|<source lang="bash">
tcp checksum 22
tcp checksum != 33-45
tcp checksum { 33, 55, 67, 88 }
tcp checksum { 33-55 }
</source>
|-
| ''urgptr <pointer>''
| Urgent pointer
|<source lang="bash">
tcp urgptr 22
tcp urgptr != 33-45
tcp urgptr { 33, 55, 67, 88 }
</source>
|-
| ''doff <offset>''
| Data offset
|<source lang="bash">
tcp doff 8
</source>
|}

==== Udp ====

{| class="wikitable"
!colspan="6"|udp match
|-
| ''dport <destination port>''
| Destination port
|<source lang="bash">
udp dport 22
udp dport != 33-45
udp dport { 33-55 }
udp dport {telnet, http, https }
udp dport vmap { 22 : accept, 23 : drop }
udp dport vmap { 25:accept, 28:drop }
</source>
|-
| ''sport < source port>''
| Source port
|<source lang="bash">
udp sport 22
udp sport != 33-45
udp sport { 33, 55, 67, 88}
udp sport { 33-55}
udp sport vmap { 25:accept, 28:drop }
udp sport 1024 tcp dport 22
</source>
|-
| ''length <length>''
| Total packet length
|<source lang="bash">
udp length 6666
udp length != 50-65
udp length { 50, 65 }
udp length { 35-50 }
</source>
|-
| ''checksum <checksum>''
| UDP checksum
|<source lang="bash">
udp checksum 22
udp checksum != 33-45
udp checksum { 33, 55, 67, 88 }
udp checksum { 33-55 }
</source>
|}

==== Udplite ====

{| class="wikitable"
!colspan="6"|udplite match
|-
| ''dport <destination port>''
| Destination port
|<source lang="bash">
udplite dport 22
udplite dport != 33-45
udplite dport { 33-55 }
udplite dport {telnet, http, https }
udplite dport vmap { 22 : accept, 23 : drop }
udplite dport vmap { 25:accept, 28:drop }
</source>
|-
| ''sport < source port>''
| Source port
|<source lang="bash">
udplite sport 22
udplite sport != 33-45
udplite sport { 33, 55, 67, 88}
udplite sport { 33-55}
udplite sport vmap { 25:accept, 28:drop }
udplite sport 1024 tcp dport 22
</source>
|-
| ''checksum <checksum>''
| Checksum
|<source lang="bash">
udplite checksum 22
udplite checksum != 33-45
udplite checksum { 33, 55, 67, 88 }
udplite checksum { 33-55 }
</source>
|}

==== Sctp ====

{| class="wikitable"
!colspan="6"|sctp match
|-
| ''dport <destination port>''
| Destination port
|<source lang="bash">
sctp dport 22
sctp dport != 33-45
sctp dport { 33-55 }
sctp dport {telnet, http, https }
sctp dport vmap { 22 : accept, 23 : drop }
sctp dport vmap { 25:accept, 28:drop }
</source>
|-
| ''sport < source port>''
| Source port
|<source lang="bash">
sctp sport 22
sctp sport != 33-45
sctp sport { 33, 55, 67, 88}
sctp sport { 33-55}
sctp sport vmap { 25:accept, 28:drop }
sctp sport 1024 tcp dport 22
</source>
|-
| ''checksum <checksum>''
| Checksum
|<source lang="bash">
sctp checksum 22
sctp checksum != 33-45
sctp checksum { 33, 55, 67, 88 }
sctp checksum { 33-55 }
</source>
|-
| ''vtag <tag>''
| Verification tag
|<source lang="bash">
sctp vtag 22
sctp vtag != 33-45
sctp vtag { 33, 55, 67, 88 }
sctp vtag { 33-55 }
</source>
|}

==== Dccp ====

{| class="wikitable"
!colspan="6"|dccp match
|-
| ''dport <destination port>''
| Destination port
|<source lang="bash">
dccp dport 22
dccp dport != 33-45
dccp dport { 33-55 }
dccp dport {telnet, http, https }
dccp dport vmap { 22 : accept, 23 : drop }
dccp dport vmap { 25:accept, 28:drop }
</source>
|-
| ''sport < source port>''
| Source port
|<source lang="bash">
dccp sport 22
dccp sport != 33-45
dccp sport { 33, 55, 67, 88}
dccp sport { 33-55}
dccp sport vmap { 25:accept, 28:drop }
dccp sport 1024 tcp dport 22
</source>
|-
| ''type <type>''
| Type of packet
|<source lang="bash">
dccp type {request, response, data, ack, dataack, closereq, close, reset, sync, syncack}
dccp type request
dccp type != request
</source>
|}

==== Ah ====

{| class="wikitable"
!colspan="6"|ah match
|-
| ''hdrlength <length>''
| AH header length
|<source lang="bash">
ah hdrlength 11-23
ah hdrlength != 11-23
ah hdrlength {11, 23, 44 }
</source>
|-
| ''reserved <value>''
|
|<source lang="bash">
ah reserved 22
ah reserved != 33-45
ah reserved {23, 100 }
ah reserved { 33-55 }
</source>
|-
| ''spi <value>''
|
|<source lang="bash">
ah spi 111
ah spi != 111-222
ah spi {111, 122 }
</source>
|-
| ''sequence <sequence>''
| Sequence Number
|<source lang="bash">
ah sequence 123
ah sequence {23, 25, 33}
ah sequence != 23-33
</source>
|}

==== Esp ====

{| class="wikitable"
!colspan="6"|esp match
|-
| ''spi <value>''
|
|<source lang="bash">
esp spi 111
esp spi != 111-222
esp spi {111, 122 }
</source>
|-
| ''sequence <sequence>''
| Sequence Number
|<source lang="bash">
esp sequence 123
esp sequence {23, 25, 33}
esp sequence != 23-33
</source>
|}

==== Comp ====

{| class="wikitable"
!colspan="6"|comp match
|-
| ''nexthdr <protocol>''
| Next header protocol (Upper layer protocol)
|<source lang="bash">
comp nexthdr != esp
comp nexthdr {esp, ah, comp, udp, udplite, tcp, tcp, dccp, sctp}
</source>
|-
| ''flags <flags>''
| Flags
|<source lang="bash">
comp flags 0x0
comp flags != 0x33-0x45
comp flags {0x33, 0x55, 0x67, 0x88}
</source>
|-
| ''cpi <value>''
| Compression Parameter Index
|<source lang="bash">
comp cpi 22
comp cpi != 33-45
comp cpi {33, 55, 67, 88}
</source>
|}

==== Icmp ====

{| class="wikitable"
!colspan="6"|icmp match
|-
| ''type <type>''
| ICMP packet type
|<source lang="bash">
icmp type {echo-reply, destination-unreachable, source-quench, redirect, echo-request, time-exceeded, parameter-problem, timestamp-request, timestamp-reply, info-request, info-reply, address-mask-request, address-mask-reply, router-advertisement, router-solicitation}
</source>
|-
| ''code <code>''
| ICMP packet code
|<source lang="bash">
icmp code 111
icmp code != 33-55
icmp code { 2, 4, 54, 33, 56}
</source>
|-
| ''checksum <value>''
| ICMP packet checksum
|<source lang="bash">
icmp checksum 12343
icmp checksum != 11-343
icmp checksum { 1111, 222, 343 }
</source>
|-
| ''id <value>''
| ICMP packet id
|<source lang="bash">
icmp id 12343
icmp id != 11-343
icmp id { 1111, 222, 343 }
</source>
|-
| ''sequence <value>''
| ICMP packet sequence
|<source lang="bash">
icmp sequence 12343
icmp sequence != 11-343
icmp sequence { 1111, 222, 343 }
</source>
|-
| ''mtu <value>''
| ICMP packet mtu
|<source lang="bash">
icmp mtu 12343
icmp mtu != 11-343
icmp mtu { 1111, 222, 343 }
</source>
|-
| ''gateway <value>''
| ICMP packet gateway
|<source lang="bash">
icmp gateway 12343
icmp gateway != 11-343
icmp gateway { 1111, 222, 343 }
</source>
|}

==== Icmpv6 ====

{| class="wikitable"
!colspan="6"|icmpv6 match
|-
| ''type <type>''
| ICMPv6 packet type
|<source lang="bash">
icmpv6 type {destination-unreachable, packet-too-big, time-exceeded, echo-request, echo-reply, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, nd-redirect, parameter-problem, router-renumbering}
</source>
|-
| ''code <code>''
| ICMPv6 packet code
|<source lang="bash">
icmpv6 code 4
icmpv6 code 3-66
icmpv6 code {5, 6, 7}
</source>
|-
| ''checksum <value>''
| ICMPv6 packet checksum
|<source lang="bash">
icmpv6 checksum 12343
icmpv6 checksum != 11-343
icmpv6 checksum { 1111, 222, 343 }
</source>
|-
| ''id <value>''
| ICMPv6 packet id
|<source lang="bash">
icmpv6 id 12343
icmpv6 id != 11-343
icmpv6 id { 1111, 222, 343 }
</source>
|-
| ''sequence <value>''
| ICMPv6 packet sequence
|<source lang="bash">
icmpv6 sequence 12343
icmpv6 sequence != 11-343
icmpv6 sequence { 1111, 222, 343 }
</source>
|-
| ''mtu <value>''
| ICMPv6 packet mtu
|<source lang="bash">
icmpv6 mtu 12343
icmpv6 mtu != 11-343
icmpv6 mtu { 1111, 222, 343 }
</source>
|-
| ''max-delay <value>''
| ICMPv6 packet max delay
|<source lang="bash">
icmpv6 max-delay 33-45
icmpv6 max-delay != 33-45
icmpv6 max-delay {33, 55, 67, 88}
</source>
|}

==== Ether ====

{| class="wikitable"
!colspan="6"|ether match
|-
| ''saddr <mac address>''
| Source mac address
|<source lang="bash">
ether saddr 00:0f:54:0c:11:04
</source>
|-
| ''type <type>''
|
|<source lang="bash">
ether type vlan
</source>
|}

==== Dst ====

{| class="wikitable"
!colspan="6"|dst match
|-
| ''nexthdr <proto>''
| Next protocol header
|<source lang="bash">
dst nexthdr { udplite, ipcomp, udp, ah, sctp, esp, dccp, tcp, ipv6-icmp}
dst nexthdr 22
dst nexthdr != 33-45
</source>
|-
| ''hdrlength <length>''
| Header Length
|<source lang="bash">
dst hdrlength 22
dst hdrlength != 33-45
dst hdrlength { 33, 55, 67, 88 }
</source>
|}

==== Frag ====

{| class="wikitable"
!colspan="6"|frag match
|-
| ''nexthdr <proto>''
| Next protocol header
|<source lang="bash">
frag nexthdr { udplite, comp, udp, ah, sctp, esp, dccp, tcp, ipv6-icmp, icmp}
frag nexthdr 6
frag nexthdr != 50-51
</source>
|-
| ''reserved <value>''
|
|<source lang="bash">
frag reserved 22
frag reserved != 33-45
frag reserved { 33, 55, 67, 88}
</source>
|-
| ''frag-off <value>''
|
|<source lang="bash">
frag frag-off 22
frag frag-off != 33-45
frag frag-off { 33, 55, 67, 88}
</source>
|-
| ''more-fragments <value>''
|
|<source lang="bash">
frag more-fragments 0
frag more-fragments 0
</source>
|-
| ''id <value>''
|
|<source lang="bash">
frag id 1
frag id 33-45
</source>
|}

==== Hbh ====

{| class="wikitable"
!colspan="6"|hbh match
|-
| ''nexthdr <proto>''
| Next protocol header
|<source lang="bash">
hbh nexthdr { udplite, comp, udp, ah, sctp, esp, dccp, tcp, icmpv6}
hbh nexthdr 22
hbh nexthdr != 33-45
</source>
|-
| ''hdrlength <length>''
| Header Length
|<source lang="bash">
hbh hdrlength 22
hbh hdrlength != 33-45
hbh hdrlength { 33, 55, 67, 88 }
</source>
|}

==== Mh ====

{| class="wikitable"
!colspan="6"|mh match
|-
| ''nexthdr <proto>''
| Next protocol header
|<source lang="bash">
mh nexthdr { udplite, ipcomp, udp, ah, sctp, esp, dccp, tcp, ipv6-icmp }
mh nexthdr 22
mh nexthdr != 33-45
</source>
|-
| ''hdrlength <length>''
| Header Length
|<source lang="bash">
mh hdrlength 22
mh hdrlength != 33-45
mh hdrlength { 33, 55, 67, 88 }
</source>
|-
| ''type <type>''
|
|<source lang="bash">
mh type {binding-refresh-request, home-test-init, careof-test-init, home-test, careof-test, binding-update, binding-acknowledgement, binding-error, fast-binding-update, fast-binding-acknowledgement, fast-binding-advertisement, experimental-mobility-header, home-agent-switch-message}
mh type home-agent-switch-message
mh type != home-agent-switch-message
</source>
|-
| ''reserved <value>''
|
|<source lang="bash">
mh reserved 22
mh reserved != 33-45
mh reserved { 33, 55, 67, 88}
</source>
|-
| ''checksum <value>''
|
|<source lang="bash">
mh checksum 22
mh checksum != 33-45
mh checksum { 33, 55, 67, 88}
</source>
|}

==== Rt ====

{| class="wikitable"
!colspan="6"|rt match
|-
| ''nexthdr <proto>''
| Next protocol header
|<source lang="bash">
rt nexthdr { udplite, ipcomp, udp, ah, sctp, esp, dccp, tcp, ipv6-icmp }
rt nexthdr 22
rt nexthdr != 33-45
</source>
|-
| ''hdrlength <length>''
| Header Length
|<source lang="bash">
rt hdrlength 22
rt hdrlength != 33-45
rt hdrlength { 33, 55, 67, 88 }
</source>
|-
| ''type <type>''
|
|<source lang="bash">
rt type 22
rt type != 33-45
rt type { 33, 55, 67, 88 }
</source>
|-
| ''seg-left <value>''
|
|<source lang="bash">
rt seg-left 22
rt seg-left != 33-45
rt seg-left { 33, 55, 67, 88}
</source>
|}

==== Vlan ====

{| class="wikitable"
!colspan="6"|vlan match
|-
| ''id <value>''
| Vlan tag ID
|<source lang="bash">
vlan id 4094
vlan id 0
</source>
|-
| ''cfi <value>''
|
|<source lang="bash">
vlan cfi 0
vlan cfi 1
</source>
|-
| ''pcp <value>''
|
|<source lang="bash">
vlan pcp 7
vlan pcp 3
</source>
|}

==== Arp ====

{| class="wikitable"
!colspan="6"|arp match
|-
| ''ptype <value>''
| Payload type
|<source lang="bash">
arp ptype 0x0800
</source>
|-
| ''htype <value>''
| Header type
|<source lang="bash">
arp htype 1
arp htype != 33-45
arp htype { 33, 55, 67, 88}
</source>
|-
| ''hlen <length>''
| Header Length
|<source lang="bash">
arp hlen 1
arp hlen != 33-45
arp hlen { 33, 55, 67, 88}
</source>
|-
| ''plen <length>''
| Payload length
|<source lang="bash">
arp plen 1
arp plen != 33-45
arp plen { 33, 55, 67, 88}
</source>
|-
| ''operation <value>''
|
|<source lang="bash">
arp operation {nak, inreply, inrequest, rreply, rrequest, reply, request}
</source>
|}

==== Ct ====

{| class="wikitable"
!colspan="6"|ct match
|-
| ''state <state>''
| State of the connection
|<source lang="bash">
ct state { new, established, related, untracked }
ct state != related
ct state established
ct state 8
</source>
|-
| ''direction <value>''
| Direction of the packet relative to the connection
|<source lang="bash">
ct direction original
ct direction != original
ct direction {reply, original}
</source>
|-
| ''status <status>''
| Status of the connection
|<source lang="bash">
ct status expected
(ct status & expected) != expected
ct status {expected,seen-reply,assured,confirmed,snat,dnat,dying}
</source>
|-
| ''mark [set] <mark>''
| Mark of the connection
|<source lang="bash">
ct mark 0
ct mark or 0x23 == 0x11
ct mark or 0x3 != 0x1
ct mark and 0x23 == 0x11
ct mark and 0x3 != 0x1
ct mark xor 0x23 == 0x11
ct mark xor 0x3 != 0x1
ct mark 0x00000032
ct mark != 0x00000032
ct mark 0x00000032-0x00000045
ct mark != 0x00000032-0x00000045
ct mark {0x32, 0x2222, 0x42de3}
ct mark {0x32-0x2222, 0x4444-0x42de3}
ct mark set 0x11 xor 0x1331
ct mark set 0x11333 and 0x11
ct mark set 0x12 or 0x11
ct mark set 0x11
ct mark set mark
ct mark set mark map { 1 : 10, 2 : 20, 3 : 30 }
</source>
|-
| ''expiration <time>''
| Connection expiration time
|<source lang="bash">
ct expiration 30
ct expiration 30s
ct expiration != 233
ct expiration != 3m53s
ct expiration 33-45
ct expiration 33s-45s
ct expiration != 33-45
ct expiration != 33s-45s
ct expiration {33, 55, 67, 88}
ct expiration { 1m7s, 33s, 55s, 1m28s}
</source>
|-
| ''helper "<helper>"''
| Helper associated with the connection
|<source lang="bash">
ct helper "ftp"
</source>
|-
| | ''[original | reply] bytes <value>''
|
|<source lang="bash">
ct original bytes > 100000
ct bytes > 100000
</source>
|-
| | ''[original | reply] packets <value>''
|
|<source lang="bash">
ct reply packets < 100
</source>
|-
| | ''[original | reply] ip saddr <ip source address>''
|
|<source lang="bash">
ct original ip saddr 192.168.0.1
ct reply ip saddr 192.168.0.1
ct original ip saddr 192.168.1.0/24
ct reply ip saddr 192.168.1.0/24
</source>
|-
| | ''[original | reply] ip daddr <ip destination address>''
|
|<source lang="bash">
ct original ip daddr 192.168.0.1
ct reply ip daddr 192.168.0.1
ct original ip daddr 192.168.1.0/24
ct reply ip daddr 192.168.1.0/24
</source>
|-
| | ''[original | reply] l3proto <protocol>''
|
|<source lang="bash">
ct original l3proto ipv4
</source>
|-
| | ''[original | reply] protocol <protocol>''
|
|<source lang="bash">
ct original protocol 6
</source>
|-
| | ''[original | reply] proto-dst <port>''
|
|<source lang="bash">
ct original proto-dst 22
</source>
|-
| | ''[original | reply] proto-src <port>''
|
|<source lang="bash">
ct reply proto-src 53
</source>
|}

==== Meta ====

[[Matching packet metainformation|''meta'']] matches packet by metainformation.

{| class="wikitable"
!colspan="6"|meta match
|-
| ''iifname <input interface name>''
| Input interface name
|<source lang="bash">
meta iifname "eth0"
meta iifname != "eth0"
meta iifname {"eth0", "lo"}
meta iifname "eth*"
</source>
|-
| ''oifname <output interface name>''
| Output interface name
|<source lang="bash">
meta oifname "eth0"
meta oifname != "eth0"
meta oifname {"eth0", "lo"}
meta oifname "eth*"
</source>
|-
| ''iif <input interface index>''
| Input interface index
|<source lang="bash">
meta iif eth0
meta iif != eth0
</source>
|-
| ''oif <output interface index>''
| Output interface index
|<source lang="bash">
meta oif lo
meta oif != lo
meta oif {eth0, lo}
</source>
|-
| ''iiftype <input interface type>''
| Input interface type
|<source lang="bash">
meta iiftype {ether, ppp, ipip, ipip6, loopback, sit, ipgre}
meta iiftype != ether
meta iiftype ether
</source>
|-
| ''oiftype <output interface type>''
| Output interface hardware type
|<source lang="bash">
meta oiftype {ether, ppp, ipip, ipip6, loopback, sit, ipgre}
meta oiftype != ether
meta oiftype ether
</source>
|-
| ''length <length>''
| Length of the packet in bytes
|<source lang="bash">
meta length 1000
meta length != 1000
meta length > 1000
meta length 33-45
meta length != 33-45
meta length { 33, 55, 67, 88 }
meta length { 33-55, 67-88 }
</source>
|-
| ''protocol <protocol>''
| ethertype protocol
|<source lang="bash">
meta protocol ip
meta protocol != ip
meta protocol { ip, arp, ip6, vlan }
</source>
|-
| ''nfproto <protocol>''
|
|<source lang="bash">
meta nfproto ipv4
meta nfproto != ipv6
meta nfproto { ipv4, ipv6 }
</source>
|-
| ''l4proto <protocol>''
|
|<source lang="bash">
meta l4proto 22
meta l4proto != 233
meta l4proto 33-45
meta l4proto { 33, 55, 67, 88 }
meta l4proto { 33-55 }
</source>
|-
| ''mark [set] <mark>''
| Packet mark
|<source lang="bash">
meta mark 0x4
meta mark 0x00000032
meta mark and 0x03 == 0x01
meta mark and 0x03 != 0x01
meta mark != 0x10
meta mark or 0x03 == 0x01
meta mark or 0x03 != 0x01
meta mark xor 0x03 == 0x01
meta mark xor 0x03 != 0x01
meta mark set 0xffffffc8 xor 0x16
meta mark set 0x16 and 0x16
meta mark set 0xffffffe9 or 0x16
meta mark set 0xffffffde and 0x16
meta mark set 0x32 or 0xfffff
meta mark set 0xfffe xor 0x16
</source>
|-
| ''priority [set] <priority>''
| tc class id
|<source lang="bash">
meta priority none
meta priority 0x1:0x1
meta priority 0x1:0xffff
meta priority 0xffff:0xffff
meta priority set 0x1:0x1
meta priority set 0x1:0xffff
meta priority set 0xffff:0xffff
</source>
|-
| ''skuid <user id>''
| UID associated with originating socket
|<source lang="bash">
meta skuid {bin, root, daemon}
meta skuid root
meta skuid != root
meta skuid lt 3000
meta skuid gt 3000
meta skuid eq 3000
meta skuid 3001-3005
meta skuid != 2001-2005
meta skuid { 2001-2005 }
</source>
|-
| ''skgid <group id>''
| GID associated with originating socket
|<source lang="bash">
meta skgid {bin, root, daemon}
meta skgid root
meta skgid != root
meta skgid lt 3000
meta skgid gt 3000
meta skgid eq 3000
meta skgid 3001-3005
meta skgid != 2001-2005
meta skgid { 2001-2005 }
</source>
|-
| ''rtclassid <class>''
| Routing realm
|<source lang="bash">
meta rtclassid cosmos
</source>
|-
| ''pkttype <type>''
| Packet type
|<source lang="bash">
meta pkttype broadcast
meta pkttype != broadcast
meta pkttype { broadcast, unicast, multicast}
</source>
|-
| ''cpu <cpu index>''
| CPU ID
|<source lang="bash">
meta cpu 1
meta cpu != 1
meta cpu 1-3
meta cpu != 1-2
meta cpu { 2,3 }
meta cpu { 2-3, 5-7 }
</source>
|-
| ''iifgroup <input group>''
| Input interface group
|<source lang="bash">
meta iifgroup 0
meta iifgroup != 0
meta iifgroup default
meta iifgroup != default
meta iifgroup {default}
meta iifgroup { 11,33 }
meta iifgroup {11-33}
</source>
|-
| ''oifgroup <group>''
| Output interface group
|<source lang="bash">
meta oifgroup 0
meta oifgroup != 0
meta oifgroup default
meta oifgroup != default
meta oifgroup {default}
meta oifgroup { 11,33 }
meta oifgroup {11-33}
</source>
|-
| ''cgroup <group>''
|
|<source lang="bash">
meta cgroup 1048577
meta cgroup != 1048577
meta cgroup { 1048577, 1048578 }
meta cgroup 1048577-1048578
meta cgroup != 1048577-1048578
meta cgroup {1048577-1048578}
</source>
|}

=== Statements ===

'''statement''' is the action performed when the packet match the rule. It could be ''terminal'' and ''non-terminal''. In a certain rule we can consider several non-terminal statements but only a single terminal statement.

==== Verdict statements ====

The '''verdict statement''' alters control flow in the ruleset and issues policy decisions for packets. The valid verdict statements are:

* ''accept'': Accept the packet and stop the remain rules evaluation.
* ''drop'': Drop the packet and stop the remain rules evaluation.
* ''queue'': Queue the packet to userspace and stop the remain rules evaluation.
* ''continue'': Continue the ruleset evaluation with the next rule.
* ''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 <chain>'': Continue at the first rule of <chain>. It will continue at the next rule after a return statement is issued
* ''goto <chain>'': Similar to jump, but after the new chain the evaluation will continue at the last chain instead of the one containing the goto statement

==== Log ====

{| class="wikitable"
!colspan="6"|log statement
|-
| ''level [over] <value> <unit> [burst <value> <unit>]''
| Log level
|<source lang="bash">
log
log level emerg
log level alert
log level crit
log level err
log level warn
log level notice
log level info
log level debug
</source>
|-
| ''group <value> [queue-threshold <value>] [snaplen <value>] [prefix "<prefix>"]''
|
|<source lang="bash">
log prefix aaaaa-aaaaaa group 2 snaplen 33
log group 2 queue-threshold 2
log group 2 snaplen 33
</source>
|}

==== Reject ====

The default '''reject''' will be the ICMP type '''port-unreachable'''. The '''icmpx''' is only used for inet family support.

More information on the [[Rejecting_traffic]] page.

{| class="wikitable"
!colspan="6"|reject statement
|-
| ''with <protocol> type <type>''
|
|<source lang="bash">
reject
reject with icmp type host-unreachable
reject with icmp type net-unreachable
reject with icmp type prot-unreachable
reject with icmp type port-unreachable
reject with icmp type net-prohibited
reject with icmp type host-prohibited
reject with icmp type admin-prohibited
reject with icmpv6 type no-route
reject with icmpv6 type admin-prohibited
reject with icmpv6 type addr-unreachable
reject with icmpv6 type port-unreachable
reject with icmpx type host-unreachable
reject with icmpx type no-route
reject with icmpx type admin-prohibited
reject with icmpx type port-unreachable
ip protocol tcp reject with tcp reset
</source>
|}

==== Counter ====

{| class="wikitable"
!colspan="6"|counter statement
|-
| ''packets <packets> bytes <bytes>''
|
|<source lang="bash">
counter
counter packets 0 bytes 0
</source>
|}

==== Limit ====

{| class="wikitable"
!colspan="6"|limit statement
|-
| ''rate [over] <value> <unit> [burst <value> <unit>]''
| Rate limit
|<source lang="bash">
limit rate 400/minute
limit rate 400/hour
limit rate over 40/day
limit rate over 400/week
limit rate over 1023/second burst 10 packets
limit rate 1025 kbytes/second
limit rate 1023000 mbytes/second
limit rate 1025 bytes/second burst 512 bytes
limit rate 1025 kbytes/second burst 1023 kbytes
limit rate 1025 mbytes/second burst 1025 kbytes
limit rate 1025000 mbytes/second burst 1023 mbytes
</source>
|}

==== Nat ====

{| class="wikitable"
!colspan="6"|nat statement
|-
| ''dnat to <destination address>''
| Destination address translation
|<source lang="bash">
dnat to 192.168.3.2
dnat to ct mark map { 0x00000014 : 1.2.3.4}
</source>
|-
| ''snat to <ip source address>''
| Source address translation
|<source lang="bash">
snat to 192.168.3.2
snat to 2001:838:35f:1::-2001:838:35f:2:::100
</source>
|-
| ''masquerade [<type>] [to :<port>]''
| Masquerade
|<source lang="bash">
masquerade
masquerade persistent,fully-random,random
masquerade to :1024
masquerade to :1024-2048
</source>
|}

==== Queue ====

{| class="wikitable"
!colspan="6"|queue statement
|-
| ''num <value> <scheduler>''
|
|<source lang="bash">
queue
queue num 2
queue num 2-3
queue num 4-5 fanout bypass
queue num 4-5 fanout
queue num 4-5 bypass
</source>
|}

== Extras ==

=== Export Configuration ===

<source lang="bash">
% nft export (xml | json)
</source>

=== Monitor Events ===

Monitor events from Netlink creating filters.

<source lang="bash">
% nft monitor [new | destroy] [tables | chains | sets | rules | elements] [xml | json]
</source>

= Nft scripting =

== List ruleset ==

<source lang="bash">
% nft list ruleset
</source>

== Flush ruleset ==

<source lang="bash">
% nft flush ruleset
</source>

== Load ruleset ==

Create a command batch file and load it with the nft interpreter,

<source lang="bash">
% echo "flush ruleset" > /etc/nftables.rules
% echo "add table filter" >> /etc/nftables.rules
% echo "add chain filter input" >> /etc/nftables.rules
% echo "add rule filter input meta iifname lo accept" >> /etc/nftables.rules
% nft -f /etc/nftables.rules
</source>

or create an executable nft script file,

<source lang="bash">
% cat << EOF > /etc/nftables.rules
> #!/usr/local/sbin/nft -f
> flush ruleset
> add table filter
> add chain filter input
> add rule filter input meta iifname lo accept
> EOF
% chmod u+x /etc/nftables.rules
% /etc/nftables.rules
</source>

or create an executable nft script file from an already created ruleset,

<source lang="bash">
% nft list ruleset > /etc/nftables.rules
% nft flush ruleset
% nft -f /etc/nftables.rules
</source>

= Examples =

== Simple IP/IPv6 Firewall ==

<source lang="bash">
flush ruleset

table firewall {
chain incoming {
type filter hook input priority 0; policy drop;

# established/related connections
ct state established,related accept

# loopback interface
iifname lo accept

# icmp
icmp type echo-request accept

# open tcp ports: sshd (22), httpd (80)
tcp dport {ssh, http} accept
}
}

table ip6 firewall {
chain incoming {
type filter hook input priority 0; policy drop;

# established/related connections
ct state established,related accept

# invalid connections
ct state invalid drop

# loopback interface
iifname lo accept

# icmp
# routers may also want: mld-listener-query, nd-router-solicit
icmpv6 type {echo-request,nd-neighbor-solicit} accept

# open tcp ports: sshd (22), httpd (80)
tcp dport {ssh, http} accept
}
}
</source>