nftables wiki - User contributions [en]

Flowtables

2025-04-18T00:53:59Z

Pablo: remove ct state established in flow add rule

Flowtables allow you to accelerate packet forwarding in software (and in hardware if your NIC supports it) by using a conntrack-based network stack bypass.

Entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4
protocols. Each entry also caches the destination interface and the gateway address (to update the destination link-layer address) to forward packets.

The TTL and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path.

<pre>
userspace process
^ |
| |
_____|____ ____\/___
/ \ / \
| input | | output |
\__________/ \_________/
^ |
| |
_________ __________ --------- _____\/_____
/ \ / \ |Routing | / \
--> ingress ---> prerouting ---> |decision| | postrouting|--> neigh_xmit
\_________/ \__________/ ---------- \____________/ ^
| ^ | ^ |
flowtable | ____\/___ | |
| | / \ | |
__\/___ | | forward |------------ |
|-----| | \_________/ |
|-----| | 'flow add' rule |
|-----| | adds entry to |
|_____| | flowtable |
| | |
/ \ | |
/hit\_no_| |
\ ? / |
\ / |
|__yes_________________fastpath bypass ____________________________|

Fig.1 Netfilter hooks and flowtable interactions
</pre>

Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address [[Nftables_families|family]] and their name. The address family must be one of ip, ip6, or inet. When no address family is specified, ip is used by default.

Flows are offloaded after the state is created. That means that usually the first reply packet will create the flowtable entry.
A firewall rule to accept the initial traffic is required.
The flow expression on the forward chain must match the return traffic of the initial connection.
Be aware that the return route is deducted from the packet, that creates the flowtable entry.
This also means if you are using special ip rules, you need to make sure that they match the reply packet traffic as well as the original traffic.

The *priority* can be a signed integer or *filter* which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.

The *devices* are specified as [[Data_types|iifname]](s) of the input interface(s) of the traffic that should be offloaded. Devices are required for both traffic directions.

An Example to offload HTTP traffic for a router:

<pre>
define DEV_PRIVATE=eth0
define DEV_INTERNET=eth1

table inet x {

flowtable f {
hook ingress priority 0
devices = { $DEV_PRIVATE, $DEV_INTERNET }
}

chain forward {
type filter hook forward priority 0; policy drop;

# offload established HTTP connections
tcp dport { 80, 443 } flow add @f counter packets 0 bytes 0

# Allow traffic from established and related packets, drop invalid
ct state vmap { established : accept, related : accept, invalid : drop }

# connections from the internal net to the internet or to other
# internal nets are allowed
iifname $DEV_PRIVATE counter accept
}
}
</pre>

Note that:

# The rule that uses the ''flow add'' statement determines what flows are added to the flowtable. This ruleset above adds entries to the flowtable for established HTTP connections.
# The devices you specify in the flowtable declaration determine where the flowtable hooks in the pipeline for lookups, in the example above, it registers a hook for devices eth0 and eth1 in the ingress hook at priority 0.

== See also ==

* [https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Linux kernel documentation on Netfilter flowtable]
* [https://netdevconf.info/0x13/session.html?workshop-netfilter-mini Netfilter Mini-Workshop, Netdev 0x13, 2019-03]
* [https://lwn.net/Articles/804384/ Mellanox flowtable hardware offload]
* [https://www.programmersought.com/article/11833283913/ Some Mellanox flowtable hardware offload performance measurements by Wen Xu of UCloud]
* [https://linuxplumbersconf.org/event/4/contributions/463/ Netfilter hardware offloads, Pablo Neira Ayuso, Linux Plumbers Conference, 2019-09]

Flowtables

2025-04-04T17:37:07Z

Pablo: replace flow offload by flow add

Flowtables allow you to accelerate packet forwarding in software (and in hardware if your NIC supports it) by using a conntrack-based network stack bypass.

Entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4
protocols. Each entry also caches the destination interface and the gateway address (to update the destination link-layer address) to forward packets.

The TTL and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path.

<pre>
userspace process
^ |
| |
_____|____ ____\/___
/ \ / \
| input | | output |
\__________/ \_________/
^ |
| |
_________ __________ --------- _____\/_____
/ \ / \ |Routing | / \
--> ingress ---> prerouting ---> |decision| | postrouting|--> neigh_xmit
\_________/ \__________/ ---------- \____________/ ^
| ^ | ^ |
flowtable | ____\/___ | |
| | / \ | |
__\/___ | | forward |------------ |
|-----| | \_________/ |
|-----| | 'flow add' rule |
|-----| | adds entry to |
|_____| | flowtable |
| | |
/ \ | |
/hit\_no_| |
\ ? / |
\ / |
|__yes_________________fastpath bypass ____________________________|

Fig.1 Netfilter hooks and flowtable interactions
</pre>

Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address [[Nftables_families|family]] and their name. The address family must be one of ip, ip6, or inet. When no address family is specified, ip is used by default.

Flows are offloaded after the state is created. That means that usually the first reply packet will create the flowtable entry.
A firewall rule to accept the initial traffic is required.
The flow expression on the forward chain must match the return traffic of the initial connection.
Be aware that the return route is deducted from the packet, that creates the flowtable entry.
This also means if you are using special ip rules, you need to make sure that they match the reply packet traffic as well as the original traffic.

The *priority* can be a signed integer or *filter* which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.

The *devices* are specified as [[Data_types|iifname]](s) of the input interface(s) of the traffic that should be offloaded. Devices are required for both traffic directions.

An Example to offload HTTP traffic for a router:

<pre>
define DEV_PRIVATE=eth0
define DEV_INTERNET=eth1

table inet x {

flowtable f {
hook ingress priority 0
devices = { $DEV_PRIVATE, $DEV_INTERNET }
}

chain forward {
type filter hook forward priority 0; policy drop;

# offload established HTTP connections
tcp dport { 80, 443 } ct state established flow add @f counter packets 0 bytes 0

# Allow traffic from established and related packets, drop invalid
ct state vmap { established : accept, related : accept, invalid : drop }

# connections from the internal net to the internet or to other
# internal nets are allowed
iifname $DEV_PRIVATE counter accept
}
}
</pre>

Note that:

# The rule that uses the ''flow add'' statement determines what flows are added to the flowtable. This ruleset above adds entries to the flowtable for established HTTP connections.
# The devices you specify in the flowtable declaration determine where the flowtable hooks in the pipeline for lookups, in the example above, it registers a hook for devices eth0 and eth1 in the ingress hook at priority 0.

== See also ==

* [https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Linux kernel documentation on Netfilter flowtable]
* [https://netdevconf.info/0x13/session.html?workshop-netfilter-mini Netfilter Mini-Workshop, Netdev 0x13, 2019-03]
* [https://lwn.net/Articles/804384/ Mellanox flowtable hardware offload]
* [https://www.programmersought.com/article/11833283913/ Some Mellanox flowtable hardware offload performance measurements by Wen Xu of UCloud]
* [https://linuxplumbersconf.org/event/4/contributions/463/ Netfilter hardware offloads, Pablo Neira Ayuso, Linux Plumbers Conference, 2019-09]

Nftables families

2024-05-29T17:13:46Z

Pablo: /* inet */ typo

[https://netfilter.org/ Netfilter] enables filtering at multiple [https://en.wikipedia.org/wiki/Internet_protocol_suite networking levels]. With iptables there is a separate tool for each level: ''iptables'', ''ip6tables'', ''arptables'', ''ebtables''. With nftables the multiple networking levels are abstracted into '''families''', all of which are served by the single tool ''nft''.

Please note that what traffic/packets you see and at which point in the network stack depends on the [[Netfilter_hooks|'''hook''']] you are using.

Following are descriptions of current nftables families. Additional families may be added in the future.

== ip ==

Tables of this family see [https://en.wikipedia.org/wiki/IPv4 IPv4] traffic/packets.
The ''iptables'' tool is the legacy x_tables equivalent.

== ip6 ==

Tables of this family see [https://en.wikipedia.org/wiki/IPv6 IPv6] traffic/packets.
The ''ip6tables'' tool is the legacy x_tables equivalent.

== inet ==

Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.

Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets and vice-versa. Rules for both layer 3 protocols affect both. Use [[Matching_packet_headers#Matching_transport_protocol|meta l4proto]] l4proto to match on the layer 4 protocol, regardless of whether the packet is IPv4 or IPv6.

Examples:
<source>
# This rule affects only IPv4 packets:
add rule inet filter input ip saddr 1.1.1.1 counter accept

# This rule affects only IPv6 packets:
add rule inet filter input ip6 daddr fe00::2 counter accept

# These rules affect both IPv4 and IPv6 packets:
add rule inet filter input ct state established,related counter accept
add rule inet filter input udp dport 53 accept
</source>

New in nftables 0.9.7 and Linux kernel 5.10 is the inet family [[Netfilter_hooks|''ingress'']] hook, which filters at the same location as the netdev ''ingress'' hook.

== arp ==

Tables of this family see [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP]-level (i.e, L2) traffic, before any L3 handling is done by the kernel. The ''arptables'' tool is the legacy x_tables equivalent.

== bridge ==

Tables of this family see traffic/packets traversing [https://wiki.linuxfoundation.org/networking/bridge bridges] (i.e. switching). No assumptions are made about L3 protocols.

The ''ebtables'' tool is the legacy x_tables equivalent. Some old x_tables modules such as ''physdev'' will also eventually be served from the nftables ''bridge'' family.

Note that there is no nf_conntrack integration for the nftables ''bridge'' family.

== netdev ==

The ''netdev'' family is different from the others in that it is used to create base chains attached to a '''single network interface'''. Such base chains see '''all''' network traffic on the specified interface, with no assumptions about L2 or L3 protocols. Therefore you can filter ARP traffic from here. There is no legacy x_tables equivalent to the ''netdev'' family.

The principal (only?) use for this family is for base chains using the [[Netfilter_hooks|''ingress'' hook]], new in Linux kernel 4.2. Such ''ingress'' chains see network packets just after the NIC driver passes them up to the networking stack. This very early location in the packet path is ideal for dropping packets associated with [https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_attack DDoS] attacks. Dropping packets from an ''ingress'' chain is twice as efficient as doing so from a ''prerouting'' chain. (Do note that in an ''ingress'' chain, 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.

You can also use the ''ingress'' hook for [[load balancing]], including Direct Server Return (DSR), [https://netdevconf.org/1.2/slides/oct6/08_nftables_Load_Balancing_with_nftables_II_Slides.pdf that has been reported to be 10x faster].

Quick reference-nftables in 10 minutes

2023-09-04T10:17:07Z

Pablo: add mld2-listener-report per bz#1701

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 base chain. Possible values are: ''accept'' (default) and ''drop''. Warning: Setting the policy to ''drop'' discards all packets that
have not been accepted by the ruleset.

<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 & 0x1fff != 0 # match fragments
ip frag-off & 0x2000 != 0 # match MF flag
ip frag-off & 0x4000 != 0 # match DF flag
</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 udp 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 udplite 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 sctp 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>
|-
| ''chunk <type>''
| Existence of a chunk with given type in packet
|<source lang="bash">
sctp chunk init exists
sctp chunk error missing
</source>
|-
| ''chunk <type> <field>''
| A chunk's field value (implies chunk existence)
|<sourcex lang="bash">
sctp chunk init flags 0x1
sctp chunk data tsn 0x23
</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 dccp 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, parameter-problem, mld2-listener-report }
</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>
|-
| | ''count [over] <number of connections>''
|
|<source lang="bash">
ct count over 2

tcp dport 22 add @ssh_flood { ip saddr ct count over 2 } reject
[ which requires an existing ssh_flood set, ie. add set filter ssh_flood { type ipv4_addr; flags dynamic; } ]
</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>

Quick reference-nftables in 10 minutes

2023-08-29T16:34:07Z

Pablo: add more useful examples for ip frag-off

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 base chain. Possible values are: ''accept'' (default) and ''drop''. Warning: Setting the policy to ''drop'' discards all packets that
have not been accepted by the ruleset.

<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 & 0x1fff != 0 # match fragments
ip frag-off & 0x2000 != 0 # match MF flag
ip frag-off & 0x4000 != 0 # match DF flag
</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 udp 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 udplite 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 sctp 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>
|-
| ''chunk <type>''
| Existence of a chunk with given type in packet
|<source lang="bash">
sctp chunk init exists
sctp chunk error missing
</source>
|-
| ''chunk <type> <field>''
| A chunk's field value (implies chunk existence)
|<sourcex lang="bash">
sctp chunk init flags 0x1
sctp chunk data tsn 0x23
</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 dccp 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>
|-
| | ''count [over] <number of connections>''
|
|<source lang="bash">
ct count over 2

tcp dport 22 add @ssh_flood { ip saddr ct count over 2 } reject
[ which requires an existing ssh_flood set, ie. add set filter ssh_flood { type ipv4_addr; flags dynamic; } ]
</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>

Quick reference-nftables in 10 minutes

2023-08-29T13:44:14Z

Pablo: incorrect copy, paste and mangle

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 base chain. Possible values are: ''accept'' (default) and ''drop''. Warning: Setting the policy to ''drop'' discards all packets that
have not been accepted by the ruleset.

<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 udp 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 udplite 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 sctp 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>
|-
| ''chunk <type>''
| Existence of a chunk with given type in packet
|<source lang="bash">
sctp chunk init exists
sctp chunk error missing
</source>
|-
| ''chunk <type> <field>''
| A chunk's field value (implies chunk existence)
|<sourcex lang="bash">
sctp chunk init flags 0x1
sctp chunk data tsn 0x23
</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 dccp 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>
|-
| | ''count [over] <number of connections>''
|
|<source lang="bash">
ct count over 2

tcp dport 22 add @ssh_flood { ip saddr ct count over 2 } reject
[ which requires an existing ssh_flood set, ie. add set filter ssh_flood { type ipv4_addr; flags dynamic; } ]
</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>

Counters

2023-08-27T20:56:13Z

Pablo: incorrect syntax with protocol matching

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;

ip 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 ip 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.

Flowtables

2023-08-22T18:26:44Z

Pablo: update notes according to HTTP connection offload

Flowtables allow you to accelerate packet forwarding in software (and in hardware if your NIC supports it) by using a conntrack-based network stack bypass.

Entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4
protocols. Each entry also caches the destination interface and the gateway address (to update the destination link-layer address) to forward packets.

The TTL and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path.

<pre>
userspace process
^ |
| |
_____|____ ____\/___
/ \ / \
| input | | output |
\__________/ \_________/
^ |
| |
_________ __________ --------- _____\/_____
/ \ / \ |Routing | / \
--> ingress ---> prerouting ---> |decision| | postrouting|--> neigh_xmit
\_________/ \__________/ ---------- \____________/ ^
| ^ | ^ |
flowtable | ____\/___ | |
| | / \ | |
__\/___ | | forward |------------ |
|-----| | \_________/ |
|-----| | 'flow offload' rule |
|-----| | adds entry to |
|_____| | flowtable |
| | |
/ \ | |
/hit\_no_| |
\ ? / |
\ / |
|__yes_________________fastpath bypass ____________________________|

Fig.1 Netfilter hooks and flowtable interactions
</pre>

Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address [[Nftables_families|family]] and their name. The address family must be one of ip, ip6, or inet. When no address family is specified, ip is used by default.

Flows are offloaded after the state is created. That means that usually the first reply packet will create the flowtable entry.
A firewall rule to accept the initial traffic is required.
The flow expression on the forward chain must match the return traffic of the initial connection.
Be aware that the return route is deducted from the packet, that creates the flowtable entry.
This also means if you are using special ip rules, you need to make sure that they match the reply packet traffic as well as the original traffic.

The *priority* can be a signed integer or *filter* which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.

The *devices* are specified as [[Data_types|iifname]](s) of the input interface(s) of the traffic that should be offloaded. Devices are required for both traffic directions.

An Example to offload HTTP traffic for a router:

<pre>
define DEV_PRIVATE=eth0
define DEV_INTERNET=eth1

table inet x {

flowtable f {
hook ingress priority 0
devices = { $DEV_PRIVATE, $DEV_INTERNET }
}

chain forward {
type filter hook forward priority 0; policy drop;

# offload established HTTP connections
tcp dport { 80, 443 } ct state established flow offload @f counter packets 0 bytes 0

# Allow traffic from established and related packets, drop invalid
ct state vmap { established : accept, related : accept, invalid : drop }

# connections from the internal net to the internet or to other
# internal nets are allowed
iifname $DEV_PRIVATE counter accept
}
}
</pre>

Note that:

# The rule that uses the ''flow offload'' statement determines what flows are added to the flowtable. This ruleset above adds entries to the flowtable for established HTTP connections.
# The devices you specify in the flowtable declaration determine where the flowtable hooks in the pipeline for lookups, in the example above, it registers a hook for devices eth0 and eth0 in the ingress hook at priority 0.

== See also ==

* [https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Linux kernel documentation on Netfilter flowtable]
* [https://netdevconf.info/0x13/session.html?workshop-netfilter-mini Netfilter Mini-Workshop, Netdev 0x13, 2019-03]
* [https://lwn.net/Articles/804384/ Mellanox flowtable hardware offload]
* [https://www.programmersought.com/article/11833283913/ Some Mellanox flowtable hardware offload performance measurements by Wen Xu of UCloud]
* [https://linuxplumbersconf.org/event/4/contributions/463/ Netfilter hardware offloads, Pablo Neira Ayuso, Linux Plumbers Conference, 2019-09]

Flowtables

2023-08-22T18:25:19Z

Pablo: provide an example that offload HTTP traffic

Flowtables allow you to accelerate packet forwarding in software (and in hardware if your NIC supports it) by using a conntrack-based network stack bypass.

Entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4
protocols. Each entry also caches the destination interface and the gateway address (to update the destination link-layer address) to forward packets.

The TTL and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path.

<pre>
userspace process
^ |
| |
_____|____ ____\/___
/ \ / \
| input | | output |
\__________/ \_________/
^ |
| |
_________ __________ --------- _____\/_____
/ \ / \ |Routing | / \
--> ingress ---> prerouting ---> |decision| | postrouting|--> neigh_xmit
\_________/ \__________/ ---------- \____________/ ^
| ^ | ^ |
flowtable | ____\/___ | |
| | / \ | |
__\/___ | | forward |------------ |
|-----| | \_________/ |
|-----| | 'flow offload' rule |
|-----| | adds entry to |
|_____| | flowtable |
| | |
/ \ | |
/hit\_no_| |
\ ? / |
\ / |
|__yes_________________fastpath bypass ____________________________|

Fig.1 Netfilter hooks and flowtable interactions
</pre>

Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address [[Nftables_families|family]] and their name. The address family must be one of ip, ip6, or inet. When no address family is specified, ip is used by default.

Flows are offloaded after the state is created. That means that usually the first reply packet will create the flowtable entry.
A firewall rule to accept the initial traffic is required.
The flow expression on the forward chain must match the return traffic of the initial connection.
Be aware that the return route is deducted from the packet, that creates the flowtable entry.
This also means if you are using special ip rules, you need to make sure that they match the reply packet traffic as well as the original traffic.

The *priority* can be a signed integer or *filter* which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.

The *devices* are specified as [[Data_types|iifname]](s) of the input interface(s) of the traffic that should be offloaded. Devices are required for both traffic directions.

An Example to offload HTTP traffic for a router:

<pre>
define DEV_PRIVATE=eth0
define DEV_INTERNET=eth1

table inet x {

flowtable f {
hook ingress priority 0
devices = { $DEV_PRIVATE, $DEV_INTERNET }
}

chain forward {
type filter hook forward priority 0; policy drop;

# offload established HTTP connections
tcp dport { 80, 443 } ct state established flow offload @f counter packets 0 bytes 0

# Allow traffic from established and related packets, drop invalid
ct state vmap { established : accept, related : accept, invalid : drop }

# connections from the internal net to the internet or to other
# internal nets are allowed
iifname $DEV_PRIVATE counter accept
}
}
</pre>

Note that:

# The rule that uses the ''flow offload'' statement determines what flows are added to the flowtable. This ruleset above adds entries to the flowtable for TCP and UDP packets.
# The devices you specify in the flowtable declaration determine where the flowtable hooks in the pipeline for lookups, in the example above, it registers a hook for devices eth0 and eth0 in the ingress hook at priority 0.

== See also ==

* [https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Linux kernel documentation on Netfilter flowtable]
* [https://netdevconf.info/0x13/session.html?workshop-netfilter-mini Netfilter Mini-Workshop, Netdev 0x13, 2019-03]
* [https://lwn.net/Articles/804384/ Mellanox flowtable hardware offload]
* [https://www.programmersought.com/article/11833283913/ Some Mellanox flowtable hardware offload performance measurements by Wen Xu of UCloud]
* [https://linuxplumbersconf.org/event/4/contributions/463/ Netfilter hardware offloads, Pablo Neira Ayuso, Linux Plumbers Conference, 2019-09]

Flowtables

2023-08-22T18:05:50Z

Pablo: add a few notes

Flowtables allow you to accelerate packet forwarding in software (and in hardware if your NIC supports it) by using a conntrack-based network stack bypass.

Entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4
protocols. Each entry also caches the destination interface and the gateway address (to update the destination link-layer address) to forward packets.

The TTL and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path.

<pre>
userspace process
^ |
| |
_____|____ ____\/___
/ \ / \
| input | | output |
\__________/ \_________/
^ |
| |
_________ __________ --------- _____\/_____
/ \ / \ |Routing | / \
--> ingress ---> prerouting ---> |decision| | postrouting|--> neigh_xmit
\_________/ \__________/ ---------- \____________/ ^
| ^ | ^ |
flowtable | ____\/___ | |
| | / \ | |
__\/___ | | forward |------------ |
|-----| | \_________/ |
|-----| | 'flow offload' rule |
|-----| | adds entry to |
|_____| | flowtable |
| | |
/ \ | |
/hit\_no_| |
\ ? / |
\ / |
|__yes_________________fastpath bypass ____________________________|

Fig.1 Netfilter hooks and flowtable interactions
</pre>

Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address [[Nftables_families|family]] and their name. The address family must be one of ip, ip6, or inet. When no address family is specified, ip is used by default.

Flows are offloaded after the state is created. That means that usually the first reply packet will create the flowtable entry.
A firewall rule to accept the initial traffic is required.
The flow expression on the forward chain must match the return traffic of the initial connection.
Be aware that the return route is deducted from the packet, that creates the flowtable entry.
This also means if you are using special ip rules, you need to make sure that they match the reply packet traffic as well as the original traffic.

The *priority* can be a signed integer or *filter* which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.

The *devices* are specified as [[Data_types|iifname]](s) of the input interface(s) of the traffic that should be offloaded. Devices are required for both traffic directions.

Example:

<pre>
table inet x {

flowtable f {
hook ingress priority 0; devices = { eth0, eth1 };
}

chain forward {
type filter hook forward priority 0; policy drop;

# offload established connections
meta l4proto { tcp, udp } flow offload @f counter packets 0 bytes 0

# established/related connections
ct state established,related counter accept

# allow initial connection
meta l4proto { tcp, udp } accept
}
}
</pre>

Note that:

# The rule that uses the ''flow offload'' statement determines what flows are added to the flowtable. This ruleset above adds entries to the flowtable for TCP and UDP packets.
# The devices you specify in the flowtable declaration determine where the flowtable hooks in the pipeline for lookups, in the example above, it registers a hook for devices eth0 and eth0 in the ingress hook at priority 0.

== See also ==

* [https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Linux kernel documentation on Netfilter flowtable]
* [https://netdevconf.info/0x13/session.html?workshop-netfilter-mini Netfilter Mini-Workshop, Netdev 0x13, 2019-03]
* [https://lwn.net/Articles/804384/ Mellanox flowtable hardware offload]
* [https://www.programmersought.com/article/11833283913/ Some Mellanox flowtable hardware offload performance measurements by Wen Xu of UCloud]
* [https://linuxplumbersconf.org/event/4/contributions/463/ Netfilter hardware offloads, Pablo Neira Ayuso, Linux Plumbers Conference, 2019-09]

Meters

2023-08-15T21:58:54Z

Pablo: /* Dynamic set and map and stateful expressions */ minor edit

== Dynamic set/map and stateful expressions ==

If you specify the ''dynamic'' flag to your set/map declaration, you can add elements to your set/map from the packet path. You can also attach a ratelimit per byte/packet/connection, counter and quota to such elements.

Among other things, the combination of dynamic set/map and stateful expressions provide a lot more flexible replacement for the ''hashlimit'' and ''connlimit'' matches in iptables.

== Using meters ==

The following example shows to how ratelimit inbound TCP connections to port 22 per source IP address:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr
timeout 60s
flags dynamic
}

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

ct state new tcp dport 22 update @my_ssh_ratelimit { ip saddr limit rate 3/minute } accept
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it attaches a ratelimiter to such element. If the element already exists, the ratelimiter is applied and the timeout is refreshed to 60 seconds. After 60 seconds of no use, the element expires and the ratelimiter is released.

You can also use [[concatenations]] to ratelimit the inbound connections per IP source address and TCP destination port:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr . inet_service
timeout 60s
flags dynamic
}

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

ct state new update @my_ssh_ratelimit { ip saddr . tcp dport limit rate 3/minute } accept
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, ''ct count'' allows you to count the number of existing connections based on connection tracking table, you can use it to limit the maximum number of established connections.

<source lang="bash">
table ip filter {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain output {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it allows a maximum number of 20 established connections to such IP source address.

'''NOTE:''' This policy does not specifies a timeout to sets intentionally. The connection tracking table timers apply in this case. For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement. If you define a timeout to your set and use it with ''ct count'', you will hit an "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Meters

2023-08-15T21:58:12Z

Pablo: clarify dynamic flag

== Dynamic set and map and stateful expressions ==

If you specify the ''dynamic'' flag to your set/map declaration, you can add elements to your set/map from the packet path. You can also attach a ratelimit per byte/packet/connection, counter and quota to such elements.

Among other things, the combination of dynamic set/map and stateful expressions provide a lot more flexible replacement for the ''hashlimit'' and ''connlimit'' matches in iptables.

== Using meters ==

The following example shows to how ratelimit inbound TCP connections to port 22 per source IP address:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr
timeout 60s
flags dynamic
}

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

ct state new tcp dport 22 update @my_ssh_ratelimit { ip saddr limit rate 3/minute } accept
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it attaches a ratelimiter to such element. If the element already exists, the ratelimiter is applied and the timeout is refreshed to 60 seconds. After 60 seconds of no use, the element expires and the ratelimiter is released.

You can also use [[concatenations]] to ratelimit the inbound connections per IP source address and TCP destination port:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr . inet_service
timeout 60s
flags dynamic
}

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

ct state new update @my_ssh_ratelimit { ip saddr . tcp dport limit rate 3/minute } accept
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, ''ct count'' allows you to count the number of existing connections based on connection tracking table, you can use it to limit the maximum number of established connections.

<source lang="bash">
table ip filter {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain output {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it allows a maximum number of 20 established connections to such IP source address.

'''NOTE:''' This policy does not specifies a timeout to sets intentionally. The connection tracking table timers apply in this case. For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement. If you define a timeout to your set and use it with ''ct count'', you will hit an "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Meters

2023-08-15T21:31:59Z

Pablo: rewrite summary

== Meters ==

'''Dynamic sets/maps''' allow to add elements to the set/map from the packet path and to attach ratelimit per byte/packet/connection, counter and quota to such elements.

Among other things, they provide a lot more flexible replacement for the ''hashlimit'' and ''connlimit'' matches in iptables.

== Using meters ==

The following example shows to how ratelimit inbound TCP connections to port 22 per source IP address:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr
timeout 60s
flags dynamic
}

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

ct state new tcp dport 22 update @my_ssh_ratelimit { ip saddr limit rate 3/minute } accept
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it attaches a ratelimiter to such element. If the element already exists, the ratelimiter is applied and the timeout is refreshed to 60 seconds. After 60 seconds of no use, the element expires and the ratelimiter is released.

You can also use [[concatenations]] to ratelimit the inbound connections per IP source address and TCP destination port:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr . inet_service
timeout 60s
flags dynamic
}

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

ct state new update @my_ssh_ratelimit { ip saddr . tcp dport limit rate 3/minute } accept
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, ''ct count'' allows you to count the number of existing connections based on connection tracking table, you can use it to limit the maximum number of established connections.

<source lang="bash">
table ip filter {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain output {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it allows a maximum number of 20 established connections to such IP source address.

'''NOTE:''' This policy does not specifies a timeout to sets intentionally. The connection tracking table timers apply in this case. For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement. If you define a timeout to your set and use it with ''ct count'', you will hit an "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Meters

2023-08-15T21:26:45Z

Pablo: /* Doing connlimit with nft */ revisit example

== Meters ==

'''Dynamic sets/maps''' or meters are a way to use maps with stateful objects. They used to be known as ''flow tables'' before nft v0.8.1 and Linux kernel 4.3.

Among other things, they provide a native replacement for the ''hashlimit'' match in iptables. However, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

'''Note that the ''meter'' keyword is obsolete, the dynamic set and map syntax is now preferred for consistency.'''

== Using meters ==

The following example shows to how ratelimit inbound TCP connections to port 22 per source IP address:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr
timeout 60s
flags dynamic
}

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

ct state new tcp dport 22 update @my_ssh_ratelimit { ip saddr limit rate 3/minute } accept
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it attaches a ratelimiter to such element. If the element already exists, the ratelimiter is applied and the timeout is refreshed to 60 seconds. After 60 seconds of no use, the element expires and the ratelimiter is released.

You can also use [[concatenations]] to ratelimit the inbound connections per IP source address and TCP destination port:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr . inet_service
timeout 60s
flags dynamic
}

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

ct state new update @my_ssh_ratelimit { ip saddr . tcp dport limit rate 3/minute } accept
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, ''ct count'' allows you to count the number of existing connections based on connection tracking table, you can use it to limit the maximum number of established connections.

<source lang="bash">
table ip filter {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain output {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it allows a maximum number of 20 established connections to such IP source address.

'''NOTE:''' This policy does not specifies a timeout to sets intentionally. The connection tracking table timers apply in this case. For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement. If you define a timeout to your set and use it with ''ct count'', you will hit an "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Meters

2023-08-15T21:11:03Z

Pablo: /* Listing meters */ remove listing

== Meters ==

'''Dynamic sets/maps''' or meters are a way to use maps with stateful objects. They used to be known as ''flow tables'' before nft v0.8.1 and Linux kernel 4.3.

Among other things, they provide a native replacement for the ''hashlimit'' match in iptables. However, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

'''Note that the ''meter'' keyword is obsolete, the dynamic set and map syntax is now preferred for consistency.'''

== Using meters ==

The following example shows to how ratelimit inbound TCP connections to port 22 per source IP address:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr
timeout 60s
flags dynamic
}

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

ct state new tcp dport 22 update @my_ssh_ratelimit { ip saddr limit rate 3/minute } accept
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it attaches a ratelimiter to such element. If the element already exists, the ratelimiter is applied and the timeout is refreshed to 60 seconds. After 60 seconds of no use, the element expires and the ratelimiter is released.

You can also use [[concatenations]] to ratelimit the inbound connections per IP source address and TCP destination port:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr . inet_service
timeout 60s
flags dynamic
}

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

ct state new update @my_ssh_ratelimit { ip saddr . tcp dport limit rate 3/minute } accept
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, there is a new ''ct count'' selector that allows you to count the number of existing connections. This extension uses the information available in the Connection Tracking System table, therefore, the counting of connection is based on the existing entries in the table.

The following example shows how to do ''connlimit'' from nftables:

table ip my_filter_table {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain my_output_chain {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
}
}

The example above dynamically populates the set ''connlimit'' from the packet path. For the first packet of each connection (ie. packets matching ''ct state new''), this adds an entry into ''connlimit'' set, this entry uses the IPv4 destination address as a key. If the number of connections goes over 20, then packets are dropped.

Since ''connlimit'' is a set, you can perform any operation on it, such as listing and flushing its content.

'''Caveats''':
* Do not define a set with a timeout. There is a garbage collector that removes the set element whenever ''ct count'' becomes zero to improve memory usage.
* For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement.

If you define a set with a timeout or you use the ''update'' set statement, then you will hit the "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Meters

2023-08-15T21:09:02Z

Pablo: /* Using meters */ use nested notation and refine example

== Meters ==

'''Dynamic sets/maps''' or meters are a way to use maps with stateful objects. They used to be known as ''flow tables'' before nft v0.8.1 and Linux kernel 4.3.

Among other things, they provide a native replacement for the ''hashlimit'' match in iptables. However, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

'''Note that the ''meter'' keyword is obsolete, the dynamic set and map syntax is now preferred for consistency.'''

== Using meters ==

The following example shows to how ratelimit inbound TCP connections to port 22 per source IP address:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr
timeout 60s
flags dynamic
}

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

ct state new tcp dport 22 update @my_ssh_ratelimit { ip saddr limit rate 3/minute } accept
}
}
</source>

For each packet matching this rule, it adds an element to the set whose key is 'ip saddr' and it attaches a ratelimiter to such element. If the element already exists, the ratelimiter is applied and the timeout is refreshed to 60 seconds. After 60 seconds of no use, the element expires and the ratelimiter is released.

You can also use [[concatenations]] to ratelimit the inbound connections per IP source address and TCP destination port:

<source lang="bash">
table ip filter {
set my_ssh_ratelimit {
type ipv4_addr . inet_service
timeout 60s
flags dynamic
}

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

ct state new update @my_ssh_ratelimit { ip saddr . tcp dport limit rate 3/minute } accept
}
}
</source>

== Listing meters ==

To list the content matched by the meter use:

<source lang="bash">
% nft list set my_filter_table my_ssh_meter
table ip my_filter_table {
set my_ssh_meter {
type ipv4_addr
size 65535
flags dynamic
elements = { 10.141.10.2 limit rate 10/second }
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, there is a new ''ct count'' selector that allows you to count the number of existing connections. This extension uses the information available in the Connection Tracking System table, therefore, the counting of connection is based on the existing entries in the table.

The following example shows how to do ''connlimit'' from nftables:

table ip my_filter_table {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain my_output_chain {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
}
}

The example above dynamically populates the set ''connlimit'' from the packet path. For the first packet of each connection (ie. packets matching ''ct state new''), this adds an entry into ''connlimit'' set, this entry uses the IPv4 destination address as a key. If the number of connections goes over 20, then packets are dropped.

Since ''connlimit'' is a set, you can perform any operation on it, such as listing and flushing its content.

'''Caveats''':
* Do not define a set with a timeout. There is a garbage collector that removes the set element whenever ''ct count'' becomes zero to improve memory usage.
* For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement.

If you define a set with a timeout or you use the ''update'' set statement, then you will hit the "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Operations at ruleset level

2023-07-31T08:17:40Z

Pablo: fix incorrect flush ruleset

== Using native nft syntax ==

Linux Kernel 3.18 includes some improvements regarding the available operations to manage your ruleset as a whole.

=== listing ===

Listing the complete ruleset:
<source lang="bash">
% nft list ruleset
</source>

Listing the ruleset per family:
<source lang="bash">
% nft list ruleset arp
% nft list ruleset ip
% nft list ruleset ip6
% nft list ruleset bridge
% nft list ruleset inet
</source>
These commands will print all tables/chains/sets/rules of the given family.

=== flushing ===

In addition, you can also flush (erase, delete, wipe) the complete ruleset:
<source lang="bash">
% nft flush ruleset
</source>
Also per family:
<source lang="bash">
% nft flush ruleset arp
% nft flush ruleset ip
% nft flush ruleset ip6
% nft flush ruleset bridge
% nft flush ruleset inet
</source>
=== backup/restore ===

You can combine these two commands above to backup your ruleset:
<source lang="bash">
% echo "flush ruleset" > backup.nft
% nft list ruleset >> backup.nft
</source>
And load it [[Atomic_rule_replacement|atomically]]:
<source lang="bash">
% nft -f backup.nft
</source>
== Listing in JSON format ==

You can also export your ruleset in JSON format, just pass the
'--json' option:

<source lang="bash">
% nft --json list ruleset > ruleset.json
</source>

== See also ==

Some related information you may want to read:

* [[Atomic rule replacement]]
* [[Scripting]]

Scripting

2023-04-20T14:46:47Z

Pablo: /* Including files */

Many people like to maintain their ruleset in shell scripts, this allows them to add comments and arrange rules in more human-friendly way. This is problematic though since shell scripts break atomicity when applying the ruleset, thus, the filtering policy is applied in an inconsistent way during the ruleset loading time.

Fortunately, nftables provides a native scripting environment to address these concerns which basically allows you to include other ruleset files, define variables and add comments. You have to restore the content of this native script through the ''nft -f my-ruleset.file'' command.

To create a nftables script, you have to add the following header to your script file:

<source lang="bash">
#!/usr/sbin/nft -f
</source>

= Adding comments =

You can add comments to your file using the '#' character. Everything after the '#' will be ignored.

<source lang="bash">
#!/usr/sbin/nft -f

#
# table declaration
#
add table filter

#
# chain declaration
#
add chain filter input { type filter hook input priority 0; policy drop; }

#
# rule declaration
#
add rule filter input ct state established,related counter accept
</source>

= Including files =

Other files can be included by using the include statement. The directories to be searched for include files can be specified using the '''-I/--includepath''' option. You can override this behavior either by prepending ‘./’ to your path to force inclusion of
files located in the current working directory (i.e. relative path) or / for file location expressed as an absolute path.

If '''-I/--includepath''' is not specified, then nft relies on the default directory that is specified at compile time. You can retrieve this default directory via '''-h/--help''' option.

Include statements support the usual shell wildcard symbols (\*,?,[]). Having no matches for an include statement is not an error, if wildcard symbols are used in the include statement.

This allows having potentially empty include directories for statements like include "/etc/firewall/rules/".
The wildcard matches are loaded in alphabetical order.

'''NOTE:''' Files beginning with dot (.) are not matched by include statements.

<source lang="bash">
#!/usr/sbin/nft -f

# include a single file using the default search path
include "ipv4-nat.ruleset"

# include all files ending in *.nft in the default search path
include "*.nft"

# include all files in a given directory using an absolute path
include "/etc/nftables/*"
</source>

= Defining variables =

You can use the ''define'' keyword to define variables, the following example shows a very simple ruleset to account the traffic that comes from 8.8.8.8 (the popular Google DNS server):

<source lang="bash">
#!/usr/sbin/nft -f

define google_dns = 8.8.8.8

add table filter
add chain filter input { type filter hook input priority 0; }
add rule filter input ip saddr $google_dns counter
</source>

You can also define a variable for sets:

<source lang="bash">
#!/usr/sbin/nft -f

define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148, 138.100.62.8 }

add table filter
add chain filter input { type filter hook input priority 0; }
add rule filter input ip saddr $ntp_servers counter
</source>

Don't forget that brackets have special semantics when used from rules, since they indicate that this variable represents a set. Therefore, avoid things like:

<source lang="bash">
define google_dns = { 8.8.8.8 }
</source>

It is simply overkill to define a set that only stores one single element, instead use the singleton definition:

<source lang="bash">
define google_dns = 8.8.8.8
</source>

= File formats =

''nft -f <filename>'' accepts 2 formats, the first is the format seen in the output of ''nft list table''. The second is using the same syntax of calling the ''nft'' binary several times, but in an atomic fashion.

Example of nftables output format:

<source lang="bash">
#!/usr/sbin/nft -f

define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148, 138.100.62.8 }

#flush table nat
table ip nat {
chain prerouting {
type filter hook prerouting priority 0; policy accept;
ip saddr $ntp_servers counter
}

chain postrouting {
type filter hook postrouting priority 100; policy accept;
}
}
</source>

Example of scripted config format:

<source lang="bash">
#!/usr/sbin/nft -f

define ntp_servers = { 84.77.40.132, 176.31.53.99, 81.19.96.148, 138.100.62.8 }

add table filter
add chain filter input { type filter hook input priority 0; }
add rule filter input ip saddr $ntp_servers counter
</source>

You can freely translate between the two formats, as the syntax is mostly the same (only the organization differs).
Depending on your use case, you may want to use one format or other when building your firewall.

= Building an ''nft'' file from scripts =
Though not necessarily recommended, you can use your choice of scripting language to build a single text file in a format accepted by ''nft'' (see previous section), and then load the firewall configuration atomically with ''nft -f <your_file_in_nft_format>''. You may want to use this method if you are coordinating your ''nft'' configuration with that of other subsystems that use different file formats and command-line tools.

= Using nftables from Python =
The same functionality provided by the ''nft'' command-line utility is available from within Python programs via the high-level library libnftables. Please see the following for more information and examples:
* [https://ral-arturo.org/2020/11/22/python-nftables-tutorial.html How to use nftables from Python], Arturo Borrero, 2020-11-22;
* [https://github.com/aborrero/python-nftables-tutorial python nftables tutorial] code examples to accompany the above.

= See also =

This related information is very useful when dealing with nftables scripts:

* [[Atomic rule replacement]]
* [[Operations at ruleset level]]

Simple ruleset for a server

2022-01-31T17:34:46Z

Pablo: /* nftables.conf */ missing closing curly brace

Here's a very basic example for a web server, you can load the ruleset file with ''nft -f''.

= nftables.conf =

<syntaxhighlight lang="bash">
flush ruleset

table inet firewall {

chain inbound_ipv4 {
# accepting ping (icmp-echo-request) for diagnostic purposes.
# However, it also lets probes discover this host is alive.
# This sample accepts them within a certain rate limit:
#
# icmp type echo-request limit rate 5/second accept
}

chain inbound_ipv6 {
# accept neighbour discovery otherwise connectivity breaks
#
icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

# accepting ping (icmpv6-echo-request) for diagnostic purposes.
# However, it also lets probes discover this host is alive.
# This sample accepts them within a certain rate limit:
#
# icmpv6 type echo-request limit rate 5/second accept
}

chain inbound {

# By default, drop all traffic unless it meets a filter
# criteria specified by the rules that follow below.
type filter hook input priority 0; policy drop;

# Allow traffic from established and related packets, drop invalid
ct state vmap { established : accept, related : accept, invalid : drop }

# Allow loopback traffic.
iifname lo accept

# Jump to chain according to layer 3 protocol using a verdict map
meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }

# Allow SSH on port TCP/22 and allow HTTP(S) TCP/80 and TCP/443
# for IPv4 and IPv6.
tcp dport { 22, 80, 443} accept

# Uncomment to enable logging of denied inbound traffic
# log prefix "[nftables] Inbound Denied: " counter drop
}

chain forward {
# Drop everything (assumes this device is not a router)
type filter hook forward priority 0; policy drop;
}

# no need to define output chain, default policy is accept if undefined.
}
</syntaxhighlight>

Sets

2021-09-03T22:51:19Z

Pablo: add query for element s in a set

''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\;}
</source>

creates a set named ''blackhole''. Set names must be 16 characters or less. 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.

Matching packet headers

2021-08-31T11:41:27Z

Pablo: /* Matching transport protocol */ a bit more detailed explanation on how meta l4proto works

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>

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

To filter on a layer 4 protocol like TCP, you can match on the ''nexthdr'' field of the IPv6 header:

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

Caution when using ''ip6 nexthdr'', the value only refers to the next header, i.e. ip6 nexthdr tcp will only match if the ipv6 packet does not contain any extension headers.
Specifically, using ''ip6 nexthdr'' to match on IPv6 ICMP matching might break because quoting RFC2710:

MLD message types are a subset of the set of ICMPv6 messages, and MLD messages
are identified in IPv6 packets by a preceding Next Header value of 58.
All MLD messages described in this document are sent with a link-local IPv6
Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
[RTR-ALERT] in a Hop-by-Hop Options header.

a hop-by-hop extension header comes between the IPv6 header and the ICMPv6 header, hence, the nexthdr field shows 58 in that case.

You could use ''meta l4proto'' to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then ''nftables'' creates an implicit ''meta l4proto'' dependency that is not shown, therefore, there is no need for
being verbose in your notation, ie.

<source lang="bash">
% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
</source>

works fine to accept all ICMPv6 traffic regardless any possible extension headers.

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. For IPv6, ''meta l4proto'' also skips any extension header until the first transport protocol is found.

= 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>

Matching packet headers

2021-08-31T11:39:34Z

Pablo: /* Matching IPv6 headers */ another typo

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>

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

To filter on a layer 4 protocol like TCP, you can match on the ''nexthdr'' field of the IPv6 header:

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

Caution when using ''ip6 nexthdr'', the value only refers to the next header, i.e. ip6 nexthdr tcp will only match if the ipv6 packet does not contain any extension headers.
Specifically, using ''ip6 nexthdr'' to match on IPv6 ICMP matching might break because quoting RFC2710:

MLD message types are a subset of the set of ICMPv6 messages, and MLD messages
are identified in IPv6 packets by a preceding Next Header value of 58.
All MLD messages described in this document are sent with a link-local IPv6
Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
[RTR-ALERT] in a Hop-by-Hop Options header.

a hop-by-hop extension header comes between the IPv6 header and the ICMPv6 header, hence, the nexthdr field shows 58 in that case.

You could use ''meta l4proto'' to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then ''nftables'' creates an implicit ''meta l4proto'' dependency that is not shown, therefore, there is no need for
being verbose in your notation, ie.

<source lang="bash">
% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
</source>

works fine to accept all ICMPv6 traffic regardless any possible extension headers.

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>

Matching packet headers

2021-08-31T11:38:58Z

Pablo: /* Matching IPv6 headers */ fix typos and style

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>

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

To filter on a layer 4 protocol like TCP, you can match on the ''nexthdr'' field of the IPv6 header:

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

Caution when using ''ip6 nexthdr'', the value only refers to the next header, i.e. ip6 nexthdr tcp will only match if the ipv6 packet does not contain any extension headers.
Specifically, using ''ip6 nexthdr'' to match on IPv6 ICMP matching might break because quoting RFC2710:

MLD message types are a subset of the set of ICMPv6 messages, and MLD messages
are identified in IPv6 packets by a preceding Next Header value of 58.
All MLD messages described in this document are sent with a link-local IPv6
Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
[RTR-ALERT] in a Hop-by-Hop Options header.

a hop-by-hop extension header comes between the IPv6 header and the ICMPv6 header, hence, the nexthdr field shows 58 in that case.

You could use ''meta l4proto'' to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then ''nftables'' creates an implicit ''meta l4proto'' dependency that is not shown, therefore, there is not for
being verbose in your notation, ie.

<source lang="bash">
% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
</source>

works fine to accept all ICMPv6 traffic regardless any possible extension headers.

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>

Matching packet headers

2021-08-31T11:37:47Z

Pablo: /* Matching IPv6 headers */ refer to the ICMPv6 case

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>

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

To filter on a layer 4 protocol like TCP, you can match on the ''nexthdr'' field of the IPv6 header:

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

Caution when using ip6 nexthdr, the value only refers to the next header, i.e. ip6 nexthdr tcp will only match if the ipv6 packet does not contain any extension headers.

IPv6 ICMP matching might break because quoting RFC2710:

MLD message types are a subset of the set of ICMPv6 messages, and MLD messages
are identified in IPv6 packets by a preceding Next Header value of 58.
All MLD messages described in this document are sent with a link-local IPv6
Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
[RTR-ALERT] in a Hop-by-Hop Options header.

a hop-by-hop extension header comes between the IPv6 header and the ICMPv6 header, hence, the nexthdr field shows 58 in that case.

You could use ''meta l4proto'' to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then ''nftables'' creates an implicit ''meta l4proto'' dependency that is not shown, therefore, there is not for
being verbose in your notation, ie.

<source lang="bash">
% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
</source>

works fine to accept all ICMPv6 traffic regardless any possible extension headers.

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>

Simple ruleset for a workstation

2021-08-12T08:33:13Z

Pablo: remove echo request in IPv6 examples

A very simple set of rules that allows you to initiate communications from your workstation to the Internet but restricts any communication initiation to your workstation (that was not initiated by you).

You can load this file with nft -f.

= fw.basic =

For IPv4 only workstation.

<source lang="bash">
flush ruleset

table ip filter {
chain input {
type filter hook input priority 0; policy drop;

# accept traffic originated from us
ct state established,related accept

# accept any localhost traffic
iif lo accept
}
}
</source>

= fw6.basic =

For IPv6 only workstation.

<source lang="bash">
flush ruleset

table ip6 filter {
chain input {
type filter hook input priority 0; policy drop;

# accept any localhost traffic
iif lo accept

# accept traffic originated from us
ct state established,related accept

# accept neighbour discovery otherwise connectivity breaks
icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
}
}
</source>

= fw.inet.basic =

For dual-stack IPv4/IPv6 workstation.

<source lang="bash">
flush ruleset

table inet filter {
chain input {
type filter hook input priority 0; policy drop;

# accept any localhost traffic
iif lo accept

# accept traffic originated from us
ct state established,related accept

# accept neighbour discovery otherwise IPv6 connectivity breaks
icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

}
}
</source>

Simple ruleset for a server

2021-07-27T23:07:42Z

Pablo: /* nftables.conf */ add a note on PMTUD

Here's a very basic example of the nftables.conf file you might use on a web server. In this example, we have the option to block off all incoming traffic from the server except from "safe" IP ranges. This is handy if your server is behind CloudFlare, Sucuri, or other similar traffic filtering services.

'''Note:''' Initially, this conf allows all inbound traffic until you comment/uncomment the "From approved IP ranges only" section.

= nftables.conf =

<source lang="bash">
#!/usr/sbin/nft -f

flush ruleset

# List all IPs and IP ranges of your traffic filtering proxy source.
define SAFE_TRAFFIC_IPS = {
x.x.x.x/xx,
x.x.x.x/xx,
x.x.x.x,
x.x.x.x
}

table inet firewall {

chain inbound {

# By default, drop all traffic unless it meets a filter
# criteria specified by the rules that follow below.
type filter hook input priority 0; policy drop;

# Allow traffic from established and related packets.
ct state established,related accept

# Drop invalid packets.
ct state invalid drop

# Allow loopback traffic.
iifname lo accept

# Allow all ICMP and IGMP traffic, but enforce a rate limit
# to help prevent some types of flood attacks.
# Allowing ICMP is mandatory for Path MTU Discovery
ip protocol icmp limit rate 4/second accept
# Allowing ICMPv6 is mandatory for IPv6 to work
ip6 nexthdr ipv6-icmp limit rate 4/second accept
ip protocol igmp limit rate 4/second accept

# Allow SSH on port 22.
tcp dport 22 accept

# Allow HTTP(S).
# -- From anywhere
tcp dport { http, https } accept
udp dport { http, https } accept
# -- From approved IP ranges only
# tcp dport { http, https } ip saddr $SAFE_TRAFFIC_IPS accept
# udp dport { http, https } ip saddr $SAFE_TRAFFIC_IPS accept

# Uncomment to allow incoming traffic on other ports.
# -- Allow Jekyll dev traffic on port 4000.
# tcp dport 4000 accept
# -- Allow Hugo dev traffic on port 1313.
# tcp dport 1313 accept

# Uncomment to enable logging of denied inbound traffic
# log prefix "[nftables] Inbound Denied: " flags all counter drop

}

chain forward {

# Drop everything (assumes this device is not a router)
type filter hook forward priority 0; policy drop;

# Uncomment to enable logging of denied forwards
# log prefix "[nftables] Forward Denied: " flags all counter drop

}

chain outbound {

# Allow all outbound traffic
type filter hook output priority 0; policy accept;

}

}
</source>

Simple ruleset for a server

2021-07-27T22:56:57Z

Pablo: add comment regarding ICMPv6 (per Thomas Landauer)

Here's a very basic example of the nftables.conf file you might use on a web server. In this example, we have the option to block off all incoming traffic from the server except from "safe" IP ranges. This is handy if your server is behind CloudFlare, Sucuri, or other similar traffic filtering services.

'''Note:''' Initially, this conf allows all inbound traffic until you comment/uncomment the "From approved IP ranges only" section.

= nftables.conf =

<source lang="bash">
#!/usr/sbin/nft -f

flush ruleset

# List all IPs and IP ranges of your traffic filtering proxy source.
define SAFE_TRAFFIC_IPS = {
x.x.x.x/xx,
x.x.x.x/xx,
x.x.x.x,
x.x.x.x
}

table inet firewall {

chain inbound {

# By default, drop all traffic unless it meets a filter
# criteria specified by the rules that follow below.
type filter hook input priority 0; policy drop;

# Allow traffic from established and related packets.
ct state established,related accept

# Drop invalid packets.
ct state invalid drop

# Allow loopback traffic.
iifname lo accept

# Allow all ICMP and IGMP traffic, but enforce a rate limit
# to help prevent some types of flood attacks.
ip protocol icmp limit rate 4/second accept
# Allowing ICMPv6 is mandatory for IPv6 to work
ip6 nexthdr ipv6-icmp limit rate 4/second accept
ip protocol igmp limit rate 4/second accept

# Allow SSH on port 22.
tcp dport 22 accept

# Allow HTTP(S).
# -- From anywhere
tcp dport { http, https } accept
udp dport { http, https } accept
# -- From approved IP ranges only
# tcp dport { http, https } ip saddr $SAFE_TRAFFIC_IPS accept
# udp dport { http, https } ip saddr $SAFE_TRAFFIC_IPS accept

# Uncomment to allow incoming traffic on other ports.
# -- Allow Jekyll dev traffic on port 4000.
# tcp dport 4000 accept
# -- Allow Hugo dev traffic on port 1313.
# tcp dport 1313 accept

# Uncomment to enable logging of denied inbound traffic
# log prefix "[nftables] Inbound Denied: " flags all counter drop

}

chain forward {

# Drop everything (assumes this device is not a router)
type filter hook forward priority 0; policy drop;

# Uncomment to enable logging of denied forwards
# log prefix "[nftables] Forward Denied: " flags all counter drop

}

chain outbound {

# Allow all outbound traffic
type filter hook output priority 0; policy accept;

}

}
</source>

Nftables families

2021-07-23T16:19:05Z

Pablo: /* inet */ refer to meta l4proto

[https://netfilter.org/ Netfilter] enables filtering at multiple [https://en.wikipedia.org/wiki/Internet_protocol_suite networking levels]. With iptables there is a separate tool for each level: ''iptables'', ''ip6tables'', ''arptables'', ''ebtables''. With nftables the multiple networking levels are abstracted into '''families''', all of which are served by the single tool ''nft''.

Please note that what traffic/packets you see and at which point in the network stack depends on the [[Netfilter_hooks|'''hook''']] you are using.

Following are descriptions of current nftables families. Additional families may be added in the future.

== ip ==

Tables of this family see [https://en.wikipedia.org/wiki/IPv4 IPv4] traffic/packets.
The ''iptables'' tool is the legacy x_tables equivalent.

== ip6 ==

Tables of this family see [https://en.wikipedia.org/wiki/IPv6 IPv6] traffic/packets.
The ''ip6tables'' tool is the legacy x_tables equivalent.

== inet ==

Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.

Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets and vice-versa. Rules for both layer 3 protocols affect both. Use [[Matching_packet_headers#Matching_transport_protocol|meta l4proto]] to match on the layer 4 protocol regardless the packet is either IPv4 or IPv6.

Examples:
<source>
# This rule affects only IPv4 packets:
add rule inet filter input ip saddr 1.1.1.1 counter accept

# This rule affects only IPv6 packets:
add rule inet filter input ip6 daddr fe00::2 counter accept

# These rules affect both IPv4 and IPv6 packets:
add rule inet filter input ct state established,related counter accept
add rule inet filter input udp dport 53 accept
</source>

New in nftables 0.9.7 and Linux kernel 4.10 is the inet family [[Netfilter_hooks|''ingress'']] hook, which filters at the same location as the netdev ''ingress'' hook.

== arp ==

Tables of this family see [https://en.wikipedia.org/wiki/Address_Resolution_Protocol ARP]-level (i.e, L2) traffic, before any L3 handling is done by the kernel. The ''arptables'' tool is the legacy x_tables equivalent.

== bridge ==

Tables of this family see traffic/packets traversing [https://wiki.linuxfoundation.org/networking/bridge bridges] (i.e. switching). No assumptions are made about L3 protocols.

The ''ebtables'' tool is the legacy x_tables equivalent. Some old x_tables modules such as ''physdev'' will also eventually be served from the nftables ''bridge'' family.

Note that there is no nf_conntrack integration for the nftables ''bridge'' family.

== netdev ==

The ''netdev'' family is different from the others in that it is used to create base chains attached to a '''single network interface'''. Such base chains see '''all''' network traffic on the specified interface, with no assumptions about L2 or L3 protocols. Therefore you can filter ARP traffic from here. There is no legacy x_tables equivalent to the ''netdev'' family.

The principal (only?) use for this family is for base chains using the [[Netfilter_hooks|''ingress'' hook]], new in Linux kernel 4.2. Such ''ingress'' chains see network packets just after the NIC driver passes them up to the networking stack. This very early location in the packet path is ideal for dropping packets associated with [https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_attack DDoS] attacks. Dropping packets from an ''ingress'' chain is twice as efficient as doing so from a ''prerouting'' chain. (Do note that in an ''ingress'' chain, 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.

You can also use the ''ingress'' hook for [[load balancing]], including Direct Server Return (DSR), [https://netdevconf.org/1.2/slides/oct6/08_nftables_Load_Balancing_with_nftables_II_Slides.pdf that has been reported to be 10x faster].

Matching packet headers

2021-07-23T16:13:56Z

Pablo: /* Matching transport protocol */ document inet

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 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>

Quick reference-nftables in 10 minutes

2021-07-23T15:00:25Z

Pablo: /* Ct */ add ct count

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>
|-
| ''chunk <type>''
| Existence of a chunk with given type in packet
|<source lang="bash">
sctp chunk init exists
sctp chunk error missing
</source>
|-
| ''chunk <type> <field>''
| A chunk's field value (implies chunk existence)
|<sourcex lang="bash">
sctp chunk init flags 0x1
sctp chunk data tsn 0x23
</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>
|-
| | ''count [over] <number of connections>''
|
|<source lang="bash">
ct count over 2

tcp dport 22 add @ssh_flood { ip saddr ct count over 2 } reject
[ which requires an existing ssh_flood set, ie. add set filter ssh_flood { type ipv4_addr; flags dynamic; } ]
</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>

Meters

2021-07-05T20:36:32Z

Pablo: /* Doing connlimit with nft */ document caveats

== Meters ==

'''Dynamic sets/maps''' or meters are a way to use maps with stateful objects. They used to be known as ''flow tables'' before nft v0.8.1 and Linux kernel 4.3.

Among other things, they provide a native replacement for the ''hashlimit'' match in iptables. However, meters are a lot more flexible since you can use any selector, one or many through [[concatenations]].

'''Note that the ''meter'' keyword is obsolete, the dynamic set and map syntax is now preferred for consistency.'''

== Using meters ==

The following commands create a table named ''my_filter_table'', a chain named ''my_input_chain'' which hooks incoming traffic and a rule that uses a meter:

<source lang="bash">
% nft add table my_filter_table
% nft add chain my_filter_table my_input_chain {type filter hook input priority 0\;}
% nft add set my_filter_table my_ssh_meter { type ipv4_addr\; flags dynamic \;}
% nft add rule my_filter_table my_input_chain tcp dport 22 ct state new add @my_ssh_meter { ip saddr limit rate 10/second } accept
</source>

In this example we create a rule to match ''new'' TCP ''ssh'' (port 22) connections, which uses a dynamic set named ''my_ssh_meter'' to limit the traffic rate to 10 connections per second for each source IP address. The available time units on limits are: ''second'', ''minute'', ''hour'', ''day'' and ''week''.

You can also use [[concatenations]] to build selectors:

<source lang="bash">
% nft add set my_filter_table my_ssh_meter { type ipv4_addr . inet_service\; flags timeout, dynamic \;}
% nft add rule my_filter_table my_input_chain tcp dport 22 ct state new add @my_ssh_meter { ip saddr . tcp dport timeout 60s limit rate 10/second } accept
</source>

This rule counts incoming connections (packets with state ''new'') based on the tuple ''(IP source address, TCP destination port)'', the counters are dropped after 60 seconds without update.

== Listing meters ==

To list the content matched by the meter use:

<source lang="bash">
% nft list set my_filter_table my_ssh_meter
table ip my_filter_table {
set my_ssh_meter {
type ipv4_addr
size 65535
flags dynamic
elements = { 10.141.10.2 limit rate 10/second }
}
}
</source>

== Doing connlimit with nft ==

Since 4.18, there is a new ''ct count'' selector that allows you to count the number of existing connections. This extension uses the information available in the Connection Tracking System table, therefore, the counting of connection is based on the existing entries in the table.

The following example shows how to do ''connlimit'' from nftables:

table ip my_filter_table {
set my_connlimit {
type ipv4_addr
size 65535
flags dynamic
}

chain my_output_chain {
type filter hook output priority filter; policy accept;
ct state new add @my_connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
}
}

The example above dynamically populates the set ''connlimit'' from the packet path. For the first packet of each connection (ie. packets matching ''ct state new''), this adds an entry into ''connlimit'' set, this entry uses the IPv4 destination address as a key. If the number of connections goes over 20, then packets are dropped.

Since ''connlimit'' is a set, you can perform any operation on it, such as listing and flushing its content.

'''Caveats''':
* Do not define a set with a timeout. There is a garbage collector that removes the set element whenever ''ct count'' becomes zero to improve memory usage.
* For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement.

If you define a set with a timeout or you use the ''update'' set statement, then you will hit the "Operation is not supported" error.

== Doing iptables hashlimit with nft ==

Meters replace iptables hashlimit in nft. From iptables v1.6.2 onward, you can use the tool '''iptables-translate''' to see how to translate hashlimit rules.

Almost all hashlimit options are available in nft, starting with --hashlimit-mode, it is replaced by the selector in a meter. All modes are available except no mode, a meter demands a selector, an iptables rule without hashlimit-mode isn't supported in nft. A simple rule translation is:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200/sec --hashlimit-mode srcip,dstport --hashlimit-name http1 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http1 { tcp dport . ip saddr limit rate over 200/second } counter drop
</source>

Notice that a meter is named, like hashlimit, and using multiple hashlimit-modes is similar to using a concatenation of selectors. Also, --hashlimit-above is translated to ''limit rate over'', to simulate --hashlimit-upto just omit or replace ''over'' with ''until'' in the rule.

The options --hashlimit-burst and --hashlimit-htable-expire are translated to ''burst'' and ''timeout'' in a meter:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-above 200kb/s --hashlimit-burst 1mb --hashlimit-mode srcip,dstport --hashlimit-name http2 --hashlimit-htable-expire 3000 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http2 { tcp dport . ip saddr timeout 3s limit rate over 200 kbytes/second burst 1 mbytes} counter drop
</source>

This rule shows how ''timeout'' and ''burst'' are used in a meter, also notice that meters, similarly to hashlimit, accepts limiting rates by bytes frequency instead of packets.

Another hashlimit option is to limit the traffic rate on subnets, of IP source or destination addresses, using the options --hashlimit-srcmask and --hashlimit-dstmask. This feature is available in nft by attaching a subnet mask to a meter selector, attach to ''ip saddr'' for source address and to ''ip daddr'' for destination adress:

<source lang="bash">
$ iptables-translate -A INPUT -m tcp -p tcp --dport 80 -m hashlimit --hashlimit-upto 200 --hashlimit-mode srcip --hashlimit-name http3 --hashlimit-srcmask 24 -j DROP
nft add rule ip filter INPUT tcp dport 80 meter http3 { ip saddr and 255.255.255.0 limit rate 200/second } counter drop
</source>

This rule will limit packets rate, grouping subnets determined by the first 24 bits of the IP source address, from the incoming packets on port 80.

The remaining options, --hashlimit-htable-max, --hashlimit-htable-size and --hashlimit-htable-gcinterval don't apply to meters.

Connlimits

2021-07-05T20:35:38Z

Pablo: /* Using connlimits in dynamic sets and maps */ remove this example, the header is a hyperlink

Connlimits

2021-07-05T20:34:30Z

Pablo: /* Using connlimits in dynamic sets and maps */ add example and caveats

A connlimit in nftables is written ''ct count {over}'' [count]. Unlike other stateful object types, all connlimits are anonymous: each connlimit attaches to and applies within the context of a single rule or single element of a dynamic set or map.

A connlimit ''ct count {over}'' [count]:
<ol>
<li>counts the number of current conntrack connections matching its context;</li>
<li>matches either:
<ol style="list-style-type:lower-alpha">
<li>only when conntrack is currently tracking fewer than ''count'' matching connections, or</li>
<li>if ''over'' is specified, only when conntrack is currently tracking more than ''count'' matching connections.</li>
</ol>
</ol>

'''Note''': connlimits require at least nftables 0.9.0 and Linux kernel 4.19.10; using connlimits can crash the host when using earlier 4.19.x kernels.

= Using connlimits in rules =

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

tcp dport 22 ct count 10 accept
}
}
</source>

The above ruleset accepts packets to port tcp/22 (sshd), as long as conntrack is currently tracking no more than 10 such sshd connections. If a new SYN to tcp/22 arrives while conntrack already has 10 such connections, it will be dropped.

= [[Meters#Doing_connlimit_with_nft|Using connlimits in dynamic sets and maps]] =

You can also use connlimit in dynamic sets, this provides a scalable way to define connlimits per set element.

The following example shows how to allow up to 2 simultaneous connections to your host from one IP address.

<source lang="bash">
table ip filter {
set connlimit {
type ipv4_addr
flags dynamic
}

chain input {
type filter hook input priority filter; policy accept;
ct state new add @connlimit { ip saddr ct count over 2 } counter drop
}
}
</source>

Caveats:
* Do not define a set with a timeout. There is a garbage collector that removes the set element whenever ''ct count'' becomes zero to improve memory usage.
* For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement.

If you define a set with a timeout or you use the ''update'' set statement, then you will hit the "Operation is not supported" error.

Connlimits

2021-07-05T20:29:52Z

Pablo: /* Using connlimits in dynamic sets and maps */ add example and caveats

A connlimit in nftables is written ''ct count {over}'' [count]. Unlike other stateful object types, all connlimits are anonymous: each connlimit attaches to and applies within the context of a single rule or single element of a dynamic set or map.

A connlimit ''ct count {over}'' [count]:
<ol>
<li>counts the number of current conntrack connections matching its context;</li>
<li>matches either:
<ol style="list-style-type:lower-alpha">
<li>only when conntrack is currently tracking fewer than ''count'' matching connections, or</li>
<li>if ''over'' is specified, only when conntrack is currently tracking more than ''count'' matching connections.</li>
</ol>
</ol>

'''Note''': connlimits require at least nftables 0.9.0 and Linux kernel 4.19.10; using connlimits can crash the host when using earlier 4.19.x kernels.

= Using connlimits in rules =

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

tcp dport 22 ct count 10 accept
}
}
</source>

The above ruleset accepts packets to port tcp/22 (sshd), as long as conntrack is currently tracking no more than 10 such sshd connections. If a new SYN to tcp/22 arrives while conntrack already has 10 such connections, it will be dropped.

= [[Meters#Doing_connlimit_with_nft|Using connlimits in dynamic sets and maps]] =

You can also use connlimit in dynamic sets, this provides a scalable way to define connlimits per set element.

The following example shows how to allow up to 2 simultaneous connections to your host from one IP address.

<source lang="bash">
table ip filter {
set connlimit {
type ipv4_addr
flags dynamic
}

chain input {
type filter hook input priority filter; policy accept;
ct state new add @connlimit { ip saddr ct count over 2 } counter packets 6 bytes 504 drop
}
}
</source>

Caveats:
* Do not define a set with a timeout. There is a garbage collector that removes the set element whenever ''ct count'' becomes zero to improve memory usage.
* For the same reason, you cannot use the ''update'' set statement which allows to refresh the timeout of your set element. Therefore, the ''ct count'' statement can only be used with the ''add'' set statement.

If you define a set with a timeout or you use the ''update'' set statement, then you will hit the "Operation is not supported" error.

Moving from ipset to nftables

2021-06-28T11:01:54Z

Pablo:

If you use [[ipset]] with iptables, you need to consider the following when [[Moving from iptables to nftables | moving to nftables]]:

* Since ipset 7.12, there is the ''ipset-translate'' utility that automatically transform ipsets into nftables [[Sets|sets]]. This utility translates ipset set types into nftables set data types, which will often result in [[Concatenations | concatenated]] types. For example, an ipset of type ''hash:net,port,net'' becomes an nftables set of type ''ipv4_addr . inet_service . ipv4_addr''.

* nftables sets do not support negated elements, as with ipset ''nomatch''. To translate an ipset that has ''nomatch'' elements you can use a pair of nftables sets, one for the usual positive elements and one for negated elements, along with compound rule expressions like ''ip saddr @pos_set  ip saddr != @neg_set''.

* After the initial translation, it is recommended to have a look at nftables [[Maps|maps]] and [[Verdict_Maps_(vmaps)|verdict maps]] to make your ruleset more efficient.

The translation from ipset to nftables is straightforward with the ''ipset-translate'' utility:

<source lang="bash">
ipset-translate restore < sets.ipset
</source>

Following is an example of translating a basic iptables/ipset configuration into nftables.

Here is the iptables/ipset setup:
<source>
user@debian:~ $ sudo ipset save > sets.ipset
user@debian:~ $ sudo cat sets.ipset
create myset hash:ip,port,ip family inet hashsize 1024 maxelem 65536
add myset 172.16.0.1,tcp:80,10.0.0.1

user@debian:~ $ sudo ipset-translate restore < sets.ipset
add table inet global
add set inet global myset { type ipv4_addr . inet_proto . inet_service . ipv4_addr; size 65536; }
add element inet global myset { 172.16.0.1 . tcp . 80 . 10.0.0.1 }
</source>

The translation utility defines a dummy ''inet'' table whose name is ''global'', you can mangle this output to make it fit into your existing ruleset.

Now, you have to manually translate the rules that contain ''-m set'' in your ruleset:

<source lang="bash">
user@debian:~ $ sudo iptables-save
# Generated by iptables-save v1.8.3 on Wed Oct 30 11:26:41 2019
*filter
:INPUT ACCEPT [3:212]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:250]
-A INPUT -m set --match-set myset src,dst,dst -j ACCEPT
COMMIT
</source>

The above translates into nftables as:

<source>
user@debian:~ $ sudo nft list ruleset
table inet filter {
map myset {
type ipv4_addr . inet_service . ipv4_addr : verdict
elements = { 172.16.0.1 . 80 . 10.0.0.1 : accept }
}

chain input {
type filter hook input priority filter; policy accept;
meta nfproto ipv4 ip saddr . tcp dport . ip daddr vmap @myset
}
}
</source>

Note that we have used an nftables [[Verdict_Maps_(vmaps)|verdict map]], which takes action directly from each map element. Using such powerful new structures can greatly reduce the number of rules required by your filtering policy, compared with iptables/ipset.

We recommend reading about [[Concatenations | concatenations]].

Here are some additional examples of nftables equivalents for some ipset data types:

'''hash:net,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . ip daddr vmap { 10.10.10.0/24 . 10.10.20.0/24 : accept }
</source>

'''hash:net,port,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . tcp dport . ip daddr vmap { 10.10.10.0/24 . 80 . 10.10.20.0/24 : accept }
</source>

'''hash:net,iface'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . iif vmap { 10.10.10.0/24 . eth0 : accept }
</source>

NOTE that before Linux kernel 5.6 and nftables 0.9.4 the CIDR notation used above was not yet available. If you are unable to upgrade, you can work around this limitation as noted in the [[Concatenations#Network_addresses|concatenation examples]].

== See also ==

* [[Concatenations]]
* [[Sets]]
* [[Maps]]
* [[Verdict_Maps_(vmaps) | Verdict maps]]
* [[Legacy xtables tools]]

Moving from ipset to nftables

2021-06-28T11:00:00Z

Pablo: incorrect ipset-translate syntax in example

If you use [[ipset]] with iptables, you need to consider the following when [[Moving from iptables to nftables | moving to nftables]]:

* Since ipset 7.12, there is the ''ipset-translate'' utility that automatically transform ipsets into nftables [[Sets|sets]]. This utility translates ipset set types into nftables set data types, which will often result in [[Concatenations | concatenated]] types. For example, an ipset of type ''hash:net,port,net'' becomes an nftables set of type ''ipv4_addr . inet_service . ipv4_addr''.

* nftables sets do not support negated elements, as with ipset ''nomatch''. To translate an ipset that has ''nomatch'' elements you can use a pair of nftables sets, one for the usual positive elements and one for negated elements, along with compound rule expressions like ''ip saddr @pos_set  ip saddr != @neg_set''.

* After the initial translation, it is recommended to have a look at nftables [[Maps|maps]] and [[Verdict_Maps_(vmaps)|verdict maps]] to make your ruleset more efficient.

The translation from ipset to nftables is straightforward with the ''ipset-translate'' utility:

<source lang="bash">
ipset-translate restore < sets.ipset
</source>

Following is an example of translating a basic iptables/ipset configuration into nftables.

Here is the iptables/ipset setup:
<source>
user@debian:~ $ sudo ipset save > sets.ipset
user@debian:~ $ sudo cat sets.ipset
create myset hash:ip,port,ip family inet hashsize 1024 maxelem 65536
add myset 172.16.0.1,tcp:80,10.0.0.1

user@debian:~ $ sudo ipset-translate restore < sets.ipset
add table inet global
add set inet global myset { type ipv4_addr . inet_proto . inet_service . ipv4_addr; size 65536; }
add element inet global myset { 172.16.0.1 . tcp . 80 . 10.0.0.1 }
</source>

Now, you have to manually translate the rules that contain ''-m set'' in your ruleset:

<source lang="bash">
user@debian:~ $ sudo iptables-save
# Generated by iptables-save v1.8.3 on Wed Oct 30 11:26:41 2019
*filter
:INPUT ACCEPT [3:212]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:250]
-A INPUT -m set --match-set myset src,dst,dst -j ACCEPT
COMMIT
</source>

The above translates into nftables as:

<source>
user@debian:~ $ sudo nft list ruleset
table inet filter {
map myset {
type ipv4_addr . inet_service . ipv4_addr : verdict
elements = { 172.16.0.1 . 80 . 10.0.0.1 : accept }
}

chain input {
type filter hook input priority filter; policy accept;
meta nfproto ipv4 ip saddr . tcp dport . ip daddr vmap @myset
}
}
</source>

Note that we have used an nftables [[Verdict_Maps_(vmaps)|verdict map]], which takes action directly from each map element. Using such powerful new structures can greatly reduce the number of rules required by your filtering policy, compared with iptables/ipset.

We recommend reading about [[Concatenations | concatenations]].

Here are some additional examples of nftables equivalents for some ipset data types:

'''hash:net,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . ip daddr vmap { 10.10.10.0/24 . 10.10.20.0/24 : accept }
</source>

'''hash:net,port,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . tcp dport . ip daddr vmap { 10.10.10.0/24 . 80 . 10.10.20.0/24 : accept }
</source>

'''hash:net,iface'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . iif vmap { 10.10.10.0/24 . eth0 : accept }
</source>

NOTE that before Linux kernel 5.6 and nftables 0.9.4 the CIDR notation used above was not yet available. If you are unable to upgrade, you can work around this limitation as noted in the [[Concatenations#Network_addresses|concatenation examples]].

== See also ==

* [[Concatenations]]
* [[Sets]]
* [[Maps]]
* [[Verdict_Maps_(vmaps) | Verdict maps]]
* [[Legacy xtables tools]]

Moving from ipset to nftables

2021-06-28T10:58:39Z

Pablo: update article to document the new ipset-translate utility

If you use [[ipset]] with iptables, you need to consider the following when [[Moving from iptables to nftables | moving to nftables]]:

* Since ipset 7.12, there is the ''ipset-translate'' utility that automatically transform ipsets into nftables [[Sets|sets]]. This utility translates ipset set types into nftables set data types, which will often result in [[Concatenations | concatenated]] types. For example, an ipset of type ''hash:net,port,net'' becomes an nftables set of type ''ipv4_addr . inet_service . ipv4_addr''.

* nftables sets do not support negated elements, as with ipset ''nomatch''. To translate an ipset that has ''nomatch'' elements you can use a pair of nftables sets, one for the usual positive elements and one for negated elements, along with compound rule expressions like ''ip saddr @pos_set  ip saddr != @neg_set''.

* After the initial translation, it is recommended to have a look at nftables [[Maps|maps]] and [[Verdict_Maps_(vmaps)|verdict maps]] to make your ruleset more efficient.

The translation from ipset to nftables is straightforward with the ''ipset-translate'' utility:

<source lang="bash">
ipset-translate restore sets.ipset > sets.nft
</source>

Following is an example of translating a basic iptables/ipset configuration into nftables.

Here is the iptables/ipset setup:
<source>
user@debian:~ $ sudo ipset save > sets.ipset
user@debian:~ $ sudo cat sets.ipset
create myset hash:ip,port,ip family inet hashsize 1024 maxelem 65536
add myset 172.16.0.1,tcp:80,10.0.0.1

user@debian:~ $ sudo ipset-translate restore < sets.ipset
add table inet global
add set inet global myset { type ipv4_addr . inet_proto . inet_service . ipv4_addr; size 65536; }
add element inet global myset { 172.16.0.1 . tcp . 80 . 10.0.0.1 }
</source>

Now, you have to manually translate the rules that contain ''-m set'' in your ruleset:

<source lang="bash">
user@debian:~ $ sudo iptables-save
# Generated by iptables-save v1.8.3 on Wed Oct 30 11:26:41 2019
*filter
:INPUT ACCEPT [3:212]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:250]
-A INPUT -m set --match-set myset src,dst,dst -j ACCEPT
COMMIT
</source>

The above translates into nftables as:

<source>
user@debian:~ $ sudo nft list ruleset
table inet filter {
map myset {
type ipv4_addr . inet_service . ipv4_addr : verdict
elements = { 172.16.0.1 . 80 . 10.0.0.1 : accept }
}

chain input {
type filter hook input priority filter; policy accept;
meta nfproto ipv4 ip saddr . tcp dport . ip daddr vmap @myset
}
}
</source>

Note that we have used an nftables [[Verdict_Maps_(vmaps)|verdict map]], which takes action directly from each map element. Using such powerful new structures can greatly reduce the number of rules required by your filtering policy, compared with iptables/ipset.

We recommend reading about [[Concatenations | concatenations]].

Here are some additional examples of nftables equivalents for some ipset data types:

'''hash:net,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . ip daddr vmap { 10.10.10.0/24 . 10.10.20.0/24 : accept }
</source>

'''hash:net,port,net'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . tcp dport . ip daddr vmap { 10.10.10.0/24 . 80 . 10.10.20.0/24 : accept }
</source>

'''hash:net,iface'''

<source lang="bash">
% nft add rule tablename chainname ip saddr . iif vmap { 10.10.10.0/24 . eth0 : accept }
</source>

NOTE that before Linux kernel 5.6 and nftables 0.9.4 the CIDR notation used above was not yet available. If you are unable to upgrade, you can work around this limitation as noted in the [[Concatenations#Network_addresses|concatenation examples]].

== See also ==

* [[Concatenations]]
* [[Sets]]
* [[Maps]]
* [[Verdict_Maps_(vmaps) | Verdict maps]]
* [[Legacy xtables tools]]

Multiple NATs using nftables maps

2021-06-21T12:56:35Z

Pablo: /* Multiple NAT mapping with address and port */

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>

= Multiple NAT mapping with address and port =

You might also need to define a NAT mapping that includes the IP address and port, such as:

<source lang="bash">
% nft add map nat foo { type inet_service : ipv4_addr . inet_service ; }
% nft add element nat foo { \
1100 : 192.168.1.2 . 5061, \
1101 : 192.168.1.3 . 5061, \
1400 : 192.168.1.4 . 5061 \
}
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map @foo
</source>

If your mapping does not need to be updated, you could use a anonymous map in your rule instead:

<source lang="bash">
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map { \
1100 : 192.168.1.2 . 5061, \
1101 : 192.168.1.3 . 5061, \
1400 : 192.168.1.4 . 5061 \
}
</source>

== See also ==

* [[Performing_Network_Address_Translation_(NAT) | Performing NAT with nftables]]

Multiple NATs using nftables maps

2021-06-21T12:56:08Z

Pablo: /* Multiple NAT mapping with address and port */ missing source tag

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>

= Multiple NAT mapping with address and port =

You might also need to define a NAT mapping that includes the IP address and port, such as:

<source lang="bash">
% nft add map nat foo { type inet_service : ipv4_addr . inet_service ; }
% nft add element nat foo { \
1100 : 192.168.1.2 . 5061, \
1101 : 192.168.1.3 . 5061, \
1400 : 192.168.1.4 . 5061 \
}
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map @foo
</source>

If your mapping does not need to be updated, you could use a anonymous map in your rule instead:

<source lang="bash">
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map { 1100 : 192.168.1.2 . 5061, 1101 : 192.168.1.3 . 5061, 1400 : 192.168.1.4 . 5061 }
</source>

== See also ==

* [[Performing_Network_Address_Translation_(NAT) | Performing NAT with nftables]]

Multiple NATs using nftables maps

2021-06-21T12:55:39Z

Pablo: /* Multiple NAT mapping with address and port */ add example for anonymous map

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>

= Multiple NAT mapping with address and port =

You might also need to define a NAT mapping that includes the IP address and port, such as:

<source lang="bash">
% nft add map nat foo { type inet_service : ipv4_addr . inet_service ; }
% nft add element nat foo { \
1100 : 192.168.1.2 . 5061, \
1101 : 192.168.1.3 . 5061, \
1400 : 192.168.1.4 . 5061 \
}
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map @foo
</source>

If your mapping does not need to be updated, you could use a anonymous map in your rule instead:

% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map { 1100 : 192.168.1.2 . 5061, 1101 : 192.168.1.3 . 5061, 1400 : 192.168.1.4 . 5061 }

== See also ==

* [[Performing_Network_Address_Translation_(NAT) | Performing NAT with nftables]]

Multiple NATs using nftables maps

2021-06-21T12:43:37Z

Pablo: /* multiple NAT mapping with address and port */ minor comestic

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>

= Multiple NAT mapping with address and port =

You might also need to define a NAT mapping that includes the IP address and port, such as:

<source lang="bash">
% nft add map nat foo { type inet_service : ipv4_addr . inet_service ; }
% nft add element nat foo { \
1100 : 192.168.1.2 . 5061, \
1101 : 192.168.1.3 . 5061, \
1400 : 192.168.1.4 . 5061 \
}
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map @foo
</source>

== See also ==

* [[Performing_Network_Address_Translation_(NAT) | Performing NAT with nftables]]

Multiple NATs using nftables maps

2021-06-21T12:42:09Z

Pablo: multiple NAT mapping with address and port

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>

= multiple NAT mapping with address and port =

You might also need to define a NAT mapping that includes the IP address and port mapping, such as:

<source lang="bash">
% nft add map nat foo { type inet_service : ipv4_addr . inet_service ; }
% nft add element nat foo { \
1100 : 192.168.1.2 . 5061, \
1101 : 192.168.1.3 . 5061, \
1400 : 192.168.1.4 . 5061 \
}
% nft add rule nat pre ip protocol udp dnat ip addr . port to udp dport map @foo
</source>

== See also ==

* [[Performing_Network_Address_Translation_(NAT) | Performing NAT with nftables]]

Main Page

2021-06-12T20:07:39Z

Pablo: /* Examples */

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]]
* [[Simple ruleset for a router]]
* [[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.

Flowtables

2021-05-27T18:39:22Z

Pablo:

'''NOTE''': [[Meters]] were formerly known as flowtables before nftables 0.8.1 release. Now they are 2 separated, unrelated things.

Flowtables allow you to accelerate packet forwarding in software (and in hardware if your NIC supports it) by using a conntrack-based network stack bypass.

Entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4
protocols. Each entry also caches the destination interface and the gateway address (to update the destination link-layer address) to forward packets.

The TTL and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path.

<pre>
userspace process
^ |
| |
_____|____ ____\/___
/ \ / \
| input | | output |
\__________/ \_________/
^ |
| |
_________ __________ --------- _____\/_____
/ \ / \ |Routing | / \
--> ingress ---> prerouting ---> |decision| | postrouting|--> neigh_xmit
\_________/ \__________/ ---------- \____________/ ^
| ^ | ^ |
flowtable | ____\/___ | |
| | / \ | |
__\/___ | | forward |------------ |
|-----| | \_________/ |
|-----| | 'flow offload' rule |
|-----| | adds entry to |
|_____| | flowtable |
| | |
/ \ | |
/hit\_no_| |
\ ? / |
\ / |
|__yes_________________fastpath bypass ____________________________|

Fig.1 Netfilter hooks and flowtable interactions
</pre>

Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address [[Nftables_families|family]] and their name. The address family must be one of ip, ip6, or inet. When no address family is specified, ip is used by default.

Flows are offloaded after the state is created. A firewall rule to accept the initial traffic is required.
The flow expression on the forward chain must match the return traffic of the initial connection.

The *priority* can be a signed integer or *filter* which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.

The *devices* are specified as [[Data_types|iifname]](s) of the input interface(s) of the traffic that should be offloaded. Devices are required for both traffic directions.

Example:

<pre>
table inet x {

flowtable f {
hook ingress priority 0 devices = { eth0, eth1 };
}

chain forward {
type filter hook forward priority 0; policy drop;

# offload established connections
ip protocol { tcp, udp } flow offload @f
ip6 nexthdr { tcp, udp } flow offload @f
counter packets 0 bytes 0

# established/related connections
ct state established,related counter accept

# allow initial connection
ip protocol { tcp, udp } accept
ip6 nexthdr { tcp, udp } accept
}
}
</pre>

== See also ==

* [https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html Linux kernel documentation on Netfilter flowtable]
* [https://netdevconf.info/0x13/session.html?workshop-netfilter-mini Netfilter Mini-Workshop, Netdev 0x13, 2019-03]
* [https://lwn.net/Articles/804384/ Mellanox flowtable hardware offload]
* [https://www.programmersought.com/article/11833283913/ Some Mellanox flowtable hardware offload performance measurements by Wen Xu of UCloud]
* [https://linuxplumbersconf.org/event/4/contributions/463/ Netfilter hardware offloads, Pablo Neira Ayuso, Linux Plumbers Conference, 2019-09]

Mangling packet headers

2021-05-03T21:27:30Z

Pablo: /* Mangling TCP options */ remove oifname pppoe0, see note regarding mangling TCP MSS option

Since nft v0.6 nftables supports packet header mangling, including stateless NAT.

'''Note''': if you mangle packet fields that are included in the [https://en.wikipedia.org/wiki/User_Datagram_Protocol#IPv4_Pseudo_Header layer 4 checksum pseudoheader], then you require a Linux kernel version >= 4.10.

To mangle packet header fields you should create a rule to match the packet, match the desired header field and set a new value to it:

<source lang="bash">
% nft add table raw
% nft add chain raw prerouting {type filter hook prerouting priority -300\;}
% nft add rule raw prerouting tcp dport 8080 tcp dport set 80
</source>

The commands above create a table named ''raw'', a chain named ''prerouting'', see [[Netfilter hooks]], and a rule to mangle the destination port of packets over TCP from 8080 to 80.

== Mangling TCP options ==

Since Linux kernel 4.14 and nftables 0.9, you can clamp your TCP MSS to Path MTU. This is very convenient in case your router encapsulates traffic over PPPoE, which is what many DSL (and some FTTH) providers do:

<source lang="bash">
nft add rule ip filter forward tcp flags syn tcp option maxseg size set rt mtu
</source>

where '''rt mtu''' calculates the MTU in runtime based on what the routing cache has observed via Path MTU Discovery (PMTUD).

Note: The TCP maximum segment size is announced through TCP options in the original syn and the reply syn+ack packets. TCP maximum segment size is not negotiated, the RFC specifies that it is possible to have different TCP maximum segment size in each direction of the flow. Therefore, make sure you mangle both the TCP options of the original syn and the reply syn+ack packets.

Note for iptables users: 'tcp option maxseg size set rt mtu' is equivalent to '-j TCPMSS --clamp-mss-to-pmtu'.

You can also manually set to fixed value, eg. PPPoE takes 8 bytes to encapsulate packets, therefore, assuming MTU of 1500 bytes, 1500 - 20 (IPv4 Header) - 20 (TCP header) - 8 (PPPoE header) = 1452 bytes:

<source lang="bash">
nft add rule ip filter forward tcp flags syn tcp option maxseg size set 1452
</source>

Other supported TCP options are: window, sack-permitted, sack, timestamp and eol.

== Interactions with conntrack ==

Keep in mind the interactions with conntrack, flows with mangled traffic must be [[Setting packet connection tracking metainformation | untracked]]. You can do this in a single rule:

<source>
% nft add rule ip6 raw prerouting ip6 daddr fd00::1 ip6 daddr set fd00::2 notrack
</source>

For more information about packet headers to mangle check manpage nft(8), [[Matching packet headers]] and [[Quick reference-nftables in 10 minutes]].

Mangling packet headers

2021-05-03T21:26:20Z

Pablo: /* Mangling TCP options */ fix example rule regarding TCP MSS mangling

Since nft v0.6 nftables supports packet header mangling, including stateless NAT.

'''Note''': if you mangle packet fields that are included in the [https://en.wikipedia.org/wiki/User_Datagram_Protocol#IPv4_Pseudo_Header layer 4 checksum pseudoheader], then you require a Linux kernel version >= 4.10.

To mangle packet header fields you should create a rule to match the packet, match the desired header field and set a new value to it:

<source lang="bash">
% nft add table raw
% nft add chain raw prerouting {type filter hook prerouting priority -300\;}
% nft add rule raw prerouting tcp dport 8080 tcp dport set 80
</source>

The commands above create a table named ''raw'', a chain named ''prerouting'', see [[Netfilter hooks]], and a rule to mangle the destination port of packets over TCP from 8080 to 80.

== Mangling TCP options ==

Since Linux kernel 4.14 and nftables 0.9, you can clamp your TCP MSS to Path MTU. This is very convenient in case your router encapsulates traffic over PPPoE, which is what many DSL (and some FTTH) providers do:

<source lang="bash">
nft add rule ip filter forward tcp flags syn tcp option maxseg size set rt mtu
</source>

where '''rt mtu''' calculates the MTU in runtime based on what the routing cache has observed via Path MTU Discovery (PMTUD).

Note: The TCP maximum segment size is announced through TCP options in the original syn and the reply syn+ack packets. TCP maximum segment size is not negotiated, the RFC specifies that it is possible to have different TCP maximum segment size in each direction of the flow. Therefore, make sure you mangle both the TCP options of the original syn and the reply syn+ack packets.

Note for iptables users: 'tcp option maxseg size set rt mtu' is equivalent to '-j TCPMSS --clamp-mss-to-pmtu'.

You can also manually set to fixed value, eg. PPPoE takes 8 bytes to encapsulate packets, therefore, assuming MTU of 1500 bytes, 1500 - 20 (IPv4 Header) - 20 (TCP header) - 8 (PPPoE header) = 1452 bytes:

<source lang="bash">
nft add rule ip filter forward oifname ppp0 tcp flags syn tcp option maxseg size set 1452
</source>

Other supported TCP options are: window, sack-permitted, sack, timestamp and eol.

== Interactions with conntrack ==

Keep in mind the interactions with conntrack, flows with mangled traffic must be [[Setting packet connection tracking metainformation | untracked]]. You can do this in a single rule:

<source>
% nft add rule ip6 raw prerouting ip6 daddr fd00::1 ip6 daddr set fd00::2 notrack
</source>

For more information about packet headers to mangle check manpage nft(8), [[Matching packet headers]] and [[Quick reference-nftables in 10 minutes]].

Netfilter hooks

2021-02-08T02:09:57Z

Pablo: add schematic to represent hooks (contributed by Francisco Javier Rodríguez López)

If you are familiar with Netfilter, don't worry, most of the infrastructure remains the same. ''nftables'' reuses the existing hook infrastructure, [http://people.netfilter.org/pablo/docs/login.pdf Connection Tracking System], NAT engine, logging infrastructure, userspace queueing and so on. Therefore, '''we have only replaced the packet classification framework'''.

For those unfamiliar with Netfilter, we provide the following schematic for the packet flow paths through Linux networking:

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

Basically, traffic flowing to the local machine in the input path see 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 router, do not forget to enable forwarding via:

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

And then, the packets that are not addressed to your local system will be seen from the forward hook. In summary, packets that are not addressed to local processes follow this path: prerouting, forward and postrouting.

= Ingress hook =

Since Linux kernel 4.2, Netfilter also comes with an ingress hook that you can use from nftables. So the big picture now look like this:

.-----------.
| |-----> input ...
---> ingress ---> prerouting --->| Routing |
| Decision |
| |
| |-----> forward ...
.-----------.

You can use this new ingress hook to filter traffic from Layer 2. This new hook comes before prerouting, so this allows you to enforce very early filtering policies. This new hook basically provides an alternative to '''tc''' ingress filtering. You still need tc for traffic shaping/queue management.

Quick reference-nftables in 10 minutes

2021-01-15T22:29:10Z

Pablo: /* Ct */ still use ip prefix for ct [original | reply] ip daddr

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
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 <destination address>''
| Destination address translation
|<source lang="bash">
dnat 192.168.3.2
dnat ct mark map { 0x00000014 : 1.2.3.4}
</source>
|-
| ''snat <ip source address>''
| Source address translation
|<source lang="bash">
snat 192.168.3.2
snat 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>

Quick reference-nftables in 10 minutes

2021-01-15T22:25:36Z

Pablo: /* Ct */ update ct original ip {s,d}addr syntax

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
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] 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 <destination address>''
| Destination address translation
|<source lang="bash">
dnat 192.168.3.2
dnat ct mark map { 0x00000014 : 1.2.3.4}
</source>
|-
| ''snat <ip source address>''
| Source address translation
|<source lang="bash">
snat 192.168.3.2
snat 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>

Mangling packet headers

2020-12-18T18:05:29Z

Pablo: