1nft(8)                                                                  nft(8)
2
3
4

NAME

6       nft  - Administration tool of the nftables framework for packet filter‐
7       ing and classification
8

SYNOPSIS

10       nft [ -nNscaej ] [ -I directory ] [ -f filename | -i | cmd ...]
11       nft -h
12       nft -v
13

DESCRIPTION

15       nft is the command line tool used to set up, maintain and inspect pack‐
16       et filtering and classification rules in the Linux kernel, in the nfta‐
17       bles framework.  The Linux kernel subsystem is known as nf_tables,  and
18       'nf' stands for Netfilter.
19

OPTIONS

21       For a full summary of options, run nft --help.
22
23       -h, --help
24              Show help message and all options.
25
26       -v, --version
27              Show version.
28
29       -n, --numeric
30              Show  data  numerically. When used once (the default behaviour),
31              skip lookup of addresses to symbolic names. Use  twice  to  also
32              show  Internet  services  (port  numbers) numerically. Use three
33              times to also show protocols and UIDs/GIDs numerically.
34
35       -N, --reversedns
36              Translate IP addresses to names. Usually requires network  traf‐
37              fic for DNS lookup.
38
39       -s, --stateless
40              Omit stateful information of rules and stateful objects.
41
42       -c, --check
43              Check commands validity without actually applying the changes.
44
45       -a, --handle
46              Show object handles in output.
47
48       -e, --echo
49              When  inserting  items into the ruleset using add, insert or re‐
50              place commands, print notifications just like nft monitor.
51
52       -j, --json
53              Format output in JSON.
54
55       -I, --includepath directory
56              Add the directory directory to the list  of  directories  to  be
57              searched for included files. This option may be specified multi‐
58              ple times.
59
60       -f, --file filename
61              Read input from filename. If filename is -, read from stdin.
62
63              nft scripts must start #!/usr/sbin/nft -f
64
65       -i, --interactive
66              Read input from an interactive readline CLI. You can use quit to
67              exit, or use the EOF marker, normally this is CTRL-D.
68

INPUT FILE FORMAT

70   LEXICAL CONVENTIONS
71       Input  is parsed line-wise. When the last character of a line, just be‐
72       fore the newline character, is a non-quoted  backslash  (\),  the  next
73       line  is  treated as a continuation. Multiple commands on the same line
74       can be separated using a semicolon (;).
75
76       A hash sign (#) begins a comment. All following characters on the  same
77       line are ignored.
78
79       Identifiers begin with an alphabetic character (a-z,A-Z), followed zero
80       or more alphanumeric characters (a-z,A-Z,0-9) and the characters  slash
81       (/),  backslash (\), underscore (_) and dot (.). Identifiers using dif‐
82       ferent characters or clashing with a keyword need  to  be  enclosed  in
83       double quotes (").
84
85   INCLUDE FILES
86       include filename
87
88       Other files can be included by using the include statement.  The direc‐
89       tories to be searched for include files  can  be  specified  using  the
90       -I/--includepath  option.  You  can  override  this behaviour either by
91       prepending ./ to your path to force inclusion of files located  in  the
92       current  working  directory (i.e. relative path) or / for file location
93       expressed as an absolute path.
94
95       If -I/--includepath is not specified, then nft relies  on  the  default
96       directory  that is specified at compile time. You can retrieve this de‐
97       fault directory via -h/--help option.
98
99       Include statements support the usual shell wildcard  symbols  (*,?,[]).
100       Having no matches for an include statement is not an error, if wildcard
101       symbols are used in the include statement. This  allows  having  poten‐
102       tially   empty   include   directories   for  statements  like  include
103       "/etc/firewall/rules/*". The wildcard matches are loaded in  alphabeti‐
104       cal  order.  Files  beginning  with  dot (.) are not matched by include
105       statements.
106
107   SYMBOLIC VARIABLES
108       define variable expr
109       $variable
110
111       Symbolic variables can be defined using the define statement.  Variable
112       references  are expressions and can be used initialize other variables.
113       The scope of a definition is the current block and all blocks contained
114       within.
115
116       Using symbolic variables
117
118       define int_if1 = eth0
119       define int_if2 = eth1
120       define int_ifs = { $int_if1, $int_if2 }
121
122       filter input iif $int_ifs accept
123
124

ADDRESS FAMILIES

126       Address families determine the type of packets which are processed. For
127       each address family the kernel contains so  called  hooks  at  specific
128       stages  of  the packet processing paths, which invoke nftables if rules
129       for these hooks exist.
130
131       ip     IPv4 address family.
132
133       ip6    IPv6 address family.
134
135       inet   Internet (IPv4/IPv6) address family.
136
137       arp    ARP address family, handling IPv4 ARP packets.
138
139       bridge Bridge address family, handling packets which traverse a  bridge
140              device.
141
142       netdev Netdev address family, handling packets from ingress.
143
144       All  nftables  objects  exist  in  address  family specific namespaces,
145       therefore all identifiers include an address family. If  an  identifier
146       is  specified  without  an address family, the ip family is used by de‐
147       fault.
148
149   IPV4/IPV6/INET ADDRESS FAMILIES
150       The IPv4/IPv6/Inet address families handle IPv4, IPv6 or both types  of
151       packets.  They contain five hooks at different packet processing stages
152       in the network stack.
153
154       IPv4/IPv6/Inet address family hooks
155
156       ┌────────────┬────────────────────────────┐
157       │Hook        │ Description                │
158       ├────────────┼────────────────────────────┤
159       │prerouting  │ All packets  entering  the │
160       │            │ system  are  processed  by │
161       │            │ the prerouting hook. It is │
162       │            │ invoked before the routing │
163       │            │ process and  is  used  for │
164       │            │ early  filtering or chang‐ │
165       │            │ ing packet attributes that │
166       │            │ affect routing.            │
167       ├────────────┼────────────────────────────┤
168       │input       │ Packets  delivered  to the │
169       │            │ local system are processed │
170       │            │ by the input hook.         │
171       ├────────────┼────────────────────────────┤
172       │forward     │ Packets   forwarded  to  a │
173       │            │ different  host  are  pro‐ │
174       │            │ cessed   by   the  forward │
175       │            │ hook.                      │
176       ├────────────┼────────────────────────────┤
177       │output      │ Packets sent by local pro‐ │
178       │            │ cesses  are  processed  by │
179       │            │ the output hook.           │
180       ├────────────┼────────────────────────────┤
181       │postrouting │ All  packets  leaving  the │
182       │            │ system  are  processed  by │
183       │            │ the postrouting hook.      │
184       └────────────┴────────────────────────────┘
185   ARP ADDRESS FAMILY
186       The ARP address family handles ARP packets received  and  sent  by  the
187       system. It is commonly used to mangle ARP packets for clustering.
188
189       ARP address family hooks
190
191       ┌───────┬────────────────────────────┐
192       │Hook   │ Description                │
193       ├───────┼────────────────────────────┤
194       │input  │ Packets  delivered  to the │
195       │       │ local system are processed │
196       │       │ by the input hook.         │
197       ├───────┼────────────────────────────┤
198       │output │ Packets  send by the local │
199       │       │ system  are  processed  by │
200       │       │ the output hook.           │
201       └───────┴────────────────────────────┘
202   BRIDGE ADDRESS FAMILY
203       The  bridge  address  family handles Ethernet packets traversing bridge
204       devices.
205
206       The list of supported hooks is identical to IPv4/IPv6/Inet address fam‐
207       ilies above.
208
209   NETDEV ADDRESS FAMILY
210       The Netdev address family handles packets from ingress.
211
212       Netdev address family hooks
213
214       ┌────────┬────────────────────────────┐
215       │Hook    │ Description                │
216       ├────────┼────────────────────────────┤
217       │ingress │ All  packets  entering the │
218       │        │ system  are  processed  by │
219       │        │ this  hook.  It is invoked │
220       │        │ before  layer  3  protocol │
221       │        │ handlers  and  it  can  be │
222       │        │ used for  early  filtering │
223       │        │ and policing.              │
224       └────────┴────────────────────────────┘

RULESET

226       {list | flush} ruleset [family]
227
228       The  ruleset  keyword  is  used  to  identify  the whole set of tables,
229       chains, etc. currently in place in kernel. The following  ruleset  com‐
230       mands exist:
231
232       list   Print the ruleset in human-readable format.
233
234       flush  Clear  the  whole  ruleset. Note that unlike iptables, this will
235              remove all tables and whatever they contain, effectively leading
236              to  an  empty ruleset - no packet filtering will happen anymore,
237              so the kernel accepts any valid packet it receives.
238
239       It is possible to limit list and flush to a specific address family on‐
240       ly. For a list of valid family names, see ADDRESS FAMILIES above.
241
242       By  design, list ruleset command output may be used as input to nft -f.
243       Effectively, this is the nft-equivalent of iptables-save and  iptables-
244       restore.
245

TABLES

247       {add | create} table [family] table [ { flags flags } ]
248       {delete | list | flush} table [family] table
249       delete table [family] handle handle
250
251       Tables  are  containers for chains, sets and stateful objects. They are
252       identified by their address family and their name. The  address  family
253       must  be  one  of ip, ip6, inet, arp, bridge, netdev.  The inet address
254       family is a dummy family which is used to create hybrid  IPv4/IPv6  ta‐
255       bles.  The  meta  expression  nfproto keyword can be used to test which
256       family (IPv4 or IPv6) context the packet is being processed  in.   When
257       no  address  family is specified, ip is used by default.  The only dif‐
258       ference between add and create is that the former will  not  return  an
259       error if the specified table already exists while create will return an
260       error.
261
262       Table flags
263
264       ┌────────┬────────────────────────────┐
265       │Flag    │ Description                │
266       ├────────┼────────────────────────────┤
267       │dormant │ table is not evaluated any │
268       │        │ more  (base chains are un‐ │
269       │        │ registered)                │
270       └────────┴────────────────────────────┘
271       Add, change, delete a table
272
273       # start nft in interactive mode
274       nft --interactive
275
276       # create a new table.
277       create table inet mytable
278
279       # add a new base chain: get input packets
280       add chain inet mytable myin { type filter hook input priority 0; }
281
282       # add a single counter to the chain
283       add rule inet mytable myin counter
284
285       # disable the table temporarily -- rules are not evaluated anymore
286       add table inet mytable { flags dormant; }
287
288       # make table active again:
289       add table inet mytable
290
291
292       add    Add a new table for the given family with the given name.
293
294       delete Delete the specified table.
295
296       list   List all chains and rules of the specified table.
297
298       flush  Flush all chains and rules of the specified table.
299

CHAINS

301       {add | create} chain [family] table chain [ { type type hook hook
302       [device device] priority priority ; [policy policy ;] } ]
303       {delete | list | flush} chain [family] table chain
304       delete chain [family] table handle handle
305       rename chain [family] table chain newname
306
307       Chains  are  containers for rules. They exist in two kinds, base chains
308       and regular chains. A base chain is an entry point for packets from the
309       networking  stack,  a  regular  chain may be used as jump target and is
310       used for better rule organization.
311
312       add    Add a new chain in the specified table. When a hook and priority
313              value  are  specified,  the chain is created as a base chain and
314              hooked up to the networking stack.
315
316       create Similar to the add command, but returns an error  if  the  chain
317              already exists.
318
319       delete Delete the specified chain. The chain must not contain any rules
320              or be used as jump target.
321
322       rename Rename the specified chain.
323
324       list   List all rules of the specified chain.
325
326       flush  Flush all rules of the specified chain.
327
328       For base chains, type, hook and priority parameters are mandatory.
329
330       Supported chain types
331
332       ┌───────┬──────────┬──────────────────┬──────────────────┐
333       │Type   │ Families │ Hooks            │ Description      │
334       ├───────┼──────────┼──────────────────┼──────────────────┤
335       │filter │ all      │ all              │ Standard   chain │
336       │       │          │                  │ type  to  use in │
337       │       │          │                  │ doubt.           │
338       ├───────┼──────────┼──────────────────┼──────────────────┤
339       │nat    │ ip, ip6  │ prerouting,  in‐ │ Chains  of  this │
340       │       │          │ put,     output, │ type     perform │
341       │       │          │ postrouting      │ Network  Address │
342       │       │          │                  │ Translation      │
343       │       │          │                  │ based  on   con‐ │
344       │       │          │                  │ ntrack  entries. │
345       │       │          │                  │ Only  the  first │
346       │       │          │                  │ packet of a con‐ │
347       │       │          │                  │ nection actually │
348       │       │          │                  │ traverses   this │
349       │       │          │                  │ chain   -    its │
350       │       │          │                  │ rules    usually │
351       │       │          │                  │ define   details │
352       │       │          │                  │ of  the  created │
353       │       │          │                  │ conntrack  entry │
354       │       │          │                  │ (NAT  statements │
355       │       │          │                  │ for instance).   │
356       ├───────┼──────────┼──────────────────┼──────────────────┤
357       │route  │ ip, ip6  │ output           │ If a packet  has │
358       │       │          │                  │ traversed      a │
359       │       │          │                  │ chain  of   this │
360       │       │          │                  │ type    and   is │
361       │       │          │                  │ about to be  ac‐ │
362       │       │          │                  │ cepted,   a  new │
363       │       │          │                  │ route lookup  is │
364       │       │          │                  │ performed     if │
365       │       │          │                  │ relevant   parts │
366       │       │          │                  │ of the IP header │
367       │       │          │                  │ have    changed. │
368       │       │          │                  │ This  allows  to │
369       │       │          │                  │ e.g.   implement │
370       │       │          │                  │ policy   routing │
371       │       │          │                  │ selectors     in │
372       │       │          │                  │ nftables.        │
373       └───────┴──────────┴──────────────────┴──────────────────┘
374       Apart  from the special cases illustrated above (e.g. nat type not sup‐
375       porting forward hook or route type only supporting output hook),  there
376       are two further quirks worth noticing:
377
378       · netdev  family  supports  merely  a single combination, namely filter
379         type and ingress hook. Base chains in this family  also  require  the
380         device  parameter  to be present since they exist per incoming inter‐
381         face only.
382
383       · arp family supports only input and output hooks, both  in  chains  of
384         type filter.
385
386       The  priority  parameter accepts a signed integer value which specifies
387       the order in which chains with same hook value are traversed.  The  or‐
388       dering  is  ascending,  i.e. lower priority values have precedence over
389       higher ones.
390
391       Base chains also allow to set the chain's policy, i.e. what happens  to
392       packets not explicitly accepted or refused in contained rules. Support‐
393       ed policy values are accept (which is the default) or drop.
394

RULES

396       [add | insert] rule [family] table chain [ handle handle | index index
397       ] statement...
398       replace rule [family] table chain handle handle statement...
399       delete rule [family] table chain handle handle
400
401       Rules  are  added  to  chain  in the given table.  If the family is not
402       specified, the ip family is used.  Rules are constructed from two kinds
403       of  components according to a set of grammatical rules: expressions and
404       statements.
405
406       The add and insert commands support  an  optional  location  specifier,
407       which is either a handle or the index (starting at zero) of an existing
408       rule. Internally, rule locations are always identified  by  handle  and
409       the translation from index happens in userspace. This has two potential
410       implications in case a concurrent  ruleset  change  happens  after  the
411       translation  was  done: The effective rule index might change if a rule
412       was inserted or deleted before the referred one. If the  referred  rule
413       was  deleted,  the  command is rejected by the kernel just as if an in‐
414       valid handle was given.
415
416       add    Add a new rule described by the list of statements. The rule  is
417              appended  to  the  given  chain unless a handle is specified, in
418              which case the rule is appended to the rule given by the handle.
419
420       insert Similar to the add command, but the rule is prepended to the be‐
421              ginning of the chain or before the rule with the given handle.
422
423       replace
424              Similar  to the add command, but the rule replaces the specified
425              rule.
426
427       delete Delete the specified rule.
428
429       add a rule to ip table input chain
430
431       nft add rule filter output ip daddr 192.168.0.0/24 accept # 'ip filter' is assumed
432       # same command, slightly more verbose
433       nft add rule ip filter output ip daddr 192.168.0.0/24 accept
434
435
436
437       delete rule from inet table
438
439       # nft -a list ruleset
440       table inet filter {
441               chain input {
442                       type filter hook input priority 0; policy accept;
443                       ct state established,related accept # handle 4
444                       ip saddr 10.1.1.1 tcp dport ssh accept # handle 5
445                 ...
446       # delete the rule with handle 5
447       # nft delete rule inet filter input handle 5
448
449

SETS

451       nftables offers two kinds of set concepts.   Anonymous  sets  are  sets
452       that  have  no  specific  name.  The  set members are enclosed in curly
453       braces, with commas to separate elements when creating the rule the set
454       is  used  in.   Once  that rule is removed, the set is removed as well.
455       They cannot be updated, i.e. once an anonymous set is declared it  can‐
456       not  be  changed anymore except by removing/altering the rule that uses
457       the anonymous set.
458
459       Using anonymous sets to accept particular subnets and ports
460
461               nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept
462
463
464       Named sets are sets that need to be defined first before  they  can  be
465       referenced in rules. Unlike anonymous sets, elements can be added to or
466       removed from a named set at any time.  Sets are referenced  from  rules
467       using an @ prefixed to the sets name.
468
469       Using named sets to accept addresses and ports
470
471               nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept
472
473
474       The  sets allowed_hosts and allowed_ports need to be created first. The
475       next section describes nft set syntax in more detail.
476
477       add set [family] table set { type type ; [flags flags ;] [timeout
478       timeout ;] [gc-interval gc-interval ;] [elements = { element[,...] } ;]
479       [size size ;] [policy policy ;] [auto-merge auto-merge ;] }
480       {delete | list | flush} set [family] table set
481       delete set [family] table handle handle
482       {add | delete} element [family] table set { element[,...] }
483
484       Sets are elements containers of an user-defined  data  type,  they  are
485       uniquely identified by an user-defined name and attached to tables.
486
487       add    Add a new set in the specified table.
488
489       delete Delete the specified set.
490
491       list   Display the elements in the specified set.
492
493       flush  Remove all elements from the specified set.
494
495       add element
496              Comma-separated list of elements to add into the specified set.
497
498       delete element
499              Comma-separated  list  of  elements to delete from the specified
500              set.
501
502       Set specifications
503
504       ┌────────────┬─────────────────────┬─────────────────────┐
505       │Keyword     │ Description         │ Type                │
506       ├────────────┼─────────────────────┼─────────────────────┤
507       │type        │ data  type  of  set │ string:  ipv4_addr, │
508       │            │ elements            │ ipv6_addr,          │
509       │            │                     │ ether_addr,     in‐ │
510       │            │                     │ et_proto, inet_ser‐ │
511       │            │                     │ vice, mark          │
512       ├────────────┼─────────────────────┼─────────────────────┤
513       │flags       │ set flags           │ string:   constant, │
514       │            │                     │ interval, timeout   │
515       ├────────────┼─────────────────────┼─────────────────────┤
516       │timeout     │ time   an   element │ string,     decimal │
517       │            │ stays  in  the set, │ followed  by  unit. │
518       │            │ mandatory if set is │ Units are: d, h, m, │
519       │            │ added  to  from the │ s                   │
520       │            │ packet path  (rule‐ │                     │
521       │            │ set).               │                     │
522       ├────────────┼─────────────────────┼─────────────────────┤
523       │gc-interval │ garbage  collection │ string,     decimal │
524       │            │ interval,      only │ followed  by  unit. │
525       │            │ available      when │ Units are: d, h, m, │
526       │            │ timeout   or   flag │ s                   │
527       │            │ timeout are active  │                     │
528       ├────────────┼─────────────────────┼─────────────────────┤
529       │elements    │ elements  contained │ set data type       │
530       │            │ by the set          │                     │
531       ├────────────┼─────────────────────┼─────────────────────┤
532       │size        │ maximum  number  of │ unsigned    integer │
533       │            │ elements   in   the │ (64 bit)            │
534       │            │ set,  mandatory  if │                     │
535       │            │ set   is  added  to │                     │
536       │            │ from   the   packet │                     │
537       │            │ path (ruleset).     │                     │
538       ├────────────┼─────────────────────┼─────────────────────┤
539       │policy      │ set policy          │ string: performance │
540       │            │                     │ [default], memory   │
541       ├────────────┼─────────────────────┼─────────────────────┤
542       │auto-merge  │ automatic  merge of │                     │
543       │            │ adjacent/overlap‐   │                     │
544       │            │ ping  set  elements │                     │
545       │            │ (only for  interval │                     │
546       │            │ sets)               │                     │
547       └────────────┴─────────────────────┴─────────────────────┘

MAPS

549       add map [family] table map { type type [flags flags ;] [elements = {
550       element[,...] } ;] [size size ;] [policy policy ;] }
551       {delete | list | flush} map [family] table map
552       {add | delete} element [family] table map { elements = { element[,...]
553       } ; }
554
555       Maps  store  data  based  on  some specific key used as input, they are
556       uniquely identified by an user-defined name and attached to tables.
557
558       add    Add a new map in the specified table.
559
560       delete Delete the specified map.
561
562       list   Display the elements in the specified map.
563
564       flush  Remove all elements from the specified map.
565
566       add element
567              Comma-separated list of elements to add into the specified map.
568
569       delete element
570              Comma-separated list of element keys to delete from  the  speci‐
571              fied map.
572
573       Map specifications
574
575       ┌─────────┬─────────────────────┬─────────────────────┐
576       │Keyword  │ Description         │ Type                │
577       ├─────────┼─────────────────────┼─────────────────────┤
578       │type     │ data  type  of  map │ string ':'  string: │
579       │         │ elements            │ ipv4_addr, ipv6_ad‐ │
580       │         │                     │ dr, ether_addr, in‐ │
581       │         │                     │ et_proto, inet_ser‐ │
582       │         │                     │ vice,         mark, │
583       │         │                     │ counter,     quota. │
584       │         │                     │ Counter  and  quota │
585       │         │                     │ can't  be  used  as │
586       │         │                     │ keys                │
587       ├─────────┼─────────────────────┼─────────────────────┤
588       │flags    │ map flags           │ string:   constant, │
589       │         │                     │ interval            │
590       ├─────────┼─────────────────────┼─────────────────────┤
591       │elements │ elements  contained │ map data type       │
592       │         │ by the map          │                     │
593       ├─────────┼─────────────────────┼─────────────────────┤
594       │size     │ maximum  number  of │ unsigned    integer │
595       │         │ elements in the map │ (64 bit)            │
596       ├─────────┼─────────────────────┼─────────────────────┤
597       │policy   │ map policy          │ string: performance │
598       │         │                     │ [default], memory   │
599       └─────────┴─────────────────────┴─────────────────────┘

FLOWTABLES

601       {add | create} flowtable [family] table flowtable { hook hook priority
602       priority ; devices = { device[,...] } ; }
603       {delete | list} flowtable [family] table flowtable
604
605       Flowtables allow you  to  accelerate  packet  forwarding  in  software.
606       Flowtables  entries are represented through a tuple that is composed of
607       the input interface, source and destination address, source and  desti‐
608       nation port; and layer 3/4 protocols. Each entry also caches the desti‐
609       nation interface and the gateway address - to  update  the  destination
610       link-layer  address  -  to forward packets. The ttl and hoplimit fields
611       are also decremented. Hence, flowtables provides  an  alternative  path
612       that  allow  packets  to bypass the classic forwarding path. Flowtables
613       reside in the ingress hook, that is located before the prerouting hook.
614       You  can select what flows you want to offload through the flow offload
615       expression from the forward chain. Flowtables are identified  by  their
616       address  family  and  their name. The address family must be one of ip,
617       ip6, inet.  The inet address family is a dummy family which is used  to
618       create  hybrid  IPv4/IPv6 tables.  When no address family is specified,
619       ip is used by default.
620
621       add    Add a new flowtable for the given family with the given name.
622
623       delete Delete the specified flowtable.
624
625       list   List all flowtables.
626

STATEFUL OBJECTS

628       {add | delete | list | reset} type [family] table object
629       delete type [family] table handle handle
630
631       Stateful objects are attached to tables and are identified by an unique
632       name.  They group stateful information from rules, to reference them in
633       rules the keywords "type name" are used e.g. "counter name".
634
635       add    Add a new stateful object in the specified table.
636
637       delete Delete the specified object.
638
639       list   Display stateful information the object holds.
640
641       reset  List-and-reset stateful object.
642
643   CT
644       ct helper helper { type type protocol protocol ; [l3proto family ;] }
645
646       Ct helper is used to define connection tracking helpers that  can  then
647       be  used  in  combination with the "ct helper set" statement.  type and
648       protocol are mandatory, l3proto is derived from the table family by de‐
649       fault, i.e. in the inet table the kernel will try to load both the IPv4
650       and IPv6 helper backends, if they are supported by the kernel.
651
652       conntrack helper specifications
653
654       ┌─────────┬─────────────────────┬─────────────────────┐
655       │Keyword  │ Description         │ Type                │
656       ├─────────┼─────────────────────┼─────────────────────┤
657       │type     │ name of helper type │ quoted string (e.g. │
658       │         │                     │ "ftp")              │
659       ├─────────┼─────────────────────┼─────────────────────┤
660       │protocol │ layer 4 protocol of │ string (e.g. tcp)   │
661       │         │ the helper          │                     │
662       ├─────────┼─────────────────────┼─────────────────────┤
663       │l3proto  │ layer 3 protocol of │ address      family │
664       │         │ the helper          │ (e.g. ip)           │
665       └─────────┴─────────────────────┴─────────────────────┘
666       defining and assigning ftp helper
667
668       Unlike iptables, helper assignment needs to be performed after the con‐
669       ntrack lookup has completed, for example with the default 0 hook prior‐
670       ity.
671
672       table inet myhelpers {
673         ct helper ftp-standard {
674            type "ftp" protocol tcp
675         }
676         chain prerouting {
677             type filter hook prerouting priority 0;
678             tcp dport 21 ct helper set "ftp-standard"
679         }
680       }
681
682   COUNTER
683       counter [packets bytes]
684
685       Counter specifications
686
687       ┌────────┬─────────────────────┬─────────────────────┐
688       │Keyword │ Description         │ Type                │
689       ├────────┼─────────────────────┼─────────────────────┤
690       │packets │ initial  count   of │ unsigned    integer │
691       │        │ packets             │ (64 bit)            │
692       ├────────┼─────────────────────┼─────────────────────┤
693       │bytes   │ initial  count   of │ unsigned    integer │
694       │        │ bytes               │ (64 bit)            │
695       └────────┴─────────────────────┴─────────────────────┘
696   QUOTA
697       quota [over | until] [used]
698
699       Quota specifications
700
701       ┌────────┬─────────────────────┬─────────────────────┐
702       │Keyword │ Description         │ Type                │
703       ├────────┼─────────────────────┼─────────────────────┤
704       │quota   │ quota  limit,  used │ Two  arguments, un‐ │
705       │        │ as the quota name   │ signed integer  (64 │
706       │        │                     │ bit)   and  string: │
707       │        │                     │ bytes,      kbytes, │
708       │        │                     │ mbytes.  "over" and │
709       │        │                     │ "until"  go  before │
710       │        │                     │ these arguments     │
711       ├────────┼─────────────────────┼─────────────────────┤
712       │used    │ initial   value  of │ Two arguments,  un‐ │
713       │        │ used quota          │ signed  integer (64 │
714       │        │                     │ bit)  and   string: │
715       │        │                     │ bytes,      kbytes, │
716       │        │                     │ mbytes              │
717       └────────┴─────────────────────┴─────────────────────┘

EXPRESSIONS

719       Expressions represent values, either constants like network  addresses,
720       port numbers etc. or data gathered from the packet during ruleset eval‐
721       uation. Expressions can be combined using binary,  logical,  relational
722       and  other  types  of expressions to form complex or relational (match)
723       expressions.  They are also used as arguments to certain types of oper‐
724       ations, like NAT, packet marking etc.
725
726       Each expression has a data type, which determines the size, parsing and
727       representation of symbolic values and type compatibility with other ex‐
728       pressions.
729
730   DESCRIBE COMMAND
731       describe expression
732
733       The  describe command shows information about the type of an expression
734       and its data type.
735
736       The describe command
737
738       $ nft describe tcp flags
739       payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits
740
741       predefined symbolic constants:
742       fin                           0x01
743       syn                           0x02
744       rst                           0x04
745       psh                           0x08
746       ack                           0x10
747       urg                           0x20
748       ecn                           0x40
749       cwr                           0x80
750

DATA TYPES

752       Data types determine the size, parsing and representation  of  symbolic
753       values  and  type compatibility of expressions. A number of global data
754       types exist, in addition some  expression  types  define  further  data
755       types  specific  to  the  expression type. Most data types have a fixed
756       size, some however may have a dynamic size, f.i. the string type.
757
758       Types may be derived from lower order types, f.i. the IPv4 address type
759       is  derived  from the integer type, meaning an IPv4 address can also be
760       specified as an integer value.
761
762       In certain contexts (set and map definitions) it is  necessary  to  ex‐
763       plicitly  specify  a data type.  Each type has a name which is used for
764       this.
765
766   INTEGER TYPE
767       ┌────────┬─────────┬──────────┬───────────┐
768       │Name    │ Keyword │ Size     │ Base type │
769       ├────────┼─────────┼──────────┼───────────┤
770       │Integer │ integer │ variable │ -         │
771       └────────┴─────────┴──────────┴───────────┘
772       The integer type is used for numeric values. It  may  be  specified  as
773       decimal,  hexadecimal  or octal number. The integer type doesn't have a
774       fixed size, its size is determined by the expression for  which  it  is
775       used.
776
777   BITMASK TYPE
778       ┌────────┬─────────┬──────────┬───────────┐
779       │Name    │ Keyword │ Size     │ Base type │
780       ├────────┼─────────┼──────────┼───────────┤
781       │Bitmask │ bitmask │ variable │ integer   │
782       └────────┴─────────┴──────────┴───────────┘
783       The bitmask type (bitmask) is used for bitmasks.
784
785   STRING TYPE
786       ┌───────┬─────────┬──────────┬───────────┐
787       │Name   │ Keyword │ Size     │ Base type │
788       ├───────┼─────────┼──────────┼───────────┤
789       │String │ string  │ variable │ -         │
790       └───────┴─────────┴──────────┴───────────┘
791       The  string type is used to for character strings. A string begins with
792       an alphabetic character (a-zA-Z) followed by zero or more  alphanumeric
793       characters  or  the  characters /, -, _ and .. In addition anything en‐
794       closed in double quotes (") is recognized as a string.
795
796       String specification
797
798       # Interface name
799       filter input iifname eth0
800
801       # Weird interface name
802       filter input iifname "(eth0)"
803
804   LINK LAYER ADDRESS TYPE
805       ┌─────────────────┬─────────┬──────────┬───────────┐
806       │Name             │ Keyword │ Size     │ Base type │
807       ├─────────────────┼─────────┼──────────┼───────────┤
808       │Link  layer  ad‐ │ lladdr  │ variable │ integer   │
809       │dress            │         │          │           │
810       └─────────────────┴─────────┴──────────┴───────────┘
811       The link layer address type is used for link layer addresses. Link lay‐
812       er addresses are specified as a variable amount of groups of two  hexa‐
813       decimal digits separated using colons (:).
814
815       Link layer address specification
816
817       # Ethernet destination MAC address
818       filter input ether daddr 20:c9:d0:43:12:d9
819
820   IPV4 ADDRESS TYPE
821       ┌─────────────┬───────────┬────────┬───────────┐
822       │Name         │ Keyword   │ Size   │ Base type │
823       ├─────────────┼───────────┼────────┼───────────┤
824       │IPv4 address │ ipv4_addr │ 32 bit │ integer   │
825       └─────────────┴───────────┴────────┴───────────┘
826       The  IPv4 address type is used for IPv4 addresses. Addresses are speci‐
827       fied in either dotted decimal, dotted hexadecimal, dotted octal,  deci‐
828       mal, hexadecimal, octal notation or as a host name. A host name will be
829       resolved using the standard system resolver.
830
831       IPv4 address specification
832
833       # dotted decimal notation
834       filter output ip daddr 127.0.0.1
835
836       # host name
837       filter output ip daddr localhost
838
839   IPV6 ADDRESS TYPE
840       ┌─────────────┬───────────┬─────────┬───────────┐
841       │Name         │ Keyword   │ Size    │ Base type │
842       ├─────────────┼───────────┼─────────┼───────────┤
843       │IPv6 address │ ipv6_addr │ 128 bit │ integer   │
844       └─────────────┴───────────┴─────────┴───────────┘
845       The IPv6 address type is used for IPv6 addresses.  Addresses are speci‐
846       fied  as  a  host name or as hexadecimal halfwords separated by colons.
847       Addresses might be enclosed in square brackets ("[]") to  differentiate
848       them from port numbers.
849
850       IPv6 address specificationIPv6 address specification with bracket nota‐
851       tion
852
853       # abbreviated loopback address
854       filter output ip6 daddr ::1
855
856       # without [] the port number (22) would be parsed as part of ipv6 address
857       ip6 nat prerouting tcp dport 2222 dnat to [1ce::d0]:22
858
859   BOOLEAN TYPE
860       ┌────────┬─────────┬───────┬───────────┐
861       │Name    │ Keyword │ Size  │ Base type │
862       ├────────┼─────────┼───────┼───────────┤
863       │Boolean │ boolean │ 1 bit │ integer   │
864       └────────┴─────────┴───────┴───────────┘
865       The boolean type is a syntactical helper type in user space.  It's  use
866       is  in the right-hand side of a (typically implicit) relational expres‐
867       sion to change the expression on the  left-hand  side  into  a  boolean
868       check (usually for existence).
869
870       The  following  keywords will automatically resolve into a boolean type
871       with given value:
872
873       ┌────────┬───────┐
874       │Keyword │ Value │
875       ├────────┼───────┤
876       │exists  │ 1     │
877       ├────────┼───────┤
878       │missing │ 0     │
879       └────────┴───────┘
880       Boolean specification
881
882       The following expressions support a boolean comparison:
883
884       ┌───────────┬────────────────────────────┐
885       │Expression │ Behaviour                  │
886       ├───────────┼────────────────────────────┤
887       │fib        │ Check route existence.     │
888       ├───────────┼────────────────────────────┤
889       │exthdr     │ Check IPv6 extension head‐ │
890       │           │ er existence.              │
891       ├───────────┼────────────────────────────┤
892       │tcp option │ Check  TCP  option  header │
893       │           │ existence.                 │
894       └───────────┴────────────────────────────┘
895       # match if route exists
896       filter input fib daddr . iif oif exists
897
898       # match only non-fragmented packets in IPv6 traffic
899       filter input exthdr frag missing
900
901       # match if TCP timestamp option is present
902       filter input tcp option timestamp exists
903
904   ICMP TYPE TYPE
905       ┌──────────┬───────────┬───────┬───────────┐
906       │Name      │ Keyword   │ Size  │ Base type │
907       ├──────────┼───────────┼───────┼───────────┤
908       │ICMP Type │ icmp_type │ 8 bit │ integer   │
909       └──────────┴───────────┴───────┴───────────┘
910       The ICMP Type type is used to conveniently specify  the  ICMP  header's
911       type field.
912
913       The following keywords may be used when specifying the ICMP type:
914
915       ┌────────────────────────┬───────┐
916       │Keyword                 │ Value │
917       ├────────────────────────┼───────┤
918       │echo-reply              │ 0     │
919       ├────────────────────────┼───────┤
920       │destination-unreachable │ 3     │
921       ├────────────────────────┼───────┤
922       │source-quench           │ 4     │
923       ├────────────────────────┼───────┤
924       │redirect                │ 5     │
925       ├────────────────────────┼───────┤
926       │echo-request            │ 8     │
927       ├────────────────────────┼───────┤
928       │router-advertisement    │ 9     │
929       ├────────────────────────┼───────┤
930       │router-solicitation     │ 10    │
931       ├────────────────────────┼───────┤
932       │time-exceeded           │ 11    │
933       ├────────────────────────┼───────┤
934       │parameter-problem       │ 12    │
935       ├────────────────────────┼───────┤
936       │timestamp-request       │ 13    │
937       ├────────────────────────┼───────┤
938       │timestamp-reply         │ 14    │
939       ├────────────────────────┼───────┤
940       │info-request            │ 15    │
941       ├────────────────────────┼───────┤
942       │info-reply              │ 16    │
943       ├────────────────────────┼───────┤
944       │address-mask-request    │ 17    │
945       ├────────────────────────┼───────┤
946       │address-mask-reply      │ 18    │
947       └────────────────────────┴───────┘
948       ICMP Type specification
949
950       # match ping packets
951       filter output icmp type { echo-request, echo-reply }
952
953   ICMP CODE TYPE
954       ┌──────────┬───────────┬───────┬───────────┐
955       │Name      │ Keyword   │ Size  │ Base type │
956       ├──────────┼───────────┼───────┼───────────┤
957       │ICMP Code │ icmp_code │ 8 bit │ integer   │
958       └──────────┴───────────┴───────┴───────────┘
959       The  ICMP  Code  type is used to conveniently specify the ICMP header's
960       code field.
961
962       The following keywords may be used when specifying the ICMP code:
963
964       ┌─────────────────┬───────┐
965       │Keyword          │ Value │
966       ├─────────────────┼───────┤
967       │net-unreachable  │ 0     │
968       ├─────────────────┼───────┤
969       │host-unreachable │ 1     │
970       ├─────────────────┼───────┤
971       │prot-unreachable │ 2     │
972       ├─────────────────┼───────┤
973       │port-unreachable │ 3     │
974       ├─────────────────┼───────┤
975       │net-prohibited   │ 9     │
976       ├─────────────────┼───────┤
977       │host-prohibited  │ 10    │
978       ├─────────────────┼───────┤
979       │admin-prohibited │ 13    │
980       └─────────────────┴───────┘
981   ICMPV6 TYPE TYPE
982       ┌────────────┬─────────────┬───────┬───────────┐
983       │Name        │ Keyword     │ Size  │ Base type │
984       ├────────────┼─────────────┼───────┼───────────┤
985       │ICMPv6 Type │ icmpv6_type │ 8 bit │ integer   │
986       └────────────┴─────────────┴───────┴───────────┘
987       The ICMPv6 Type type is used to conveniently specify the  ICMPv6  head‐
988       er's type field.
989
990       The following keywords may be used when specifying the ICMPv6 type:
991
992       ┌────────────────────────┬───────┐
993       │Keyword                 │ Value │
994       ├────────────────────────┼───────┤
995       │destination-unreachable │ 1     │
996       ├────────────────────────┼───────┤
997       │packet-too-big          │ 2     │
998       ├────────────────────────┼───────┤
999       │time-exceeded           │ 3     │
1000       ├────────────────────────┼───────┤
1001       │parameter-problem       │ 4     │
1002       ├────────────────────────┼───────┤
1003       │echo-request            │ 128   │
1004       ├────────────────────────┼───────┤
1005       │echo-reply              │ 129   │
1006       ├────────────────────────┼───────┤
1007       │mld-listener-query      │ 130   │
1008       ├────────────────────────┼───────┤
1009       │mld-listener-report     │ 131   │
1010       ├────────────────────────┼───────┤
1011       │mld-listener-done       │ 132   │
1012       ├────────────────────────┼───────┤
1013       │mld-listener-reduction  │ 132   │
1014       ├────────────────────────┼───────┤
1015       │nd-router-solicit       │ 133   │
1016       ├────────────────────────┼───────┤
1017       │nd-router-advert        │ 134   │
1018       ├────────────────────────┼───────┤
1019       │nd-neighbor-solicit     │ 135   │
1020       ├────────────────────────┼───────┤
1021       │nd-neighbor-advert      │ 136   │
1022       ├────────────────────────┼───────┤
1023       │nd-redirect             │ 137   │
1024       ├────────────────────────┼───────┤
1025       │router-renumbering      │ 138   │
1026       ├────────────────────────┼───────┤
1027       │ind-neighbor-solicit    │ 141   │
1028       ├────────────────────────┼───────┤
1029       │ind-neighbor-advert     │ 142   │
1030       ├────────────────────────┼───────┤
1031       │mld2-listener-report    │ 143   │
1032       └────────────────────────┴───────┘
1033       ICMPv6 Type specification
1034
1035       # match ICMPv6 ping packets
1036       filter output icmpv6 type { echo-request, echo-reply }
1037
1038   ICMPV6 CODE TYPE
1039       ┌────────────┬─────────────┬───────┬───────────┐
1040       │Name        │ Keyword     │ Size  │ Base type │
1041       ├────────────┼─────────────┼───────┼───────────┤
1042       │ICMPv6 Code │ icmpv6_code │ 8 bit │ integer   │
1043       └────────────┴─────────────┴───────┴───────────┘
1044       The  ICMPv6  Code type is used to conveniently specify the ICMPv6 head‐
1045       er's code field.
1046
1047       The following keywords may be used when specifying the ICMPv6 code:
1048
1049       ┌─────────────────┬───────┐
1050       │Keyword          │ Value │
1051       ├─────────────────┼───────┤
1052       │no-route         │ 0     │
1053       ├─────────────────┼───────┤
1054       │admin-prohibited │ 1     │
1055       ├─────────────────┼───────┤
1056       │addr-unreachable │ 3     │
1057       ├─────────────────┼───────┤
1058       │port-unreachable │ 4     │
1059       ├─────────────────┼───────┤
1060       │policy-fail      │ 5     │
1061       ├─────────────────┼───────┤
1062       │reject-route     │ 6     │
1063       └─────────────────┴───────┘
1064   ICMPVX CODE TYPE
1065       ┌────────────┬────────────┬───────┬───────────┐
1066       │Name        │ Keyword    │ Size  │ Base type │
1067       ├────────────┼────────────┼───────┼───────────┤
1068       │ICMPvX Code │ icmpx_code │ 8 bit │ integer   │
1069       └────────────┴────────────┴───────┴───────────┘
1070       The ICMPvX Code type abstraction is a set of values which  overlap  be‐
1071       tween ICMP and ICMPv6 Code types to be used from the inet family.
1072
1073       The following keywords may be used when specifying the ICMPvX code:
1074
1075       ┌─────────────────┬───────┐
1076       │Keyword          │ Value │
1077       ├─────────────────┼───────┤
1078       │no-route         │ 0     │
1079       ├─────────────────┼───────┤
1080       │port-unreachable │ 1     │
1081       ├─────────────────┼───────┤
1082       │host-unreachable │ 2     │
1083       ├─────────────────┼───────┤
1084       │admin-prohibited │ 3     │
1085       └─────────────────┴───────┘
1086   CONNTRACK TYPES
1087       This is an overview of types used in ct expression and statement:
1088
1089       ┌─────────────────┬───────────┬─────────┬───────────┐
1090       │Name             │ Keyword   │ Size    │ Base type │
1091       ├─────────────────┼───────────┼─────────┼───────────┤
1092       │conntrack state  │ ct_state  │ 4 byte  │ bitmask   │
1093       ├─────────────────┼───────────┼─────────┼───────────┤
1094       │conntrack direc‐ │ ct_dir    │ 8 bit   │ integer   │
1095       │tion             │           │         │           │
1096       ├─────────────────┼───────────┼─────────┼───────────┤
1097       │conntrack status │ ct_status │ 4 byte  │ bitmask   │
1098       ├─────────────────┼───────────┼─────────┼───────────┤
1099       │conntrack  event │ ct_event  │ 4 byte  │ bitmask   │
1100       │bits             │           │         │           │
1101       ├─────────────────┼───────────┼─────────┼───────────┤
1102       │conntrack label  │ ct_label  │ 128 bit │ bitmask   │
1103       └─────────────────┴───────────┴─────────┴───────────┘
1104       For each of the types above, keywords are available for convenience:
1105
1106       conntrack state (ct_state)
1107
1108       ┌────────────┬───────┐
1109       │Keyword     │ Value │
1110       ├────────────┼───────┤
1111       │invalid     │ 1     │
1112       ├────────────┼───────┤
1113       │established │ 2     │
1114       ├────────────┼───────┤
1115       │related     │ 4     │
1116       ├────────────┼───────┤
1117       │new         │ 8     │
1118       ├────────────┼───────┤
1119       │untracked   │ 64    │
1120       └────────────┴───────┘
1121       conntrack direction (ct_dir)
1122
1123       ┌─────────┬───────┐
1124       │Keyword  │ Value │
1125       ├─────────┼───────┤
1126       │original │ 0     │
1127       ├─────────┼───────┤
1128       │reply    │ 1     │
1129       └─────────┴───────┘
1130       conntrack status (ct_status)
1131
1132       ┌───────────┬───────┐
1133       │Keyword    │ Value │
1134       ├───────────┼───────┤
1135       │expected   │ 1     │
1136       ├───────────┼───────┤
1137       │seen-reply │ 2     │
1138       ├───────────┼───────┤
1139       │assured    │ 4     │
1140       ├───────────┼───────┤
1141       │confirmed  │ 8     │
1142       ├───────────┼───────┤
1143       │snat       │ 16    │
1144       ├───────────┼───────┤
1145       │dnat       │ 32    │
1146       ├───────────┼───────┤
1147       │dying      │ 512   │
1148       └───────────┴───────┘
1149       conntrack event bits (ct_event)
1150
1151       ┌──────────┬───────┐
1152       │Keyword   │ Value │
1153       ├──────────┼───────┤
1154       │new       │ 1     │
1155       ├──────────┼───────┤
1156       │related   │ 2     │
1157       ├──────────┼───────┤
1158       │destroy   │ 4     │
1159       ├──────────┼───────┤
1160       │reply     │ 8     │
1161       ├──────────┼───────┤
1162       │assured   │ 16    │
1163       ├──────────┼───────┤
1164       │protoinfo │ 32    │
1165       ├──────────┼───────┤
1166       │helper    │ 64    │
1167       ├──────────┼───────┤
1168       │mark      │ 128   │
1169       ├──────────┼───────┤
1170       │seqadj    │ 256   │
1171       ├──────────┼───────┤
1172       │secmark   │ 512   │
1173       ├──────────┼───────┤
1174       │label     │ 1024  │
1175       └──────────┴───────┘
1176       Possible  keywords for conntrack label type (ct_label) are read at run‐
1177       time from /etc/connlabel.conf.
1178

PRIMARY EXPRESSIONS

1180       The lowest order expression is a primary expression,  representing  ei‐
1181       ther a constant or a single datum from a packet's payload, meta data or
1182       a stateful module.
1183
1184   META EXPRESSIONS
1185       meta {length | nfproto | l4proto | protocol | priority}
1186       [meta] {mark | iif | iifname | iiftype | oif | oifname | oiftype |
1187       skuid | skgid | nftrace | rtclassid | ibrname | obrname | pkttype | cpu
1188       | iifgroup | oifgroup | cgroup | random | secpath}
1189
1190       A meta expression refers to meta data associated with a packet.
1191
1192       There are two types of meta expressions: unqualified and qualified meta
1193       expressions.   Qualified  meta expressions require the meta keyword be‐
1194       fore the meta key, unqualified meta expressions can be specified by us‐
1195       ing  the  meta  key  directly  or  as qualified meta expressions.  Meta
1196       l4proto is useful to match a particular transport protocol that is part
1197       of  either an IPv4 or IPv6 packet. It will also skip any IPv6 extension
1198       headers present in an IPv6 packet.
1199
1200       Meta expression types
1201
1202       ┌──────────┬─────────────────────┬───────────────────┐
1203       │Keyword   │ Description         │ Type              │
1204       ├──────────┼─────────────────────┼───────────────────┤
1205       │length    │ Length of the pack‐ │ integer (32 bit)  │
1206       │          │ et in bytes         │                   │
1207       ├──────────┼─────────────────────┼───────────────────┤
1208       │nfproto   │ real  hook protocol │ integer (32 bit)  │
1209       │          │ family, useful only │                   │
1210       │          │ in inet table       │                   │
1211       ├──────────┼─────────────────────┼───────────────────┤
1212       │l4proto   │ layer  4  protocol, │ integer (8 bit)   │
1213       │          │ skips  ipv6  exten‐ │                   │
1214       │          │ sion headers        │                   │
1215       ├──────────┼─────────────────────┼───────────────────┤
1216       │protocol  │ EtherType  protocol │ ether_type        │
1217       │          │ value               │                   │
1218       ├──────────┼─────────────────────┼───────────────────┤
1219       │priority  │ TC packet priority  │ tc_handle         │
1220       ├──────────┼─────────────────────┼───────────────────┤
1221       │mark      │ Packet mark         │ mark              │
1222       ├──────────┼─────────────────────┼───────────────────┤
1223       │iif       │ Input interface in‐ │ iface_index       │
1224       │          │ dex                 │                   │
1225       ├──────────┼─────────────────────┼───────────────────┤
1226       │iifname   │ Input     interface │ ifname            │
1227       │          │ name                │                   │
1228       ├──────────┼─────────────────────┼───────────────────┤
1229       │iiftype   │ Input     interface │ iface_type        │
1230       │          │ type                │                   │
1231       ├──────────┼─────────────────────┼───────────────────┤
1232       │oif       │ Output    interface │ iface_index       │
1233       │          │ index               │                   │
1234       ├──────────┼─────────────────────┼───────────────────┤
1235       │oifname   │ Output    interface │ ifname            │
1236       │          │ name                │                   │
1237       ├──────────┼─────────────────────┼───────────────────┤
1238       │oiftype   │ Output    interface │ iface_type        │
1239       │          │ hardware type       │                   │
1240       ├──────────┼─────────────────────┼───────────────────┤
1241       │skuid     │ UID associated with │ uid               │
1242       │          │ originating socket  │                   │
1243       ├──────────┼─────────────────────┼───────────────────┤
1244       │skgid     │ GID associated with │ gid               │
1245       │          │ originating socket  │                   │
1246       ├──────────┼─────────────────────┼───────────────────┤
1247       │rtclassid │ Routing realm       │ realm             │
1248       ├──────────┼─────────────────────┼───────────────────┤
1249       │ibrname   │ Input bridge inter‐ │ ifname            │
1250       │          │ face name           │                   │
1251       ├──────────┼─────────────────────┼───────────────────┤
1252       │obrname   │ Output  bridge  in‐ │ ifname            │
1253       │          │ terface name        │                   │
1254       ├──────────┼─────────────────────┼───────────────────┤
1255       │pkttype   │ packet type         │ pkt_type          │
1256       ├──────────┼─────────────────────┼───────────────────┤
1257       │cpu       │ cpu number process‐ │ integer (32 bits) │
1258       │          │ ing the packet      │                   │
1259       ├──────────┼─────────────────────┼───────────────────┤
1260       │iifgroup  │ incoming     device │ devgroup          │
1261       │          │ group               │                   │
1262       ├──────────┼─────────────────────┼───────────────────┤
1263       │oifgroup  │ outgoing     device │ devgroup          │
1264       │          │ group               │                   │
1265       ├──────────┼─────────────────────┼───────────────────┤
1266       │cgroup    │ control group id    │ integer (32 bits) │
1267       ├──────────┼─────────────────────┼───────────────────┤
1268       │random    │ pseudo-random  num‐ │ integer (32 bits) │
1269       │          │ ber                 │                   │
1270       ├──────────┼─────────────────────┼───────────────────┤
1271       │secpath   │ boolean             │ boolean (1 bit)   │
1272       └──────────┴─────────────────────┴───────────────────┘
1273       Meta expression specific types
1274
1275       ┌──────────────┬────────────────────────────┐
1276       │Type          │ Description                │
1277       ├──────────────┼────────────────────────────┤
1278       │iface_index   │ Interface  index  (32  bit │
1279       │              │ number).  Can be specified │
1280       │              │ numerically or as name  of │
1281       │              │ an existing interface.     │
1282       ├──────────────┼────────────────────────────┤
1283       │ifname        │ Interface  name  (16  byte │
1284       │              │ string). Does not have  to │
1285       │              │ exist.                     │
1286       ├──────────────┼────────────────────────────┤
1287       │iface_type    │ Interface   type  (16  bit │
1288       │              │ number).                   │
1289       ├──────────────┼────────────────────────────┤
1290       │uid           │ User ID (32  bit  number). │
1291       │              │ Can  be  specified numeri‐ │
1292       │              │ cally or as user name.     │
1293       ├──────────────┼────────────────────────────┤
1294       │gid           │ Group ID (32 bit  number). │
1295       │              │ Can  be  specified numeri‐ │
1296       │              │ cally or as group name.    │
1297       ├──────────────┼────────────────────────────┤
1298       │realm         │ Routing Realm (32 bit num‐ │
1299       │              │ ber). Can be specified nu‐ │
1300       │              │ merically or  as  symbolic │
1301       │              │ name       defined      in │
1302       │              │ /etc/iproute2/rt_realms.   │
1303       ├──────────────┼────────────────────────────┤
1304       │devgroup_type │ Device group (32 bit  num‐ │
1305       │              │ ber). Can be specified nu‐ │
1306       │              │ merically or  as  symbolic │
1307       │              │ name       defined      in │
1308       │              │ /etc/iproute2/group.       │
1309       ├──────────────┼────────────────────────────┤
1310       │pkt_type      │ Packet  type:  host   (ad‐ │
1311       │              │ dressed  to  local  host), │
1312       │              │ broadcast (to all), multi‐ │
1313       │              │ cast   (to  group),  other │
1314       │              │ (addressed   to    another │
1315       │              │ host).                     │
1316       └──────────────┴────────────────────────────┘
1317       Using meta expressions
1318
1319       # qualified meta expression
1320       filter output meta oif eth0
1321
1322       # unqualified meta expression
1323       filter output oif eth0
1324
1325       # packed was subject to ipsec processing
1326       raw prerouting meta secpath exists accept
1327
1328   FIB EXPRESSIONS
1329       fib {saddr | daddr | {mark | iif | oif}} {oif | oifname | type}
1330
1331       A  fib  expression queries the fib (forwarding information base) to ob‐
1332       tain information such as the output interface index  a  particular  ad‐
1333       dress would use. The input is a tuple of elements that is used as input
1334       to the fib lookup functions.
1335
1336       fib expression specific types
1337
1338       ┌────────┬─────────────────────┬──────────────────┐
1339       │Keyword │ Description         │ Type             │
1340       ├────────┼─────────────────────┼──────────────────┤
1341       │oif     │ Output    interface │ integer (32 bit) │
1342       │        │ index               │                  │
1343       ├────────┼─────────────────────┼──────────────────┤
1344       │oifname │ Output    interface │ string           │
1345       │        │ name                │                  │
1346       ├────────┼─────────────────────┼──────────────────┤
1347       │type    │ Address type        │ fib_addrtype     │
1348       └────────┴─────────────────────┴──────────────────┘
1349       Using fib expressions
1350
1351       # drop packets without a reverse path
1352       filter prerouting fib saddr . iif oif missing drop
1353
1354       # drop packets to address not configured on ininterface
1355       filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
1356
1357       # perform lookup in a specific 'blackhole' table (0xdead, needs ip appropriate ip rule)
1358       filter prerouting meta mark set 0xdead fib daddr . mark type vmap { blackhole : drop, prohibit : jump prohibited, unreachable : drop }
1359
1360   ROUTING EXPRESSIONS
1361       rt {classid | nexthop}
1362
1363       A routing expression refers to routing data associated with a packet.
1364
1365       Routing expression types
1366
1367       ┌────────┬─────────────────────┬─────────────────────┐
1368       │Keyword │ Description         │ Type                │
1369       ├────────┼─────────────────────┼─────────────────────┤
1370       │classid │ Routing realm       │ realm               │
1371       ├────────┼─────────────────────┼─────────────────────┤
1372       │nexthop │ Routing nexthop     │ ipv4_addr/ipv6_addr │
1373       ├────────┼─────────────────────┼─────────────────────┤
1374       │mtu     │ TCP maximum segment │ integer (16 bit)    │
1375       │        │ size of route       │                     │
1376       └────────┴─────────────────────┴─────────────────────┘
1377       Routing expression specific types
1378
1379       ┌──────┬────────────────────────────┐
1380       │Type  │ Description                │
1381       ├──────┼────────────────────────────┤
1382       │realm │ Routing Realm (32 bit num‐ │
1383       │      │ ber). Can be specified nu‐ │
1384       │      │ merically  or  as symbolic │
1385       │      │ name      defined       in │
1386       │      │ /etc/iproute2/rt_realms.   │
1387       └──────┴────────────────────────────┘
1388       Using routing expressions
1389
1390       # IP family independent rt expression
1391       filter output rt classid 10
1392
1393       # IP family dependent rt expressions
1394       ip filter output rt nexthop 192.168.0.1
1395       ip6 filter output rt nexthop fd00::1
1396       inet filter output rt ip nexthop 192.168.0.1
1397       inet filter output rt ip6 nexthop fd00::1
1398

PAYLOAD EXPRESSIONS

1400       Payload expressions refer to data from the packet's payload.
1401
1402   ETHERNET HEADER EXPRESSION
1403       ether [Ethernet header field]
1404
1405       Ethernet header expression types
1406
1407       ┌────────┬─────────────────────┬────────────┐
1408       │Keyword │ Description         │ Type       │
1409       ├────────┼─────────────────────┼────────────┤
1410       │daddr   │ Destination MAC ad‐ │ ether_addr │
1411       │        │ dress               │            │
1412       ├────────┼─────────────────────┼────────────┤
1413       │saddr   │ Source MAC address  │ ether_addr │
1414       ├────────┼─────────────────────┼────────────┤
1415       │type    │ EtherType           │ ether_type │
1416       └────────┴─────────────────────┴────────────┘
1417   VLAN HEADER EXPRESSION
1418       vlan [VLAN header field]
1419
1420       VLAN header expression
1421
1422       ┌────────┬─────────────────────┬──────────────────┐
1423       │Keyword │ Description         │ Type             │
1424       ├────────┼─────────────────────┼──────────────────┤
1425       │id      │ VLAN ID (VID)       │ integer (12 bit) │
1426       ├────────┼─────────────────────┼──────────────────┤
1427       │cfi     │ Canonical    Format │ integer (1 bit)  │
1428       │        │ Indicator           │                  │
1429       ├────────┼─────────────────────┼──────────────────┤
1430       │pcp     │ Priority code point │ integer (3 bit)  │
1431       ├────────┼─────────────────────┼──────────────────┤
1432       │type    │ EtherType           │ ether_type       │
1433       └────────┴─────────────────────┴──────────────────┘
1434   ARP HEADER EXPRESSION
1435       arp [ARP header field]
1436
1437       ARP header expression
1438
1439       ┌──────────┬─────────────────────┬──────────────────┐
1440       │Keyword   │ Description         │ Type             │
1441       ├──────────┼─────────────────────┼──────────────────┤
1442       │htype     │ ARP hardware type   │ integer (16 bit) │
1443       ├──────────┼─────────────────────┼──────────────────┤
1444       │ptype     │ EtherType           │ ether_type       │
1445       ├──────────┼─────────────────────┼──────────────────┤
1446       │hlen      │ Hardware    address │ integer (8 bit)  │
1447       │          │ len                 │                  │
1448       ├──────────┼─────────────────────┼──────────────────┤
1449       │plen      │ Protocol    address │ integer (8 bit)  │
1450       │          │ len                 │                  │
1451       ├──────────┼─────────────────────┼──────────────────┤
1452       │operation │ Operation           │ arp_op           │
1453       └──────────┴─────────────────────┴──────────────────┘
1454   IPV4 HEADER EXPRESSION
1455       ip [IPv4 header field]
1456
1457       IPv4 header expression
1458
1459       ┌──────────┬─────────────────────┬─────────────────────┐
1460       │Keyword   │ Description         │ Type                │
1461       ├──────────┼─────────────────────┼─────────────────────┤
1462       │version   │ IP  header  version │ integer (4 bit)     │
1463       │          │ (4)                 │                     │
1464       ├──────────┼─────────────────────┼─────────────────────┤
1465       │hdrlength │ IP  header   length │ integer   (4   bit) │
1466       │          │ including options   │ FIXME scaling       │
1467       ├──────────┼─────────────────────┼─────────────────────┤
1468       │dscp      │ Differentiated Ser‐ │ dscp                │
1469       │          │ vices Code Point    │                     │
1470       ├──────────┼─────────────────────┼─────────────────────┤
1471       │ecn       │ Explicit Congestion │ ecn                 │
1472       │          │ Notification        │                     │
1473       ├──────────┼─────────────────────┼─────────────────────┤
1474       │length    │ Total packet length │ integer (16 bit)    │
1475       ├──────────┼─────────────────────┼─────────────────────┤
1476       │id        │ IP ID               │ integer (16 bit)    │
1477       ├──────────┼─────────────────────┼─────────────────────┤
1478       │frag-off  │ Fragment offset     │ integer (16 bit)    │
1479       ├──────────┼─────────────────────┼─────────────────────┤
1480       │ttl       │ Time to live        │ integer (8 bit)     │
1481       ├──────────┼─────────────────────┼─────────────────────┤
1482       │protocol  │ Upper layer  proto‐ │ inet_proto          │
1483       │          │ col                 │                     │
1484       ├──────────┼─────────────────────┼─────────────────────┤
1485       │checksum  │ IP header checksum  │ integer (16 bit)    │
1486       ├──────────┼─────────────────────┼─────────────────────┤
1487       │saddr     │ Source address      │ ipv4_addr           │
1488       ├──────────┼─────────────────────┼─────────────────────┤
1489       │daddr     │ Destination address │ ipv4_addr           │
1490       └──────────┴─────────────────────┴─────────────────────┘
1491   ICMP HEADER EXPRESSION
1492       icmp [ICMP header field]
1493
1494       ICMP header expression
1495
1496       ┌─────────┬─────────────────────┬──────────────────┐
1497       │Keyword  │ Description         │ Type             │
1498       ├─────────┼─────────────────────┼──────────────────┤
1499       │type     │ ICMP type field     │ icmp_type        │
1500       ├─────────┼─────────────────────┼──────────────────┤
1501       │code     │ ICMP code field     │ integer (8 bit)  │
1502       ├─────────┼─────────────────────┼──────────────────┤
1503       │checksum │ ICMP checksum field │ integer (16 bit) │
1504       ├─────────┼─────────────────────┼──────────────────┤
1505       │id       │ ID   of   echo  re‐ │ integer (16 bit) │
1506       │         │ quest/response      │                  │
1507       ├─────────┼─────────────────────┼──────────────────┤
1508       │sequence │ sequence number  of │ integer (16 bit) │
1509       │         │ echo    request/re‐ │                  │
1510       │         │ sponse              │                  │
1511       ├─────────┼─────────────────────┼──────────────────┤
1512       │gateway  │ gateway  of   redi‐ │ integer (32 bit) │
1513       │         │ rects               │                  │
1514       ├─────────┼─────────────────────┼──────────────────┤
1515       │mtu      │ MTU   of  path  MTU │ integer (16 bit) │
1516       │         │ discovery           │                  │
1517       └─────────┴─────────────────────┴──────────────────┘
1518   IPV6 HEADER EXPRESSION
1519       ip6 [IPv6 header field]
1520
1521       This expression refers to the ipv6 header fields.  Caution  when  using
1522       ip6 nexthdr, the value only refers to the next header, i.e. ip6 nexthdr
1523       tcp will only match if the ipv6 packet does not contain  any  extension
1524       headers.  Packets  that are fragmented or e.g. contain a routing exten‐
1525       sion headers will not be matched.  Please use meta l4proto if you  wish
1526       to  match the real transport header and ignore any additional extension
1527       headers instead.
1528
1529       IPv6 header expression
1530
1531       ┌──────────┬─────────────────────┬──────────────────┐
1532       │Keyword   │ Description         │ Type             │
1533       ├──────────┼─────────────────────┼──────────────────┤
1534       │version   │ IP  header  version │ integer (4 bit)  │
1535       │          │ (6)                 │                  │
1536       ├──────────┼─────────────────────┼──────────────────┤
1537       │dscp      │ Differentiated Ser‐ │ dscp             │
1538       │          │ vices Code Point    │                  │
1539       ├──────────┼─────────────────────┼──────────────────┤
1540       │ecn       │ Explicit Congestion │ ecn              │
1541       │          │ Notification        │                  │
1542       ├──────────┼─────────────────────┼──────────────────┤
1543       │flowlabel │ Flow label          │ integer (20 bit) │
1544       ├──────────┼─────────────────────┼──────────────────┤
1545       │length    │ Payload length      │ integer (16 bit) │
1546       ├──────────┼─────────────────────┼──────────────────┤
1547       │nexthdr   │ Nexthdr protocol    │ inet_proto       │
1548       ├──────────┼─────────────────────┼──────────────────┤
1549       │hoplimit  │ Hop limit           │ integer (8 bit)  │
1550       ├──────────┼─────────────────────┼──────────────────┤
1551       │saddr     │ Source address      │ ipv6_addr        │
1552       ├──────────┼─────────────────────┼──────────────────┤
1553       │daddr     │ Destination address │ ipv6_addr        │
1554       └──────────┴─────────────────────┴──────────────────┘
1555       matching if first extension header indicates a fragment
1556
1557       ip6 nexthdr ipv6-frag counter
1558
1559   ICMPV6 HEADER EXPRESSION
1560       icmpv6 [ICMPv6 header field]
1561
1562       ICMPv6 header expression
1563
1564       ┌──────────────────┬─────────────────────┬──────────────────┐
1565       │Keyword           │ Description         │ Type             │
1566       ├──────────────────┼─────────────────────┼──────────────────┤
1567       │type              │ ICMPv6 type field   │ icmpv6_type      │
1568       ├──────────────────┼─────────────────────┼──────────────────┤
1569       │code              │ ICMPv6 code field   │ integer (8 bit)  │
1570       ├──────────────────┼─────────────────────┼──────────────────┤
1571       │checksum          │ ICMPv6     checksum │ integer (16 bit) │
1572       │                  │ field               │                  │
1573       ├──────────────────┼─────────────────────┼──────────────────┤
1574       │parameter-problem │ pointer to problem  │ integer (32 bit) │
1575       ├──────────────────┼─────────────────────┼──────────────────┤
1576       │packet-too-big    │ oversized MTU       │ integer (32 bit) │
1577       ├──────────────────┼─────────────────────┼──────────────────┤
1578       │id                │ ID  of   echo   re‐ │ integer (16 bit) │
1579       │                  │ quest/response      │                  │
1580       ├──────────────────┼─────────────────────┼──────────────────┤
1581       │sequence          │ sequence  number of │ integer (16 bit) │
1582       │                  │ echo    request/re‐ │                  │
1583       │                  │ sponse              │                  │
1584       ├──────────────────┼─────────────────────┼──────────────────┤
1585       │max-delay         │ maximum    response │ integer (16 bit) │
1586       │                  │ delay    of     MLD │                  │
1587       │                  │ queries             │                  │
1588       └──────────────────┴─────────────────────┴──────────────────┘
1589   TCP HEADER EXPRESSION
1590       tcp [TCP header field]
1591
1592       TCP header expression
1593
1594       ┌─────────┬──────────────────┬─────────────────────┐
1595       │Keyword  │ Description      │ Type                │
1596       ├─────────┼──────────────────┼─────────────────────┤
1597       │sport    │ Source port      │ inet_service        │
1598       ├─────────┼──────────────────┼─────────────────────┤
1599       │dport    │ Destination port │ inet_service        │
1600       ├─────────┼──────────────────┼─────────────────────┤
1601       │sequence │ Sequence number  │ integer (32 bit)    │
1602       ├─────────┼──────────────────┼─────────────────────┤
1603       │ackseq   │ Acknowledgement  │ integer (32 bit)    │
1604       │         │ number           │                     │
1605       ├─────────┼──────────────────┼─────────────────────┤
1606       │doff     │ Data offset      │ integer   (4   bit) │
1607       │         │                  │ FIXME scaling       │
1608       ├─────────┼──────────────────┼─────────────────────┤
1609       │reserved │ Reserved area    │ integer (4 bit)     │
1610       ├─────────┼──────────────────┼─────────────────────┤
1611       │flags    │ TCP flags        │ tcp_flag            │
1612       ├─────────┼──────────────────┼─────────────────────┤
1613       │window   │ Window           │ integer (16 bit)    │
1614       ├─────────┼──────────────────┼─────────────────────┤
1615       │checksum │ Checksum         │ integer (16 bit)    │
1616       ├─────────┼──────────────────┼─────────────────────┤
1617       │urgptr   │ Urgent pointer   │ integer (16 bit)    │
1618       └─────────┴──────────────────┴─────────────────────┘
1619   UDP HEADER EXPRESSION
1620       udp [UDP header field]
1621
1622       UDP header expression
1623
1624       ┌─────────┬─────────────────────┬──────────────────┐
1625       │Keyword  │ Description         │ Type             │
1626       ├─────────┼─────────────────────┼──────────────────┤
1627       │sport    │ Source port         │ inet_service     │
1628       ├─────────┼─────────────────────┼──────────────────┤
1629       │dport    │ Destination port    │ inet_service     │
1630       ├─────────┼─────────────────────┼──────────────────┤
1631       │length   │ Total packet length │ integer (16 bit) │
1632       ├─────────┼─────────────────────┼──────────────────┤
1633       │checksum │ Checksum            │ integer (16 bit) │
1634       └─────────┴─────────────────────┴──────────────────┘
1635   UDP-LITE HEADER EXPRESSION
1636       udplite [UDP-Lite header field]
1637
1638       UDP-Lite header expression
1639
1640       ┌─────────┬──────────────────┬──────────────────┐
1641       │Keyword  │ Description      │ Type             │
1642       ├─────────┼──────────────────┼──────────────────┤
1643       │sport    │ Source port      │ inet_service     │
1644       ├─────────┼──────────────────┼──────────────────┤
1645       │dport    │ Destination port │ inet_service     │
1646       ├─────────┼──────────────────┼──────────────────┤
1647       │checksum │ Checksum         │ integer (16 bit) │
1648       └─────────┴──────────────────┴──────────────────┘
1649   SCTP HEADER EXPRESSION
1650       sctp [SCTP header field]
1651
1652       SCTP header expression
1653
1654       ┌─────────┬──────────────────┬──────────────────┐
1655       │Keyword  │ Description      │ Type             │
1656       ├─────────┼──────────────────┼──────────────────┤
1657       │sport    │ Source port      │ inet_service     │
1658       ├─────────┼──────────────────┼──────────────────┤
1659       │dport    │ Destination port │ inet_service     │
1660       ├─────────┼──────────────────┼──────────────────┤
1661       │vtag     │ Verification Tag │ integer (32 bit) │
1662       ├─────────┼──────────────────┼──────────────────┤
1663       │checksum │ Checksum         │ integer (32 bit) │
1664       └─────────┴──────────────────┴──────────────────┘
1665   DCCP HEADER EXPRESSION
1666       dccp [DCCP header field]
1667
1668       DCCP header expression
1669
1670       ┌────────┬──────────────────┬──────────────┐
1671       │Keyword │ Description      │ Type         │
1672       ├────────┼──────────────────┼──────────────┤
1673       │sport   │ Source port      │ inet_service │
1674       ├────────┼──────────────────┼──────────────┤
1675       │dport   │ Destination port │ inet_service │
1676       └────────┴──────────────────┴──────────────┘
1677   AUTHENTICATION HEADER EXPRESSION
1678       ah [AH header field]
1679
1680       AH header expression
1681
1682       ┌──────────┬─────────────────────┬──────────────────┐
1683       │Keyword   │ Description         │ Type             │
1684       ├──────────┼─────────────────────┼──────────────────┤
1685       │nexthdr   │ Next  header proto‐ │ inet_proto       │
1686       │          │ col                 │                  │
1687       ├──────────┼─────────────────────┼──────────────────┤
1688       │hdrlength │ AH Header length    │ integer (8 bit)  │
1689       ├──────────┼─────────────────────┼──────────────────┤
1690       │reserved  │ Reserved area       │ integer (16 bit) │
1691       ├──────────┼─────────────────────┼──────────────────┤
1692       │spi       │ Security  Parameter │ integer (32 bit) │
1693       │          │ Index               │                  │
1694       ├──────────┼─────────────────────┼──────────────────┤
1695       │sequence  │ Sequence number     │ integer (32 bit) │
1696       └──────────┴─────────────────────┴──────────────────┘
1697   ENCRYPTED SECURITY PAYLOAD HEADER EXPRESSION
1698       esp [ESP header field]
1699
1700       ESP header expression
1701
1702       ┌─────────┬─────────────────────┬──────────────────┐
1703       │Keyword  │ Description         │ Type             │
1704       ├─────────┼─────────────────────┼──────────────────┤
1705       │spi      │ Security  Parameter │ integer (32 bit) │
1706       │         │ Index               │                  │
1707       ├─────────┼─────────────────────┼──────────────────┤
1708       │sequence │ Sequence number     │ integer (32 bit) │
1709       └─────────┴─────────────────────┴──────────────────┘
1710   IPCOMP HEADER EXPRESSION
1711       comp [IPComp header field]
1712
1713       IPComp header expression
1714
1715       ┌────────┬─────────────────────┬──────────────────┐
1716       │Keyword │ Description         │ Type             │
1717       ├────────┼─────────────────────┼──────────────────┤
1718       │nexthdr │ Next header  proto‐ │ inet_proto       │
1719       │        │ col                 │                  │
1720       ├────────┼─────────────────────┼──────────────────┤
1721       │flags   │ Flags               │ bitmask          │
1722       ├────────┼─────────────────────┼──────────────────┤
1723       │cpi     │ Compression Parame‐ │ integer (16 bit) │
1724       │        │ ter Index           │                  │
1725       └────────┴─────────────────────┴──────────────────┘
1726   RAW PAYLOAD EXPRESSION
1727       @ [base,offset,length]
1728
1729       The raw payload expression instructs to  load  lengthbits  starting  at
1730       offsetbits.   Bit  0 refers the the very first bit -- in the C program‐
1731       ming language, this corresponds to the topmost bit, i.e. 0x80  in  case
1732       of  an  octet.  They are useful to match headers that do not have a hu‐
1733       man-readable template expression yet.  Note that nft will not  add  de‐
1734       pendencies for Raw payload expressions.  If you e.g. want to match pro‐
1735       tocol fields of a transport header with protocol number 5, you need  to
1736       manually  exclude  packets  that have a different transport header, for
1737       instance my using meta l4proto 5 before the raw expression.
1738
1739       Supported payload protocol bases
1740
1741       ┌─────┬────────────────────────────┐
1742       │Base │ Description                │
1743       ├─────┼────────────────────────────┤
1744       │ll   │ Link  layer,  for  example │
1745       │     │ the Ethernet header        │
1746       ├─────┼────────────────────────────┤
1747       │nh   │ Network  header, for exam‐ │
1748       │     │ ple IPv4 or IPv6           │
1749       ├─────┼────────────────────────────┤
1750       │th   │ Transport Header, for  ex‐ │
1751       │     │ ample TCP                  │
1752       └─────┴────────────────────────────┘
1753       Matching destination port of both UDP and TCP
1754
1755       inet filter input meta l4proto {tcp, udp} @th,16,16 { dns, http }
1756
1757       Rewrite  arp  packet target hardware address if target protocol address
1758       matches a given address
1759
1760       input meta iifname enp2s0 arp ptype 0x0800 arp htype 1 arp hlen 6 arp plen 4 @nh,192,32 0xc0a88f10 @nh,144,48 set 0x112233445566 accept
1761
1762   EXTENSION HEADER EXPRESSIONS
1763       Extension header expressions refer to data from variable-sized protocol
1764       headers, such as IPv6 extension headers and TCP options.
1765
1766       nftables  currently  supports matching (finding) a given ipv6 extension
1767       header or TCP option.
1768       hbh {nexthdr | hdrlength}
1769       frag {nexthdr | frag-off | more-fragments | id}
1770       rt {nexthdr | hdrlength | type | seg-left}
1771       dst {nexthdr | hdrlength}
1772       mh {nexthdr | hdrlength | checksum | type}
1773       srh {flags | tag | sid | seg-left}
1774       tcp option {eol | noop | maxseg | window | sack-permitted | sack |
1775                  sack0 | sack1 | sack2 | sack3 | timestamp} tcp_option_field
1776
1777       The  following  syntaxes are valid only in a relational expression with
1778       boolean type on right-hand side for checking header existence only:
1779       exthdr {hbh | frag | rt | dst | mh}
1780       tcp option {eol | noop | maxseg | window | sack-permitted | sack |
1781                  sack0 | sack1 | sack2 | sack3 | timestamp}
1782
1783       IPv6 extension headers
1784
1785       ┌────────┬────────────────────────┐
1786       │Keyword │ Description            │
1787       ├────────┼────────────────────────┤
1788       │hbh     │ Hop by Hop             │
1789       ├────────┼────────────────────────┤
1790       │rt      │ Routing Header         │
1791       ├────────┼────────────────────────┤
1792       │frag    │ Fragmentation header   │
1793       ├────────┼────────────────────────┤
1794       │dst     │ dst options            │
1795       ├────────┼────────────────────────┤
1796       │mh      │ Mobility Header        │
1797       ├────────┼────────────────────────┤
1798       │srh     │ Segment Routing Header │
1799       └────────┴────────────────────────┘
1800       TCP Options
1801
1802       ┌───────────────┬─────────────────────┬─────────────────────┐
1803       │Keyword        │ Description         │ TCP option fields   │
1804       ├───────────────┼─────────────────────┼─────────────────────┤
1805       │eol            │ End of option list  │ kind                │
1806       ├───────────────┼─────────────────────┼─────────────────────┤
1807       │noop           │ 1  Byte  TCP  No-op │ kind                │
1808       │               │ options             │                     │
1809       ├───────────────┼─────────────────────┼─────────────────────┤
1810       │maxseg         │ TCP Maximum Segment │ kind, length, size  │
1811       │               │ Size                │                     │
1812       ├───────────────┼─────────────────────┼─────────────────────┤
1813       │window         │ TCP Window Scaling  │ kind, length, count │
1814       ├───────────────┼─────────────────────┼─────────────────────┤
1815       │sack-permitted │ TCP SACK permitted  │ kind, length        │
1816       ├───────────────┼─────────────────────┼─────────────────────┤
1817       │sack           │ TCP  Selective  Ac‐ │ kind, length, left, │
1818       │               │ knowledgement       │ right               │
1819       │               │ (alias of block 0)  │                     │
1820       ├───────────────┼─────────────────────┼─────────────────────┤
1821       │sack0          │ TCP  Selective  Ac‐ │ kind, length, left, │
1822       │               │ knowledgement       │ right               │
1823       │               │ (block 0)           │                     │
1824       ├───────────────┼─────────────────────┼─────────────────────┤
1825       │sack1          │ TCP  Selective  Ac‐ │ kind, length, left, │
1826       │               │ knowledgement       │ right               │
1827       │               │ (block 1)           │                     │
1828       ├───────────────┼─────────────────────┼─────────────────────┤
1829       │sack2          │ TCP  Selective  Ac‐ │ kind, length, left, │
1830       │               │ knowledgement       │ right               │
1831       │               │ (block 2)           │                     │
1832       ├───────────────┼─────────────────────┼─────────────────────┤
1833       │sack3          │ TCP  Selective  Ac‐ │ kind, length, left, │
1834       │               │ knowledgement       │ right               │
1835       │               │ (block 3)           │                     │
1836       ├───────────────┼─────────────────────┼─────────────────────┤
1837       │timestamp      │ TCP Timestamps      │ kind,       length, │
1838       │               │                     │ tsval, tsecr        │
1839       └───────────────┴─────────────────────┴─────────────────────┘
1840       finding TCP options
1841
1842       filter input tcp option sack-permitted kind 1 counter
1843
1844       matching IPv6 exthdr
1845
1846       ip6 filter input frag more-fragments 1 counter
1847
1848   CONNTRACK EXPRESSIONS
1849       Conntrack expressions refer to meta data of the connection tracking en‐
1850       try associated with a packet.
1851
1852       There are three types of conntrack expressions. Some conntrack  expres‐
1853       sions  require the flow direction before the conntrack key, others must
1854       be used directly because they are  direction  agnostic.   The  packets,
1855       bytes  and  avgpkt keywords can be used with or without a direction. If
1856       the direction is omitted, the sum of the original and the reply  direc‐
1857       tion is returned. The same is true for the zone, if a direction is giv‐
1858       en, the zone is only matched if the zone id is tied to the given direc‐
1859       tion.
1860
1861       ct {state | direction | status | mark | expiration | helper | label |
1862          l3proto | protocol | bytes | packets | avgpkt | zone}
1863       ct {original | reply} {l3proto | protocol | proto-src | proto-dst |
1864          bytes | packets | avgpkt | zone}
1865       ct {original | reply} {ip | ip6} {saddr | daddr}
1866
1867       Conntrack expressions
1868
1869       ┌───────────┬─────────────────────┬─────────────────────┐
1870       │Keyword    │ Description         │ Type                │
1871       ├───────────┼─────────────────────┼─────────────────────┤
1872       │state      │ State  of  the con‐ │ ct_state            │
1873       │           │ nection             │                     │
1874       ├───────────┼─────────────────────┼─────────────────────┤
1875       │direction  │ Direction  of   the │ ct_dir              │
1876       │           │ packet  relative to │                     │
1877       │           │ the connection      │                     │
1878       ├───────────┼─────────────────────┼─────────────────────┤
1879       │status     │ Status of the  con‐ │ ct_status           │
1880       │           │ nection             │                     │
1881       ├───────────┼─────────────────────┼─────────────────────┤
1882       │mark       │ Connection mark     │ mark                │
1883       ├───────────┼─────────────────────┼─────────────────────┤
1884       │expiration │ Connection  expira‐ │ time                │
1885       │           │ tion time           │                     │
1886       ├───────────┼─────────────────────┼─────────────────────┤
1887       │helper     │ Helper   associated │ string              │
1888       │           │ with the connection │                     │
1889       ├───────────┼─────────────────────┼─────────────────────┤
1890       │label      │ Connection tracking │ ct_label            │
1891       │           │ label bit  or  sym‐ │                     │
1892       │           │ bolic  name defined │                     │
1893       │           │ in   connlabel.conf │                     │
1894       │           │ in the nftables in‐ │                     │
1895       │           │ clude path          │                     │
1896       ├───────────┼─────────────────────┼─────────────────────┤
1897       │l3proto    │ Layer 3 protocol of │ nf_proto            │
1898       │           │ the connection      │                     │
1899       ├───────────┼─────────────────────┼─────────────────────┤
1900       │saddr      │ Source  address  of │ ipv4_addr/ipv6_addr │
1901       │           │ the connection  for │                     │
1902       │           │ the given direction │                     │
1903       ├───────────┼─────────────────────┼─────────────────────┤
1904       │daddr      │ Destination address │ ipv4_addr/ipv6_addr │
1905       │           │ of  the  connection │                     │
1906       │           │ for  the  given di‐ │                     │
1907       │           │ rection             │                     │
1908       ├───────────┼─────────────────────┼─────────────────────┤
1909       │protocol   │ Layer 4 protocol of │ inet_proto          │
1910       │           │ the  connection for │                     │
1911       │           │ the given direction │                     │
1912       ├───────────┼─────────────────────┼─────────────────────┤
1913       │proto-src  │ Layer  4   protocol │ integer (16 bit)    │
1914       │           │ source for the giv‐ │                     │
1915       │           │ en direction        │                     │
1916       ├───────────┼─────────────────────┼─────────────────────┤
1917       │proto-dst  │ Layer  4   protocol │ integer (16 bit)    │
1918       │           │ destination for the │                     │
1919       │           │ given direction     │                     │
1920       ├───────────┼─────────────────────┼─────────────────────┤
1921       │packets    │ packet  count  seen │ integer (64 bit)    │
1922       │           │ in the given direc‐ │                     │
1923       │           │ tion  or   sum   of │                     │
1924       │           │ original and reply  │                     │
1925       ├───────────┼─────────────────────┼─────────────────────┤
1926       │bytes      │ byte   count  seen, │ integer (64 bit)    │
1927       │           │ see description for │                     │
1928       │           │ packets keyword     │                     │
1929       ├───────────┼─────────────────────┼─────────────────────┤
1930       │avgpkt     │ average  bytes  per │ integer (64 bit)    │
1931       │           │ packet,   see   de‐ │                     │
1932       │           │ scription for pack‐ │                     │
1933       │           │ ets keyword         │                     │
1934       ├───────────┼─────────────────────┼─────────────────────┤
1935       │zone       │ conntrack zone      │ integer (16 bit)    │
1936       └───────────┴─────────────────────┴─────────────────────┘
1937       A description of conntrack-specific types listed  above  can  be  found
1938       sub-section CONNTRACK TYPES above.
1939

STATEMENTS

1941       Statements  represent  actions  to be performed. They can alter control
1942       flow (return, jump to a different chain, accept or drop the packet)  or
1943       can perform actions, such as logging, rejecting a packet, etc.
1944
1945       Statements exist in two kinds. Terminal statements unconditionally ter‐
1946       minate evaluation of the current rule, non-terminal  statements  either
1947       only  conditionally  or never terminate evaluation of the current rule,
1948       in other words, they are passive from the ruleset  evaluation  perspec‐
1949       tive.  There can be an arbitrary amount of non-terminal statements in a
1950       rule, but only a single terminal statement as the final statement.
1951
1952   VERDICT STATEMENT
1953       The verdict statement alters control flow in  the  ruleset  and  issues
1954       policy decisions for packets.
1955
1956       {accept | drop | queue | continue | return}
1957       {jump | goto} chain
1958
1959       accept Terminate ruleset evaluation and accept the packet.
1960
1961       drop   Terminate ruleset evaluation and drop the packet.
1962
1963       queue  Terminate ruleset evaluation and queue the packet to userspace.
1964
1965       continue
1966              Continue ruleset evaluation with the next rule. FIXME
1967
1968       return Return  from  the  current  chain and continue evaluation at the
1969              next rule in the last chain. If issued in a base  chain,  it  is
1970              equivalent to accept.
1971
1972       jump chain
1973              Continue evaluation at the first rule in chain.  The current po‐
1974              sition in the ruleset is pushed to a call stack  and  evaluation
1975              will  continue there when the new chain is entirely evaluated of
1976              a return verdict is issued.
1977
1978       goto chain
1979              Similar to jump, but the current position is not pushed  to  the
1980              call  stack,  meaning  that  after the new chain evaluation will
1981              continue at the last chain instead of the one containing the go‐
1982              to statement.
1983
1984       Verdict statements
1985
1986       # process packets from eth0 and the internal network in from_lan
1987       # chain, drop all packets from eth0 with different source addresses.
1988
1989       filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan
1990       filter input iif eth0 drop
1991
1992   PAYLOAD STATEMENT
1993       The  payload statement alters packet content.  It can be used for exam‐
1994       ple to set ip DSCP (differv) header field or ipv6 flow labels.
1995
1996       route some packets instead of bridging
1997
1998       # redirect tcp:http from 192.160.0.0/16 to local machine for routing instead of bridging
1999       # assumes 00:11:22:33:44:55 is local MAC address.
2000       bridge input meta iif eth0 ip saddr 192.168.0.0/16 tcp dport 80 meta pkttype set unicast ether daddr set 00:11:22:33:44:55
2001
2002       Set IPv4 DSCP header field
2003
2004       ip forward ip dscp set 42
2005
2006   EXTENSION HEADER STATEMENT
2007       The extension header statement alters packet content in  variable-sized
2008       headers.   This  can currently be used to alter the TCP Maximum segment
2009       size of packets, similar to TCPMSS.
2010
2011       change tcp mss
2012
2013       tcp flags syn tcp option maxseg size set 1360
2014       # set a size based on route information:
2015       tcp flags syn tcp option maxseg size set rt mtu
2016
2017   LOG STATEMENT
2018       log [prefix quoted_string] [level syslog-level] [flags log-flags]
2019       log group nflog_group [prefix quoted_string] [queue-threshold value]
2020           [snaplen size]
2021       log level audit
2022
2023       The log statement enables logging of matching packets. When this state‐
2024       ment is used from a rule, the Linux kernel will print some  information
2025       on  all  matching  packets,  such  as header fields, via the kernel log
2026       (where it can be read with dmesg(1) or read in the syslog).
2027
2028       In the second form of invocation (if 'nflog_group' is  specified),  the
2029       Linux kernel will pass the packet to nfnetlink_log which will multicast
2030       the packet through a netlink socket to the specified  multicast  group.
2031       One  or  more userspace processes may subscribe to the group to receive
2032       the packets, see libnetfilter_queue documentation for details.
2033
2034       In the third form of invocation (if level audit is specified), the Lin‐
2035       ux kernel writes a message into the audit buffer suitably formatted for
2036       reading with auditd. Therefore no further formatting options  (such  as
2037       prefix or flags) are allowed in this mode.
2038
2039       This  is  a non-terminating statement, so the rule evaluation continues
2040       after the packet is logged.
2041
2042       log statement options
2043
2044       ┌────────────────┬─────────────────────┬─────────────────────┐
2045       │Keyword         │ Description         │ Type                │
2046       ├────────────────┼─────────────────────┼─────────────────────┤
2047       │prefix          │ Log message prefix  │ quoted string       │
2048       ├────────────────┼─────────────────────┼─────────────────────┤
2049       │level           │ Syslog   level   of │ string:      emerg, │
2050       │                │ logging             │ alert,  crit,  err, │
2051       │                │                     │ warn [default], no‐ │
2052       │                │                     │ tice, info, debug   │
2053       ├────────────────┼─────────────────────┼─────────────────────┤
2054       │group           │ NFLOG group to send │ unsigned    integer │
2055       │                │ messages to         │ (16 bit)            │
2056       ├────────────────┼─────────────────────┼─────────────────────┤
2057       │snaplen         │ Length  of   packet │ unsigned    integer │
2058       │                │ payload  to include │ (32 bit)            │
2059       │                │ in netlink message  │                     │
2060       ├────────────────┼─────────────────────┼─────────────────────┤
2061       │queue-threshold │ Number  of  packets │ unsigned    integer │
2062       │                │ to queue inside the │ (32 bit)            │
2063       │                │ kernel before send‐ │                     │
2064       │                │ ing     them     to │                     │
2065       │                │ userspace           │                     │
2066       └────────────────┴─────────────────────┴─────────────────────┘
2067       log-flags
2068
2069       ┌─────────────┬────────────────────────────┐
2070       │Flag         │ Description                │
2071       ├─────────────┼────────────────────────────┤
2072       │tcp sequence │ Log TCP sequence numbers.  │
2073       ├─────────────┼────────────────────────────┤
2074       │tcp options  │ Log options from  the  TCP │
2075       │             │ packet header.             │
2076       ├─────────────┼────────────────────────────┤
2077       │ip options   │ Log   options   from   the │
2078       │             │ IP/IPv6 packet header.     │
2079       ├─────────────┼────────────────────────────┤
2080       │skuid        │ Log  the  userid  of   the │
2081       │             │ process   which  generated │
2082       │             │ the packet.                │
2083       ├─────────────┼────────────────────────────┤
2084       │ether        │ Decode MAC  addresses  and │
2085       │             │ protocol.                  │
2086       ├─────────────┼────────────────────────────┤
2087       │all          │ Enable all log flags list‐ │
2088       │             │ ed above.                  │
2089       └─────────────┴────────────────────────────┘
2090       Using log statement
2091
2092       # log the UID which generated the packet and ip options
2093       ip filter output log flags skuid flags ip options
2094
2095       # log the tcp sequence numbers and tcp options from the TCP packet
2096       ip filter output log flags tcp sequence,options
2097
2098       # enable all supported log flags
2099       ip6 filter output log flags all
2100
2101   REJECT STATEMENT
2102       reject [ with {icmp | icmpv6 | icmpx} type {icmp_code | icmpv6_code |
2103              icmpx_code} ]
2104       reject [ with tcp reset ]
2105
2106       A  reject statement is used to send back an error packet in response to
2107       the matched packet otherwise it is equivalent to drop so it is a termi‐
2108       nating  statement,  ending rule traversal. This statement is only valid
2109       in the input, forward and output chains, and user-defined chains  which
2110       are only called from those chains.
2111
2112       The different ICMP reject variants are meant for use in different table
2113       families:
2114
2115       ┌────────┬────────┬─────────────┐
2116       │Variant │ Family │ Type        │
2117       ├────────┼────────┼─────────────┤
2118       │icmp    │ ip     │ icmp_code   │
2119       ├────────┼────────┼─────────────┤
2120       │icmpv6  │ ip6    │ icmpv6_code │
2121       ├────────┼────────┼─────────────┤
2122       │icmpx   │ inet   │ icmpx_code  │
2123       └────────┴────────┴─────────────┘
2124       For a description of the different types and a list of  supported  key‐
2125       words  refer  to  DATA  TYPES section above.  The common default reject
2126       value is port-unreachable.
2127
2128       Note that in bridge family, reject statement is only  allowed  in  base
2129       chains which hook into input or prerouting.
2130
2131   COUNTER STATEMENT
2132       A counter statement sets the hit count of packets along with the number
2133       of bytes.
2134
2135       counter [ packets number bytes number ]
2136
2137   CONNTRACK STATEMENT
2138       The conntrack statement can be used to set the conntrack mark and  con‐
2139       ntrack labels.
2140
2141       ct {mark | event | label | zone} set value
2142
2143       The ct statement sets meta data associated with a connection.  The zone
2144       id has to be assigned before a conntrack lookup takes place, i.e.  this
2145       has  to be done in prerouting and possibly output (if locally generated
2146       packets need to be placed in a distinct zone), with a hook priority  of
2147       -300.
2148
2149       Conntrack statement types
2150
2151       ┌────────┬─────────────────────┬─────────────────────┐
2152       │Keyword │ Description         │ Value               │
2153       ├────────┼─────────────────────┼─────────────────────┤
2154       │event   │ conntrack     event │ bitmask,    integer │
2155       │        │ bits                │ (32 bit)            │
2156       ├────────┼─────────────────────┼─────────────────────┤
2157       │helper  │ name  of  ct helper │ quoted string       │
2158       │        │ object to assign to │                     │
2159       │        │ the connection      │                     │
2160       ├────────┼─────────────────────┼─────────────────────┤
2161       │mark    │ Connection tracking │ mark                │
2162       │        │ mark                │                     │
2163       ├────────┼─────────────────────┼─────────────────────┤
2164       │label   │ Connection tracking │ label               │
2165       │        │ label               │                     │
2166       ├────────┼─────────────────────┼─────────────────────┤
2167       │zone    │ conntrack zone      │ integer (16 bit)    │
2168       └────────┴─────────────────────┴─────────────────────┘
2169       save packet nfmark in conntrack
2170
2171       ct mark set meta mark
2172
2173       set zone mapped via interface
2174
2175       table inet raw {
2176         chain prerouting {
2177             type filter hook prerouting priority -300;
2178             ct zone set iif map { "eth1" : 1, "veth1" : 2 }
2179         }
2180         chain output {
2181             type filter hook output priority -300;
2182             ct zone set oif map { "eth1" : 1, "veth1" : 2 }
2183         }
2184       }
2185
2186       restrict events reported by ctnetlink
2187
2188       ct event set new,related,destroy
2189
2190   META STATEMENT
2191       A  meta  statement  sets  the value of a meta expression.  The existing
2192       meta fields are: priority, mark, pkttype, nftrace.
2193
2194       meta {mark | priority | pkttype | nftrace} set value
2195
2196       A meta statement sets meta data associated with a packet.
2197
2198       Meta statement types
2199
2200       ┌─────────┬─────────────────────┬───────────┐
2201       │Keyword  │ Description         │ Value     │
2202       ├─────────┼─────────────────────┼───────────┤
2203       │priority │ TC packet priority  │ tc_handle │
2204       ├─────────┼─────────────────────┼───────────┤
2205       │mark     │ Packet mark         │ mark      │
2206       ├─────────┼─────────────────────┼───────────┤
2207       │pkttype  │ packet type         │ pkt_type  │
2208       ├─────────┼─────────────────────┼───────────┤
2209       │nftrace  │ ruleset      packet │ 0, 1      │
2210       │         │ tracing on/off. Use │           │
2211       │         │ monitor trace  com‐ │           │
2212       │         │ mand    to    watch │           │
2213       │         │ traces              │           │
2214       └─────────┴─────────────────────┴───────────┘
2215   LIMIT STATEMENT
2216       limit rate [over] packet_number / {second | minute | hour | day} [burst
2217             packet_number packets]
2218       limit rate [over] byte_number {bytes | kbytes | mbytes} / {second |
2219             minute | hour | day | week} [burst byte_number bytes]
2220
2221       A limit statement matches at a limited rate using a token  bucket  fil‐
2222       ter.  A  rule  using  this  statement  will  match  until this limit is
2223       reached. It can be used in combination with the log statement  to  give
2224       limited  logging.  The  over  keyword, that is optional, makes it match
2225       over the specified rate.
2226
2227       limit statement values
2228
2229       ┌──────────────┬───────────────────┬─────────────────────┐
2230       │Value         │ Description       │ Type                │
2231       ├──────────────┼───────────────────┼─────────────────────┤
2232       │packet_number │ Number of packets │ unsigned    integer │
2233       │              │                   │ (32 bit)            │
2234       ├──────────────┼───────────────────┼─────────────────────┤
2235       │byte_number   │ Number of bytes   │ unsigned    integer │
2236       │              │                   │ (32 bit)            │
2237       └──────────────┴───────────────────┴─────────────────────┘
2238   NAT STATEMENTS
2239       snat to address [:port] [persistent, random, fully-random]
2240       snat to address - address [:port - port] [persistent, random, fully-
2241            random]
2242       dnat to address [:port] [persistent, random, fully-random]
2243       dnat to address [:port - port] [persistent, random, fully-random]
2244       masquerade to [:port] [persistent, random, fully-random]
2245       masquerade to [:port - port] [persistent, random, fully-random]
2246       redirect to [:port] [persistent, random, fully-random]
2247       redirect to [:port - port] [persistent, random, fully-random]
2248
2249       The nat statements are only valid from nat chain types.
2250
2251       The  snat  and masquerade statements specify that the source address of
2252       the packet should  be  modified.  While  snat  is  only  valid  in  the
2253       postrouting  and input chains, masquerade makes sense only in postrout‐
2254       ing. The dnat and redirect statements are only valid in the  prerouting
2255       and  output  chains,  they  specify that the destination address of the
2256       packet should be modified. You can use non-base chains which are called
2257       from base chains of nat chain type too. All future packets in this con‐
2258       nection will also be mangled, and rules should cease being examined.
2259
2260       The masquerade statement is a special form of snat  which  always  uses
2261       the outgoing interface's IP address to translate to. It is particularly
2262       useful on gateways with dynamic (public) IP addresses.
2263
2264       The redirect statement is a special form of dnat  which  always  trans‐
2265       lates  the  destination  address  to  the local host's one. It comes in
2266       handy if one only wants to alter the destination port of incoming traf‐
2267       fic on different interfaces.
2268
2269       Note  that  all  nat statements require both prerouting and postrouting
2270       base chains to be present since otherwise packets on  the  return  path
2271       won't  be  seen  by netfilter and therefore no reverse translation will
2272       take place.
2273
2274       NAT statement values
2275
2276       ┌───────────┬─────────────────────┬─────────────────────┐
2277       │Expression │ Description         │ Type                │
2278       ├───────────┼─────────────────────┼─────────────────────┤
2279       │address    │ Specifies that  the │ ipv4_addr, ipv6_ad‐ │
2280       │           │ source/destination  │ dr,            e.g. │
2281       │           │ address   of    the │ abcd::1234, or  you │
2282       │           │ packet   should  be │ can  use a mapping, │
2283       │           │ modified.  You  may │ e.g. meta mark  map │
2284       │           │ specify  a  mapping │ { 10 : 192.168.1.2, │
2285       │           │ to relate a list of │ 20 : 192.168.1.3 }  │
2286       │           │ tuples  composed of │                     │
2287       │           │ arbitrary   expres‐ │                     │
2288       │           │ sion  key  with ad‐ │                     │
2289       │           │ dress value.        │                     │
2290       ├───────────┼─────────────────────┼─────────────────────┤
2291       │port       │ Specifies that  the │ port   number   (16 │
2292       │           │ source/destination  │ bits)               │
2293       │           │ address   of    the │                     │
2294       │           │ packet   should  be │                     │
2295       │           │ modified.           │                     │
2296       └───────────┴─────────────────────┴─────────────────────┘
2297       NAT statement flags
2298
2299       ┌─────────────┬────────────────────────────┐
2300       │Flag         │ Description                │
2301       ├─────────────┼────────────────────────────┤
2302       │persistent   │ Gives  a  client  the same │
2303       │             │ source-/destination-ad‐    │
2304       │             │ dress for each connection. │
2305       ├─────────────┼────────────────────────────┤
2306       │random       │ If  used then port mapping │
2307       │             │ will be randomized using a │
2308       │             │ random seeded MD5 hash mix │
2309       │             │ using source and  destina‐ │
2310       │             │ tion  address and destina‐ │
2311       │             │ tion port.                 │
2312       ├─────────────┼────────────────────────────┤
2313       │fully-random │ If used then port  mapping │
2314       │             │ is  generated  based  on a │
2315       │             │ 32-bit pseudo-random algo‐ │
2316       │             │ rithm.                     │
2317       └─────────────┴────────────────────────────┘
2318       Using NAT statements
2319
2320       # create a suitable table/chain setup for all further examples
2321       add table nat
2322       add chain nat prerouting { type nat hook prerouting priority 0; }
2323       add chain nat postrouting { type nat hook postrouting priority 100; }
2324
2325       # translate source addresses of all packets leaving via eth0 to address 1.2.3.4
2326       add rule nat postrouting oif eth0 snat to 1.2.3.4
2327
2328       # redirect all traffic entering via eth0 to destination address 192.168.1.120
2329       add rule nat prerouting iif eth0 dnat to 192.168.1.120
2330
2331       # translate source addresses of all packets leaving via eth0 to whatever
2332       # locally generated packets would use as source to reach the same destination
2333       add rule nat postrouting oif eth0 masquerade
2334
2335       # redirect incoming TCP traffic for port 22 to port 2222
2336       add rule nat prerouting tcp dport 22 redirect to :2222
2337
2338   FLOW OFFLOAD STATEMENT
2339       A flow offload statement allows us to select what flows you want to ac‐
2340       celerate forwarding through layer 3 network stack bypass. You  have  to
2341       specify the flowtable name where you want to offload this flow.
2342
2343       flow offload @flowtable
2344
2345   QUEUE STATEMENT
2346       This statement passes the packet to userspace using the nfnetlink_queue
2347       handler. The packet is put into the  queue  identified  by  its  16-bit
2348       queue  number.  Userspace can inspect and modify the packet if desired.
2349       Userspace must then drop or re-inject the packet into the  kernel.  See
2350       libnetfilter_queue documentation for details.
2351
2352       queue [num queue_number] [bypass]
2353       queue [num queue_number_from - queue_number_to] [bypass,fanout]
2354
2355       queue statement values
2356
2357       ┌──────────────────┬─────────────────────┬─────────────────────┐
2358       │Value             │ Description         │ Type                │
2359       ├──────────────────┼─────────────────────┼─────────────────────┤
2360       │queue_number      │ Sets  queue number, │ unsigned    integer │
2361       │                  │ default is 0.       │ (16 bit)            │
2362       ├──────────────────┼─────────────────────┼─────────────────────┤
2363       │queue_number_from │ Sets  initial queue │ unsigned    integer │
2364       │                  │ in  the  range,  if │ (16 bit)            │
2365       │                  │ fanout is used.     │                     │
2366       ├──────────────────┼─────────────────────┼─────────────────────┤
2367       │queue_number_to   │ Sets closing  queue │ unsigned    integer │
2368       │                  │ in  the  range,  if │ (16 bit)            │
2369       │                  │ fanout is used.     │                     │
2370       └──────────────────┴─────────────────────┴─────────────────────┘
2371       queue statement flags
2372
2373       ┌───────┬────────────────────────────┐
2374       │Flag   │ Description                │
2375       ├───────┼────────────────────────────┤
2376       │bypass │ Let  packets go through if │
2377       │       │ userspace application can‐ │
2378       │       │ not back off. Before using │
2379       │       │ this flag, read libnetfil‐ │
2380       │       │ ter_queue    documentation │
2381       │       │ for   performance   tuning │
2382       │       │ recommendations.           │
2383       ├───────┼────────────────────────────┤
2384       │fanout │ Distribute packets between │
2385       │       │ several queues.            │
2386       └───────┴────────────────────────────┘
2387   DUP STATEMENT
2388       The dup statement is used to duplicate a packet and send the copy to  a
2389       different destination.
2390
2391       dup to device
2392       dup to address device device
2393
2394       Dup statement values
2395
2396       ┌───────────┬─────────────────────┬─────────────────────┐
2397       │Expression │ Description         │ Type                │
2398       ├───────────┼─────────────────────┼─────────────────────┤
2399       │address    │ Specifies  that the │ ipv4_addr, ipv6_ad‐ │
2400       │           │ copy of the  packet │ dr,            e.g. │
2401       │           │ should be sent to a │ abcd::1234, or  you │
2402       │           │ new gateway.        │ can  use a mapping, │
2403       │           │                     │ e.g. ip saddr map { │
2404       │           │                     │ 192.168.1.2       : │
2405       │           │                     │ 10.1.1.1 }          │
2406       ├───────────┼─────────────────────┼─────────────────────┤
2407       │device     │ Specifies that  the │ string              │
2408       │           │ copy    should   be │                     │
2409       │           │ transmitted via de‐ │                     │
2410       │           │ vice.               │                     │
2411       └───────────┴─────────────────────┴─────────────────────┘
2412       Using the dup statement
2413
2414       # send to machine with ip address 10.2.3.4 on eth0
2415       ip filter forward dup to 10.2.3.4 device "eth0"
2416
2417       # copy raw frame to another interface
2418       netdetv ingress dup to "eth0"
2419       dup to "eth0"
2420
2421       # combine with map dst addr to gateways
2422       dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" }
2423
2424   FWD STATEMENT
2425       The  fwd  statement  is used to redirect a raw packet to another inter‐
2426       face. Its is only available in the netdev family ingress hook.   It  is
2427       similar to the dup statement except that no copy is made.
2428
2429       fwd to device
2430
2431   SET STATEMENT
2432       The  set  statement  is used to dynamically add or update elements in a
2433       set from the packet path.  The set setname must already  exist  in  the
2434       given  table.   Furthermore,  any  set that will be dynamically updated
2435       from the nftables ruleset must specify both a maximum set size (to pre‐
2436       vent memory exhaustion) and a timeout (so that number of entries in set
2437       will not grow indefinitely).  The set statement can  be  used  to  e.g.
2438       create dynamic blacklists.
2439
2440       {add | update} @setname { expression [timeout timeout] [comment string]
2441       }
2442
2443       Example for simple blacklist
2444
2445           # declare a set, bound to table "filter", in family "ip".  Timeout and size are mandatory because we will add elements from packet path.
2446           nft add set ip filter blackhole "{ type ipv4_addr; flags timeout; size 65536; }"
2447
2448           # whitelist internal interface.
2449           nft add rule ip filter input meta iifname "internal" accept
2450
2451           # drop packets coming from blacklisted ip addresses.
2452           nft add rule ip filter input ip saddr @blackhole counter drop
2453
2454           # add source ip addresses to the blacklist if more than 10 tcp connection requests occurred per second and ip address.
2455           # entries will timeout after one minute, after which they might be re-added if limit condition persists.
2456           nft add rule ip filter input tcp flags syn tcp dport ssh meter flood size 128000 { ip saddr timeout 10s limit rate over 10/second} add @blackhole { ip saddr timeout 1m } drop
2457
2458           # inspect state of the rate limit meter:
2459           nft list meter ip filter flood
2460
2461           # inspect content of blackhole:
2462           nft list set ip filter blackhole
2463
2464           # manually add two addresses to the set:
2465           nft add element filter blackhole { 10.2.3.4, 10.23.1.42 }
2466

ADDITIONAL COMMANDS

2468       These are some additional commands included in nft.
2469
2470   MONITOR
2471       The monitor command allows you to listen to Netlink events produced  by
2472       the  nf_tables  subsystem, related to creation and deletion of objects.
2473       When they occur, nft will print to stdout the monitored events  in  ei‐
2474       ther XML, JSON or native nft format.
2475
2476       To  filter events related to a concrete object, use one of the keywords
2477       'tables', 'chains', 'sets', 'rules', 'elements', 'ruleset'.
2478
2479       To filter events related to a concrete action,  use  keyword  'new'  or
2480       'destroy'.
2481
2482       Hit ^C to finish the monitor operation.
2483
2484       Listen to all events, report in native nft format
2485
2486       % nft monitor
2487
2488       Listen to added tables, report in XML format
2489
2490       % nft monitor new tables xml
2491
2492       Listen to deleted rules, report in JSON format
2493
2494       % nft monitor destroy rules json
2495
2496       Listen to both new and destroyed chains, in native nft format
2497
2498       % nft monitor chains
2499
2500       Listen  to ruleset events such as table, chain, rule, set, counters and
2501       quotas, in native nft format
2502
2503       % nft monitor ruleset
2504

ERROR REPORTING

2506       When an error is detected, nft shows the line(s) containing the  error,
2507       the  position  of  the erroneous parts in the input stream and marks up
2508       the erroneous parts using carets (^). If the  error  results  from  the
2509       combination  of  two  expressions  or statements, the part imposing the
2510       constraints which are violated is marked using tildes (~).
2511
2512       For errors returned by the kernel, nft can't detect which parts of  the
2513       input caused the error and the entire command is marked.
2514
2515       Error caused by single incorrect expression
2516
2517       <cmdline>:1:19-22: Error: Interface does not exist
2518       filter output oif eth0
2519                         ^^^^
2520
2521       Error caused by invalid combination of two expressions
2522
2523       <cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
2524       filter output tcp dport == tcp dport
2525                               ~~ ^^^^^^^^^
2526
2527       Error returned by the kernel
2528
2529       <cmdline>:0:0-23: Error: Could not process rule: Operation not permitted
2530       filter output oif wlan0
2531       ^^^^^^^^^^^^^^^^^^^^^^^
2532

EXIT STATUS

2534       On  success,  nft exits with a status of 0. Unspecified errors cause it
2535       to exit with a status of 1, memory allocation errors with a  status  of
2536       2, unable to open Netlink socket with 3.
2537

SEE ALSO

2539       iptables(8), ip6tables(8), arptables(8), ebtables(8), ip(8), tc(8)
2540
2541       There is an official wiki at: https://wiki.nftables.org
2542

AUTHORS

2544       nftables  was  written  by Patrick McHardy and Pablo Neira Ayuso, among
2545       many other contributors from the Netfilter community.
2546
2548       Copyright  2008-2014 Patrick McHardy <kaber@trash.net>
2549       Copyright  2013-2016 Pablo Neira Ayuso <pablo@netfilter.org>
2550
2551       nftables is free software; you can redistribute it and/or modify it un‐
2552       der  the terms of the GNU General Public License version 2 as published
2553       by the Free Software Foundation.
2554
2555       This documentation is licensed under the terms of the Creative  Commons
2556       Attribution-ShareAlike 4.0 license, CC BY-SA 4.0 ⟨http://
2557       creativecommons.org/licenses/by-sa/4.0/⟩ .
2558
2559
2560
2561                                  11 May 2019                           nft(8)
Impressum