1nft(8) nft(8)
2
3
4
6 nft - Administration tool of the nftables framework for packet filter‐
7 ing and classification
8
10 nft [ -nNscae ] [ -I directory ] [ -f filename | -i | cmd ...]
11 nft -h
12 nft -v
13
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
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 -I, --includepath directory
53 Add the directory directory to the list of directories to be
54 searched for included files. This option may be specified multi‐
55 ple times.
56
57 -f, --file filename
58 Read input from filename. If filename is -, read from stdin.
59
60 nft scripts must start #!/usr/sbin/nft -f
61
62 -i, --interactive
63 Read input from an interactive readline CLI. You can use quit to
64 exit, or use the EOF marker, normally this is CTRL-D.
65
67 LEXICAL CONVENTIONS
68 Input is parsed line-wise. When the last character of a line, just be‐
69 fore the newline character, is a non-quoted backslash (\), the next
70 line is treated as a continuation. Multiple commands on the same line
71 can be separated using a semicolon (;).
72
73 A hash sign (#) begins a comment. All following characters on the same
74 line are ignored.
75
76 Identifiers begin with an alphabetic character (a-z,A-Z), followed zero
77 or more alphanumeric characters (a-z,A-Z,0-9) and the characters slash
78 (/), backslash (\), underscore (_) and dot (.). Identifiers using dif‐
79 ferent characters or clashing with a keyword need to be enclosed in
80 double quotes (").
81
82 INCLUDE FILES
83 include filename
84
85 Other files can be included by using the include statement. The direc‐
86 tories to be searched for include files can be specified using the
87 -I/--includepath option. You can override this behaviour either by
88 prepending ./ to your path to force inclusion of files located in the
89 current working directory (i.e. relative path) or / for file location
90 expressed as an absolute path.
91
92 If -I/--includepath is not specified, then nft relies on the default
93 directory that is specified at compile time. You can retrieve this de‐
94 fault directory via -h/--help option.
95
96 Include statements support the usual shell wildcard symbols (*,?,[]).
97 Having no matches for an include statement is not an error, if wildcard
98 symbols are used in the include statement. This allows having poten‐
99 tially empty include directories for statements like include
100 "/etc/firewall/rules/*". The wildcard matches are loaded in alphabeti‐
101 cal order. Files beginning with dot (.) are not matched by include
102 statements.
103
104 SYMBOLIC VARIABLES
105 define variable expr
106 $variable
107
108 Symbolic variables can be defined using the define statement. Variable
109 references are expressions and can be used initialize other variables.
110 The scope of a definition is the current block and all blocks contained
111 within.
112
113 Using symbolic variables
114
115 define int_if1 = eth0
116 define int_if2 = eth1
117 define int_ifs = { $int_if1, $int_if2 }
118
119 filter input iif $int_ifs accept
120
121
123 Address families determine the type of packets which are processed. For
124 each address family the kernel contains so called hooks at specific
125 stages of the packet processing paths, which invoke nftables if rules
126 for these hooks exist.
127
128 ip IPv4 address family.
129
130 ip6 IPv6 address family.
131
132 inet Internet (IPv4/IPv6) address family.
133
134 arp ARP address family, handling IPv4 ARP packets.
135
136 bridge Bridge address family, handling packets which traverse a bridge
137 device.
138
139 netdev Netdev address family, handling packets from ingress.
140
141 All nftables objects exist in address family specific namespaces,
142 therefore all identifiers include an address family. If an identifier
143 is specified without an address family, the ip family is used by de‐
144 fault.
145
146 IPV4/IPV6/INET ADDRESS FAMILIES
147 The IPv4/IPv6/Inet address families handle IPv4, IPv6 or both types of
148 packets. They contain five hooks at different packet processing stages
149 in the network stack.
150
151 IPv4/IPv6/Inet address family hooks
152
153 ┌────────────┬────────────────────────────┐
154 │Hook │ Description │
155 ├────────────┼────────────────────────────┤
156 │prerouting │ All packets entering the │
157 │ │ system are processed by │
158 │ │ the prerouting hook. It is │
159 │ │ invoked before the routing │
160 │ │ process and is used for │
161 │ │ early filtering or chang‐ │
162 │ │ ing packet attributes that │
163 │ │ affect routing. │
164 ├────────────┼────────────────────────────┤
165 │input │ Packets delivered to the │
166 │ │ local system are processed │
167 │ │ by the input hook. │
168 ├────────────┼────────────────────────────┤
169 │forward │ Packets forwarded to a │
170 │ │ different host are pro‐ │
171 │ │ cessed by the forward │
172 │ │ hook. │
173 ├────────────┼────────────────────────────┤
174 │output │ Packets sent by local pro‐ │
175 │ │ cesses are processed by │
176 │ │ the output hook. │
177 ├────────────┼────────────────────────────┤
178 │postrouting │ All packets leaving the │
179 │ │ system are processed by │
180 │ │ the postrouting hook. │
181 └────────────┴────────────────────────────┘
182 ARP ADDRESS FAMILY
183 The ARP address family handles ARP packets received and sent by the
184 system. It is commonly used to mangle ARP packets for clustering.
185
186 ARP address family hooks
187
188 ┌───────┬────────────────────────────┐
189 │Hook │ Description │
190 ├───────┼────────────────────────────┤
191 │input │ Packets delivered to the │
192 │ │ local system are processed │
193 │ │ by the input hook. │
194 ├───────┼────────────────────────────┤
195 │output │ Packets send by the local │
196 │ │ system are processed by │
197 │ │ the output hook. │
198 └───────┴────────────────────────────┘
199 BRIDGE ADDRESS FAMILY
200 The bridge address family handles Ethernet packets traversing bridge
201 devices.
202
203 The list of supported hooks is identical to IPv4/IPv6/Inet address fam‐
204 ilies above.
205
206 NETDEV ADDRESS FAMILY
207 The Netdev address family handles packets from ingress.
208
209 Netdev address family hooks
210
211 ┌────────┬────────────────────────────┐
212 │Hook │ Description │
213 ├────────┼────────────────────────────┤
214 │ingress │ All packets entering the │
215 │ │ system are processed by │
216 │ │ this hook. It is invoked │
217 │ │ before layer 3 protocol │
218 │ │ handlers and it can be │
219 │ │ used for early filtering │
220 │ │ and policing. │
221 └────────┴────────────────────────────┘
223 {list | flush} ruleset [family]
224 export [ruleset] format
225
226 The ruleset keyword is used to identify the whole set of tables,
227 chains, etc. currently in place in kernel. The following ruleset com‐
228 mands exist:
229
230 list Print the ruleset in human-readable format.
231
232 flush Clear the whole ruleset. Note that unlike iptables, this will
233 remove all tables and whatever they contain, effectively leading
234 to an empty ruleset - no packet filtering will happen anymore,
235 so the kernel accepts any valid packet it receives.
236
237 export Print the ruleset in machine readable format. The mandatory for‐
238 mat parameter may be either xml or json.
239
240 It is possible to limit list and flush to a specific address family on‐
241 ly. For a list of valid family names, see ADDRESS FAMILIES above.
242
243 Note that contrary to what one might assume, the output generated by
244 export is not parseable by nft -f. Instead, the output of list command
245 serves well for that purpose.
246
248 {add | create} table [family] table [ { flags flags } ]
249 {delete | list | flush} table [family] table
250 delete table [family] handle handle
251
252 Tables are containers for chains, sets and stateful objects. They are
253 identified by their address family and their name. The address family
254 must be one of ip, ip6, inet, arp, bridge, netdev. The inet address
255 family is a dummy family which is used to create hybrid IPv4/IPv6 ta‐
256 bles. The meta expression nfproto keyword can be used to test which
257 family (IPv4 or IPv6) context the packet is being processed in. When
258 no address family is specified, ip is used by default. The only dif‐
259 ference between add and create is that the former will not return an
260 error if the specified table already exists while create will return an
261 error.
262
263 Table flags
264
265 ┌────────┬────────────────────────────┐
266 │Flag │ Description │
267 ├────────┼────────────────────────────┤
268 │dormant │ table is not evaluated any │
269 │ │ more (base chains are un‐ │
270 │ │ registered) │
271 └────────┴────────────────────────────┘
272 Add, change, delete a table
273
274 # start nft in interactive mode
275 nft --interactive
276
277 # create a new table.
278 create table inet mytable
279
280 # add a new base chain: get input packets
281 add chain inet mytable myin { type filter hook input priority 0; }
282
283 # add a single counter to the chain
284 add rule inet mytable myin counter
285
286 # disable the table temporarily -- rules are not evaluated anymore
287 add table inet mytable { flags dormant; }
288
289 # make table active again:
290 add table inet mytable
291
292
293 add Add a new table for the given family with the given name.
294
295 delete Delete the specified table.
296
297 list List all chains and rules of the specified table.
298
299 flush Flush all chains and rules of the specified table.
300
302 {add | create} chain [family] table chain [ { type type hook hook
303 [device device] priority priority ; [policy policy ;] } ]
304 {delete | list | flush} chain [family] table chain
305 delete chain [family] table handle handle
306 rename chain [family] table chain newname
307
308 Chains are containers for rules. They exist in two kinds, base chains
309 and regular chains. A base chain is an entry point for packets from the
310 networking stack, a regular chain may be used as jump target and is
311 used for better rule organization.
312
313 add Add a new chain in the specified table. When a hook and priority
314 value are specified, the chain is created as a base chain and
315 hooked up to the networking stack.
316
317 create Similar to the add command, but returns an error if the chain
318 already exists.
319
320 delete Delete the specified chain. The chain must not contain any rules
321 or be used as jump target.
322
323 rename Rename the specified chain.
324
325 list List all rules of the specified chain.
326
327 flush Flush all rules of the specified chain.
328
329 For base chains, type, hook and priority parameters are mandatory.
330
331 Supported chain types
332
333 ┌───────┬──────────┬──────────────────┬──────────────────┐
334 │Type │ Families │ Hooks │ Description │
335 ├───────┼──────────┼──────────────────┼──────────────────┤
336 │filter │ all │ all │ Standard chain │
337 │ │ │ │ type to use in │
338 │ │ │ │ doubt. │
339 ├───────┼──────────┼──────────────────┼──────────────────┤
340 │nat │ ip, ip6 │ prerouting, in‐ │ Chains of this │
341 │ │ │ put, output, │ type perform │
342 │ │ │ postrouting │ Network Address │
343 │ │ │ │ Translation │
344 │ │ │ │ based on con‐ │
345 │ │ │ │ ntrack entries. │
346 │ │ │ │ Only the first │
347 │ │ │ │ packet of a con‐ │
348 │ │ │ │ nection actually │
349 │ │ │ │ traverses this │
350 │ │ │ │ chain - its │
351 │ │ │ │ rules usually │
352 │ │ │ │ define details │
353 │ │ │ │ of the created │
354 │ │ │ │ conntrack entry │
355 │ │ │ │ (NAT statements │
356 │ │ │ │ for instance). │
357 ├───────┼──────────┼──────────────────┼──────────────────┤
358 │route │ ip, ip6 │ output │ If a packet has │
359 │ │ │ │ traversed a │
360 │ │ │ │ chain of this │
361 │ │ │ │ type and is │
362 │ │ │ │ about to be ac‐ │
363 │ │ │ │ cepted, a new │
364 │ │ │ │ route lookup is │
365 │ │ │ │ performed if │
366 │ │ │ │ relevant parts │
367 │ │ │ │ of the IP header │
368 │ │ │ │ have changed. │
369 │ │ │ │ This allows to │
370 │ │ │ │ e.g. implement │
371 │ │ │ │ policy routing │
372 │ │ │ │ selectors in │
373 │ │ │ │ nftables. │
374 └───────┴──────────┴──────────────────┴──────────────────┘
375 Apart from the special cases illustrated above (e.g. nat type not sup‐
376 porting forward hook or route type only supporting output hook), there
377 are two further quirks worth noticing:
378
379 · netdev family supports merely a single combination, namely filter
380 type and ingress hook. Base chains in this family also require the
381 device parameter to be present since they exist per incoming inter‐
382 face only.
383
384 · arp family supports only input and output hooks, both in chains of
385 type filter.
386
387 The priority parameter accepts a signed integer value which specifies
388 the order in which chains with same hook value are traversed. The or‐
389 dering is ascending, i.e. lower priority values have precedence over
390 higher ones.
391
392 Base chains also allow to set the chain's policy, i.e. what happens to
393 packets not explicitly accepted or refused in contained rules. Support‐
394 ed policy values are accept (which is the default) or drop.
395
397 [add | insert] rule [family] table chain [ {handle | position} handle |
398 index index ] statement...
399 replace rule [family] table chain handle handle statement...
400 delete rule [family] table chain handle handle
401
402 Rules are added to chain in the given table. If the family is not
403 specified, the ip family is used. Rules are constructed from two kinds
404 of components according to a set of grammatical rules: expressions and
405 statements.
406
407 The add and insert commands support an optional location specifier,
408 which is either a handle of an existing rule or an index (starting at
409 zero). Internally, rule locations are always identified by handle and
410 the translation from index happens in userspace. This has two potential
411 implications in case a concurrent ruleset change happens after the
412 translation was done: The effective rule index might change if a rule
413 was inserted or deleted before the referred one. If the referred rule
414 was deleted, the command is rejected by the kernel just as if an in‐
415 valid handle was given.
416
417 add Add a new rule described by the list of statements. The rule is
418 appended to the given chain unless a handle is specified, in
419 which case the rule is appended to the rule given by the handle.
420 The alternative name position is deprecated and should not be
421 used anymore.
422
423 insert Similar to the add command, but the rule is prepended to the be‐
424 ginning of the chain or before the rule with the given handle.
425
426 replace
427 Similar to the add command, but the rule replaces the specified
428 rule.
429
430 delete Delete the specified rule.
431
432 add a rule to ip table input chain
433
434 nft add rule filter output ip daddr 192.168.0.0/24 accept # 'ip filter' is assumed
435 # same command, slightly more verbose
436 nft add rule ip filter output ip daddr 192.168.0.0/24 accept
437
438
439
440 delete rule from inet table
441
442 # nft -a list ruleset
443 table inet filter {
444 chain input {
445 type filter hook input priority 0; policy accept;
446 ct state established,related accept # handle 4
447 ip saddr 10.1.1.1 tcp dport ssh accept # handle 5
448 ...
449 # delete the rule with handle 5
450 # nft delete rule inet filter input handle 5
451
452
454 nftables offers two kinds of set concepts. Anonymous sets are sets
455 that have no specific name. The set members are enclosed in curly
456 braces, with commas to separate elements when creating the rule the set
457 is used in. Once that rule is removed, the set is removed as well.
458 They cannot be updated, i.e. once an anonymous set is declared it can‐
459 not be changed anymore except by removing/altering the rule that uses
460 the anonymous set.
461
462 Using anonymous sets to accept particular subnets and ports
463
464 nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept
465
466
467 Named sets are sets that need to be defined first before they can be
468 referenced in rules. Unlike anonymous sets, elements can be added to or
469 removed from a named set at any time. Sets are referenced from rules
470 using an @ prefixed to the sets name.
471
472 Using named sets to accept addresses and ports
473
474 nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept
475
476
477 The sets allowed_hosts and allowed_ports need to be created first. The
478 next section describes nft set syntax in more detail.
479
480 add set [family] table set { type type ; [flags flags ;] [timeout
481 timeout ;] [gc-interval gc-interval ;] [elements = { element[,...] } ;]
482 [size size ;] [policy policy ;] [auto-merge auto-merge ;] }
483 {delete | list | flush} set [family] table set
484 delete set [family] table handle handle
485 {add | delete} element [family] table set { element[,...] }
486
487 Sets are elements containers of an user-defined data type, they are
488 uniquely identified by an user-defined name and attached to tables.
489
490 add Add a new set in the specified table.
491
492 delete Delete the specified set.
493
494 list Display the elements in the specified set.
495
496 flush Remove all elements from the specified set.
497
498 add element
499 Comma-separated list of elements to add into the specified set.
500
501 delete element
502 Comma-separated list of elements to delete from the specified
503 set.
504
505 Set specifications
506
507 ┌────────────┬─────────────────────┬─────────────────────┐
508 │Keyword │ Description │ Type │
509 ├────────────┼─────────────────────┼─────────────────────┤
510 │type │ data type of set │ string: ipv4_addr, │
511 │ │ elements │ ipv6_addr, │
512 │ │ │ ether_addr, in‐ │
513 │ │ │ et_proto, inet_ser‐ │
514 │ │ │ vice, mark │
515 ├────────────┼─────────────────────┼─────────────────────┤
516 │flags │ set flags │ string: constant, │
517 │ │ │ interval, timeout │
518 ├────────────┼─────────────────────┼─────────────────────┤
519 │timeout │ time an element │ string, decimal │
520 │ │ stays in the set, │ followed by unit. │
521 │ │ mandatory if set is │ Units are: d, h, m, │
522 │ │ added to from the │ s │
523 │ │ packet path (rule‐ │ │
524 │ │ set). │ │
525 ├────────────┼─────────────────────┼─────────────────────┤
526 │gc-interval │ garbage collection │ string, decimal │
527 │ │ interval, only │ followed by unit. │
528 │ │ available when │ Units are: d, h, m, │
529 │ │ timeout or flag │ s │
530 │ │ timeout are active │ │
531 ├────────────┼─────────────────────┼─────────────────────┤
532 │elements │ elements contained │ set data type │
533 │ │ by the set │ │
534 ├────────────┼─────────────────────┼─────────────────────┤
535 │size │ maximum number of │ unsigned integer │
536 │ │ elements in the │ (64 bit) │
537 │ │ set, mandatory if │ │
538 │ │ set is added to │ │
539 │ │ from the packet │ │
540 │ │ path (ruleset). │ │
541 ├────────────┼─────────────────────┼─────────────────────┤
542 │policy │ set policy │ string: performance │
543 │ │ │ [default], memory │
544 ├────────────┼─────────────────────┼─────────────────────┤
545 │auto-merge │ automatic merge of │ │
546 │ │ adjacent/overlap‐ │ │
547 │ │ ping set elements │ │
548 │ │ (only for interval │ │
549 │ │ sets) │ │
550 └────────────┴─────────────────────┴─────────────────────┘
552 add map [family] table map { type type [flags flags ;] [elements = {
553 element[,...] } ;] [size size ;] [policy policy ;] }
554 {delete | list | flush} map [family] table map
555 {add | delete} element [family] table map { elements = { element[,...]
556 } ; }
557
558 Maps store data based on some specific key used as input, they are
559 uniquely identified by an user-defined name and attached to tables.
560
561 add Add a new map in the specified table.
562
563 delete Delete the specified map.
564
565 list Display the elements in the specified map.
566
567 flush Remove all elements from the specified map.
568
569 add element
570 Comma-separated list of elements to add into the specified map.
571
572 delete element
573 Comma-separated list of element keys to delete from the speci‐
574 fied map.
575
576 Map specifications
577
578 ┌─────────┬─────────────────────┬─────────────────────┐
579 │Keyword │ Description │ Type │
580 ├─────────┼─────────────────────┼─────────────────────┤
581 │type │ data type of map │ string ':' string: │
582 │ │ elements │ ipv4_addr, ipv6_ad‐ │
583 │ │ │ dr, ether_addr, in‐ │
584 │ │ │ et_proto, inet_ser‐ │
585 │ │ │ vice, mark, │
586 │ │ │ counter, quota. │
587 │ │ │ Counter and quota │
588 │ │ │ can't be used as │
589 │ │ │ keys │
590 ├─────────┼─────────────────────┼─────────────────────┤
591 │flags │ map flags │ string: constant, │
592 │ │ │ interval │
593 ├─────────┼─────────────────────┼─────────────────────┤
594 │elements │ elements contained │ map data type │
595 │ │ by the map │ │
596 ├─────────┼─────────────────────┼─────────────────────┤
597 │size │ maximum number of │ unsigned integer │
598 │ │ elements in the map │ (64 bit) │
599 ├─────────┼─────────────────────┼─────────────────────┤
600 │policy │ map policy │ string: performance │
601 │ │ │ [default], memory │
602 └─────────┴─────────────────────┴─────────────────────┘
604 {add | create} flowtable [family] table flowtable { hook hook priority
605 priority ; devices = { device[,...] } ; }
606 {delete | list} flowtable [family] table flowtable
607
608 Flowtables allow you to accelerate packet forwarding in software.
609 Flowtables entries are represented through a tuple that is composed of
610 the input interface, source and destination address, source and desti‐
611 nation port; and layer 3/4 protocols. Each entry also caches the desti‐
612 nation interface and the gateway address - to update the destination
613 link-layer address - to forward packets. The ttl and hoplimit fields
614 are also decremented. Hence, flowtables provides an alternative path
615 that allow packets to bypass the classic forwarding path. Flowtables
616 reside in the ingress hook, that is located before the prerouting hook.
617 You can select what flows you want to offload through the flow offload
618 expression from the forward chain. Flowtables are identified by their
619 address family and their name. The address family must be one of ip,
620 ip6, inet. The inet address family is a dummy family which is used to
621 create hybrid IPv4/IPv6 tables. When no address family is specified,
622 ip is used by default.
623
624 add Add a new flowtable for the given family with the given name.
625
626 delete Delete the specified flowtable.
627
628 list List all flowtables.
629
631 {add | delete | list | reset} type [family] table object
632 delete type [family] table handle handle
633
634 Stateful objects are attached to tables and are identified by an unique
635 name. They group stateful information from rules, to reference them in
636 rules the keywords "type name" are used e.g. "counter name".
637
638 add Add a new stateful object in the specified table.
639
640 delete Delete the specified object.
641
642 list Display stateful information the object holds.
643
644 reset List-and-reset stateful object.
645
646 CT
647 ct helper helper { type type protocol protocol ; [l3proto family ;] }
648
649 Ct helper is used to define connection tracking helpers that can then
650 be used in combination with the "ct helper set" statement. type and
651 protocol are mandatory, l3proto is derived from the table family by de‐
652 fault, i.e. in the inet table the kernel will try to load both the IPv4
653 and IPv6 helper backends, if they are supported by the kernel.
654
655 conntrack helper specifications
656
657 ┌─────────┬─────────────────────┬─────────────────────┐
658 │Keyword │ Description │ Type │
659 ├─────────┼─────────────────────┼─────────────────────┤
660 │type │ name of helper type │ quoted string (e.g. │
661 │ │ │ "ftp") │
662 ├─────────┼─────────────────────┼─────────────────────┤
663 │protocol │ layer 4 protocol of │ string (e.g. tcp) │
664 │ │ the helper │ │
665 ├─────────┼─────────────────────┼─────────────────────┤
666 │l3proto │ layer 3 protocol of │ address family │
667 │ │ the helper │ (e.g. ip) │
668 └─────────┴─────────────────────┴─────────────────────┘
669 defining and assigning ftp helper
670
671 Unlike iptables, helper assignment needs to be performed after the con‐
672 ntrack lookup has completed, for example with the default 0 hook prior‐
673 ity.
674
675 table inet myhelpers {
676 ct helper ftp-standard {
677 type "ftp" protocol tcp
678 }
679 chain prerouting {
680 type filter hook prerouting priority 0;
681 tcp dport 21 ct helper set "ftp-standard"
682 }
683 }
684
685 COUNTER
686 counter [packets bytes]
687
688 Counter specifications
689
690 ┌────────┬─────────────────────┬─────────────────────┐
691 │Keyword │ Description │ Type │
692 ├────────┼─────────────────────┼─────────────────────┤
693 │packets │ initial count of │ unsigned integer │
694 │ │ packets │ (64 bit) │
695 ├────────┼─────────────────────┼─────────────────────┤
696 │bytes │ initial count of │ unsigned integer │
697 │ │ bytes │ (64 bit) │
698 └────────┴─────────────────────┴─────────────────────┘
699 QUOTA
700 quota [over | until] [used]
701
702 Quota specifications
703
704 ┌────────┬─────────────────────┬─────────────────────┐
705 │Keyword │ Description │ Type │
706 ├────────┼─────────────────────┼─────────────────────┤
707 │quota │ quota limit, used │ Two arguments, un‐ │
708 │ │ as the quota name │ signed integer (64 │
709 │ │ │ bit) and string: │
710 │ │ │ bytes, kbytes, │
711 │ │ │ mbytes. "over" and │
712 │ │ │ "until" go before │
713 │ │ │ these arguments │
714 ├────────┼─────────────────────┼─────────────────────┤
715 │used │ initial value of │ Two arguments, un‐ │
716 │ │ used quota │ signed integer (64 │
717 │ │ │ bit) and string: │
718 │ │ │ bytes, kbytes, │
719 │ │ │ mbytes │
720 └────────┴─────────────────────┴─────────────────────┘
722 Expressions represent values, either constants like network addresses,
723 port numbers etc. or data gathered from the packet during ruleset eval‐
724 uation. Expressions can be combined using binary, logical, relational
725 and other types of expressions to form complex or relational (match)
726 expressions. They are also used as arguments to certain types of oper‐
727 ations, like NAT, packet marking etc.
728
729 Each expression has a data type, which determines the size, parsing and
730 representation of symbolic values and type compatibility with other ex‐
731 pressions.
732
733 DESCRIBE COMMAND
734 describe expression
735
736 The describe command shows information about the type of an expression
737 and its data type.
738
739 The describe command
740
741 $ nft describe tcp flags
742 payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits
743
744 predefined symbolic constants:
745 fin 0x01
746 syn 0x02
747 rst 0x04
748 psh 0x08
749 ack 0x10
750 urg 0x20
751 ecn 0x40
752 cwr 0x80
753
755 Data types determine the size, parsing and representation of symbolic
756 values and type compatibility of expressions. A number of global data
757 types exist, in addition some expression types define further data
758 types specific to the expression type. Most data types have a fixed
759 size, some however may have a dynamic size, f.i. the string type.
760
761 Types may be derived from lower order types, f.i. the IPv4 address type
762 is derived from the integer type, meaning an IPv4 address can also be
763 specified as an integer value.
764
765 In certain contexts (set and map definitions) it is necessary to ex‐
766 plicitly specify a data type. Each type has a name which is used for
767 this.
768
769 INTEGER TYPE
770 ┌────────┬─────────┬──────────┬───────────┐
771 │Name │ Keyword │ Size │ Base type │
772 ├────────┼─────────┼──────────┼───────────┤
773 │Integer │ integer │ variable │ - │
774 └────────┴─────────┴──────────┴───────────┘
775 The integer type is used for numeric values. It may be specified as
776 decimal, hexadecimal or octal number. The integer type doesn't have a
777 fixed size, its size is determined by the expression for which it is
778 used.
779
780 BITMASK TYPE
781 ┌────────┬─────────┬──────────┬───────────┐
782 │Name │ Keyword │ Size │ Base type │
783 ├────────┼─────────┼──────────┼───────────┤
784 │Bitmask │ bitmask │ variable │ integer │
785 └────────┴─────────┴──────────┴───────────┘
786 The bitmask type (bitmask) is used for bitmasks.
787
788 STRING TYPE
789 ┌───────┬─────────┬──────────┬───────────┐
790 │Name │ Keyword │ Size │ Base type │
791 ├───────┼─────────┼──────────┼───────────┤
792 │String │ string │ variable │ - │
793 └───────┴─────────┴──────────┴───────────┘
794 The string type is used to for character strings. A string begins with
795 an alphabetic character (a-zA-Z) followed by zero or more alphanumeric
796 characters or the characters /, -, _ and .. In addition anything en‐
797 closed in double quotes (") is recognized as a string.
798
799 String specification
800
801 # Interface name
802 filter input iifname eth0
803
804 # Weird interface name
805 filter input iifname "(eth0)"
806
807 LINK LAYER ADDRESS TYPE
808 ┌─────────────────┬─────────┬──────────┬───────────┐
809 │Name │ Keyword │ Size │ Base type │
810 ├─────────────────┼─────────┼──────────┼───────────┤
811 │Link layer ad‐ │ lladdr │ variable │ integer │
812 │dress │ │ │ │
813 └─────────────────┴─────────┴──────────┴───────────┘
814 The link layer address type is used for link layer addresses. Link lay‐
815 er addresses are specified as a variable amount of groups of two hexa‐
816 decimal digits separated using colons (:).
817
818 Link layer address specification
819
820 # Ethernet destination MAC address
821 filter input ether daddr 20:c9:d0:43:12:d9
822
823 IPV4 ADDRESS TYPE
824 ┌─────────────┬───────────┬────────┬───────────┐
825 │Name │ Keyword │ Size │ Base type │
826 ├─────────────┼───────────┼────────┼───────────┤
827 │IPv4 address │ ipv4_addr │ 32 bit │ integer │
828 └─────────────┴───────────┴────────┴───────────┘
829 The IPv4 address type is used for IPv4 addresses. Addresses are speci‐
830 fied in either dotted decimal, dotted hexadecimal, dotted octal, deci‐
831 mal, hexadecimal, octal notation or as a host name. A host name will be
832 resolved using the standard system resolver.
833
834 IPv4 address specification
835
836 # dotted decimal notation
837 filter output ip daddr 127.0.0.1
838
839 # host name
840 filter output ip daddr localhost
841
842 IPV6 ADDRESS TYPE
843 ┌─────────────┬───────────┬─────────┬───────────┐
844 │Name │ Keyword │ Size │ Base type │
845 ├─────────────┼───────────┼─────────┼───────────┤
846 │IPv6 address │ ipv6_addr │ 128 bit │ integer │
847 └─────────────┴───────────┴─────────┴───────────┘
848 The IPv6 address type is used for IPv6 addresses. Addresses are speci‐
849 fied as a host name or as hexadecimal halfwords separated by colons.
850 Addresses might be enclosed in square brackets ("[]") to differentiate
851 them from port numbers.
852
853 IPv6 address specificationIPv6 address specification with bracket nota‐
854 tion
855
856 # abbreviated loopback address
857 filter output ip6 daddr ::1
858
859 # without [] the port number (22) would be parsed as part of ipv6 address
860 ip6 nat prerouting tcp dport 2222 dnat to [1ce::d0]:22
861
862 BOOLEAN TYPE
863 ┌────────┬─────────┬───────┬───────────┐
864 │Name │ Keyword │ Size │ Base type │
865 ├────────┼─────────┼───────┼───────────┤
866 │Boolean │ boolean │ 1 bit │ integer │
867 └────────┴─────────┴───────┴───────────┘
868 The boolean type is a syntactical helper type in user space. It's use
869 is in the right-hand side of a (typically implicit) relational expres‐
870 sion to change the expression on the left-hand side into a boolean
871 check (usually for existence).
872
873 The following keywords will automatically resolve into a boolean type
874 with given value:
875
876 ┌────────┬───────┐
877 │Keyword │ Value │
878 ├────────┼───────┤
879 │exists │ 1 │
880 ├────────┼───────┤
881 │missing │ 0 │
882 └────────┴───────┘
883 Boolean specification
884
885 The following expressions support a boolean comparison:
886
887 ┌───────────┬────────────────────────────┐
888 │Expression │ Behaviour │
889 ├───────────┼────────────────────────────┤
890 │fib │ Check route existence. │
891 ├───────────┼────────────────────────────┤
892 │exthdr │ Check IPv6 extension head‐ │
893 │ │ er existence. │
894 ├───────────┼────────────────────────────┤
895 │tcp option │ Check TCP option header │
896 │ │ existence. │
897 └───────────┴────────────────────────────┘
898 # match if route exists
899 filter input fib daddr . iif oif exists
900
901 # match only non-fragmented packets in IPv6 traffic
902 filter input exthdr frag missing
903
904 # match if TCP timestamp option is present
905 filter input tcp option timestamp exists
906
907 ICMP TYPE TYPE
908 ┌──────────┬───────────┬───────┬───────────┐
909 │Name │ Keyword │ Size │ Base type │
910 ├──────────┼───────────┼───────┼───────────┤
911 │ICMP Type │ icmp_type │ 8 bit │ integer │
912 └──────────┴───────────┴───────┴───────────┘
913 The ICMP Type type is used to conveniently specify the ICMP header's
914 type field.
915
916 The following keywords may be used when specifying the ICMP type:
917
918 ┌────────────────────────┬───────┐
919 │Keyword │ Value │
920 ├────────────────────────┼───────┤
921 │echo-reply │ 0 │
922 ├────────────────────────┼───────┤
923 │destination-unreachable │ 3 │
924 ├────────────────────────┼───────┤
925 │source-quench │ 4 │
926 ├────────────────────────┼───────┤
927 │redirect │ 5 │
928 ├────────────────────────┼───────┤
929 │echo-request │ 8 │
930 ├────────────────────────┼───────┤
931 │router-advertisement │ 9 │
932 ├────────────────────────┼───────┤
933 │router-solicitation │ 10 │
934 ├────────────────────────┼───────┤
935 │time-exceeded │ 11 │
936 ├────────────────────────┼───────┤
937 │parameter-problem │ 12 │
938 ├────────────────────────┼───────┤
939 │timestamp-request │ 13 │
940 ├────────────────────────┼───────┤
941 │timestamp-reply │ 14 │
942 ├────────────────────────┼───────┤
943 │info-request │ 15 │
944 ├────────────────────────┼───────┤
945 │info-reply │ 16 │
946 ├────────────────────────┼───────┤
947 │address-mask-request │ 17 │
948 ├────────────────────────┼───────┤
949 │address-mask-reply │ 18 │
950 └────────────────────────┴───────┘
951 ICMP Type specification
952
953 # match ping packets
954 filter output icmp type { echo-request, echo-reply }
955
956 ICMP CODE TYPE
957 ┌──────────┬───────────┬───────┬───────────┐
958 │Name │ Keyword │ Size │ Base type │
959 ├──────────┼───────────┼───────┼───────────┤
960 │ICMP Code │ icmp_code │ 8 bit │ integer │
961 └──────────┴───────────┴───────┴───────────┘
962 The ICMP Code type is used to conveniently specify the ICMP header's
963 code field.
964
965 The following keywords may be used when specifying the ICMP code:
966
967 ┌─────────────────┬───────┐
968 │Keyword │ Value │
969 ├─────────────────┼───────┤
970 │net-unreachable │ 0 │
971 ├─────────────────┼───────┤
972 │host-unreachable │ 1 │
973 ├─────────────────┼───────┤
974 │prot-unreachable │ 2 │
975 ├─────────────────┼───────┤
976 │port-unreachable │ 3 │
977 ├─────────────────┼───────┤
978 │net-prohibited │ 9 │
979 ├─────────────────┼───────┤
980 │host-prohibited │ 10 │
981 ├─────────────────┼───────┤
982 │admin-prohibited │ 13 │
983 └─────────────────┴───────┘
984 ICMPV6 TYPE TYPE
985 ┌────────────┬─────────────┬───────┬───────────┐
986 │Name │ Keyword │ Size │ Base type │
987 ├────────────┼─────────────┼───────┼───────────┤
988 │ICMPv6 Type │ icmpv6_type │ 8 bit │ integer │
989 └────────────┴─────────────┴───────┴───────────┘
990 The ICMPv6 Type type is used to conveniently specify the ICMPv6 head‐
991 er's type field.
992
993 The following keywords may be used when specifying the ICMPv6 type:
994
995 ┌────────────────────────┬───────┐
996 │Keyword │ Value │
997 ├────────────────────────┼───────┤
998 │destination-unreachable │ 1 │
999 ├────────────────────────┼───────┤
1000 │packet-too-big │ 2 │
1001 ├────────────────────────┼───────┤
1002 │time-exceeded │ 3 │
1003 ├────────────────────────┼───────┤
1004 │parameter-problem │ 4 │
1005 ├────────────────────────┼───────┤
1006 │echo-request │ 128 │
1007 ├────────────────────────┼───────┤
1008 │echo-reply │ 129 │
1009 ├────────────────────────┼───────┤
1010 │mld-listener-query │ 130 │
1011 ├────────────────────────┼───────┤
1012 │mld-listener-report │ 131 │
1013 ├────────────────────────┼───────┤
1014 │mld-listener-done │ 132 │
1015 ├────────────────────────┼───────┤
1016 │mld-listener-reduction │ 132 │
1017 ├────────────────────────┼───────┤
1018 │nd-router-solicit │ 133 │
1019 ├────────────────────────┼───────┤
1020 │nd-router-advert │ 134 │
1021 ├────────────────────────┼───────┤
1022 │nd-neighbor-solicit │ 135 │
1023 ├────────────────────────┼───────┤
1024 │nd-neighbor-advert │ 136 │
1025 ├────────────────────────┼───────┤
1026 │nd-redirect │ 137 │
1027 ├────────────────────────┼───────┤
1028 │router-renumbering │ 138 │
1029 ├────────────────────────┼───────┤
1030 │ind-neighbor-solicit │ 141 │
1031 ├────────────────────────┼───────┤
1032 │ind-neighbor-advert │ 142 │
1033 ├────────────────────────┼───────┤
1034 │mld2-listener-report │ 143 │
1035 └────────────────────────┴───────┘
1036 ICMPv6 Type specification
1037
1038 # match ICMPv6 ping packets
1039 filter output icmpv6 type { echo-request, echo-reply }
1040
1041 ICMPV6 CODE TYPE
1042 ┌────────────┬─────────────┬───────┬───────────┐
1043 │Name │ Keyword │ Size │ Base type │
1044 ├────────────┼─────────────┼───────┼───────────┤
1045 │ICMPv6 Code │ icmpv6_code │ 8 bit │ integer │
1046 └────────────┴─────────────┴───────┴───────────┘
1047 The ICMPv6 Code type is used to conveniently specify the ICMPv6 head‐
1048 er's code field.
1049
1050 The following keywords may be used when specifying the ICMPv6 code:
1051
1052 ┌─────────────────┬───────┐
1053 │Keyword │ Value │
1054 ├─────────────────┼───────┤
1055 │no-route │ 0 │
1056 ├─────────────────┼───────┤
1057 │admin-prohibited │ 1 │
1058 ├─────────────────┼───────┤
1059 │addr-unreachable │ 3 │
1060 ├─────────────────┼───────┤
1061 │port-unreachable │ 4 │
1062 ├─────────────────┼───────┤
1063 │policy-fail │ 5 │
1064 ├─────────────────┼───────┤
1065 │reject-route │ 6 │
1066 └─────────────────┴───────┘
1067 ICMPVX CODE TYPE
1068 ┌────────────┬────────────┬───────┬───────────┐
1069 │Name │ Keyword │ Size │ Base type │
1070 ├────────────┼────────────┼───────┼───────────┤
1071 │ICMPvX Code │ icmpx_code │ 8 bit │ integer │
1072 └────────────┴────────────┴───────┴───────────┘
1073 The ICMPvX Code type abstraction is a set of values which overlap be‐
1074 tween ICMP and ICMPv6 Code types to be used from the inet family.
1075
1076 The following keywords may be used when specifying the ICMPvX code:
1077
1078 ┌─────────────────┬───────┐
1079 │Keyword │ Value │
1080 ├─────────────────┼───────┤
1081 │no-route │ 0 │
1082 ├─────────────────┼───────┤
1083 │port-unreachable │ 1 │
1084 ├─────────────────┼───────┤
1085 │host-unreachable │ 2 │
1086 ├─────────────────┼───────┤
1087 │admin-prohibited │ 3 │
1088 └─────────────────┴───────┘
1089 CONNTRACK TYPES
1090 This is an overview of types used in ct expression and statement:
1091
1092 ┌─────────────────┬───────────┬─────────┬───────────┐
1093 │Name │ Keyword │ Size │ Base type │
1094 ├─────────────────┼───────────┼─────────┼───────────┤
1095 │conntrack state │ ct_state │ 4 byte │ bitmask │
1096 ├─────────────────┼───────────┼─────────┼───────────┤
1097 │conntrack direc‐ │ ct_dir │ 8 bit │ integer │
1098 │tion │ │ │ │
1099 ├─────────────────┼───────────┼─────────┼───────────┤
1100 │conntrack status │ ct_status │ 4 byte │ bitmask │
1101 ├─────────────────┼───────────┼─────────┼───────────┤
1102 │conntrack event │ ct_event │ 4 byte │ bitmask │
1103 │bits │ │ │ │
1104 ├─────────────────┼───────────┼─────────┼───────────┤
1105 │conntrack label │ ct_label │ 128 bit │ bitmask │
1106 └─────────────────┴───────────┴─────────┴───────────┘
1107 For each of the types above, keywords are available for convenience:
1108
1109 conntrack state (ct_state)
1110
1111 ┌────────────┬───────┐
1112 │Keyword │ Value │
1113 ├────────────┼───────┤
1114 │invalid │ 1 │
1115 ├────────────┼───────┤
1116 │established │ 2 │
1117 ├────────────┼───────┤
1118 │related │ 4 │
1119 ├────────────┼───────┤
1120 │new │ 8 │
1121 ├────────────┼───────┤
1122 │untracked │ 64 │
1123 └────────────┴───────┘
1124 conntrack direction (ct_dir)
1125
1126 ┌─────────┬───────┐
1127 │Keyword │ Value │
1128 ├─────────┼───────┤
1129 │original │ 0 │
1130 ├─────────┼───────┤
1131 │reply │ 1 │
1132 └─────────┴───────┘
1133 conntrack status (ct_status)
1134
1135 ┌───────────┬───────┐
1136 │Keyword │ Value │
1137 ├───────────┼───────┤
1138 │expected │ 1 │
1139 ├───────────┼───────┤
1140 │seen-reply │ 2 │
1141 ├───────────┼───────┤
1142 │assured │ 4 │
1143 ├───────────┼───────┤
1144 │confirmed │ 8 │
1145 ├───────────┼───────┤
1146 │snat │ 16 │
1147 ├───────────┼───────┤
1148 │dnat │ 32 │
1149 ├───────────┼───────┤
1150 │dying │ 512 │
1151 └───────────┴───────┘
1152 conntrack event bits (ct_event)
1153
1154 ┌──────────┬───────┐
1155 │Keyword │ Value │
1156 ├──────────┼───────┤
1157 │new │ 1 │
1158 ├──────────┼───────┤
1159 │related │ 2 │
1160 ├──────────┼───────┤
1161 │destroy │ 4 │
1162 ├──────────┼───────┤
1163 │reply │ 8 │
1164 ├──────────┼───────┤
1165 │assured │ 16 │
1166 ├──────────┼───────┤
1167 │protoinfo │ 32 │
1168 ├──────────┼───────┤
1169 │helper │ 64 │
1170 ├──────────┼───────┤
1171 │mark │ 128 │
1172 ├──────────┼───────┤
1173 │seqadj │ 256 │
1174 ├──────────┼───────┤
1175 │secmark │ 512 │
1176 ├──────────┼───────┤
1177 │label │ 1024 │
1178 └──────────┴───────┘
1179 Possible keywords for conntrack label type (ct_label) are read at run‐
1180 time from /etc/connlabel.conf.
1181
1183 The lowest order expression is a primary expression, representing ei‐
1184 ther a constant or a single datum from a packet's payload, meta data or
1185 a stateful module.
1186
1187 META EXPRESSIONS
1188 meta {length | nfproto | l4proto | protocol | priority}
1189 [meta] {mark | iif | iifname | iiftype | oif | oifname | oiftype |
1190 skuid | skgid | nftrace | rtclassid | ibrname | obrname | pkttype | cpu
1191 | iifgroup | oifgroup | cgroup | random | secpath}
1192
1193 A meta expression refers to meta data associated with a packet.
1194
1195 There are two types of meta expressions: unqualified and qualified meta
1196 expressions. Qualified meta expressions require the meta keyword be‐
1197 fore the meta key, unqualified meta expressions can be specified by us‐
1198 ing the meta key directly or as qualified meta expressions. Meta
1199 l4proto is useful to match a particular transport protocol that is part
1200 of either an IPv4 or IPv6 packet. It will also skip any IPv6 extension
1201 headers present in an IPv6 packet.
1202
1203 Meta expression types
1204
1205 ┌──────────┬─────────────────────┬───────────────────┐
1206 │Keyword │ Description │ Type │
1207 ├──────────┼─────────────────────┼───────────────────┤
1208 │length │ Length of the pack‐ │ integer (32 bit) │
1209 │ │ et in bytes │ │
1210 ├──────────┼─────────────────────┼───────────────────┤
1211 │nfproto │ real hook protocol │ integer (32 bit) │
1212 │ │ family, useful only │ │
1213 │ │ in inet table │ │
1214 ├──────────┼─────────────────────┼───────────────────┤
1215 │l4proto │ layer 4 protocol, │ integer (8 bit) │
1216 │ │ skips ipv6 exten‐ │ │
1217 │ │ sion headers │ │
1218 ├──────────┼─────────────────────┼───────────────────┤
1219 │protocol │ EtherType protocol │ ether_type │
1220 │ │ value │ │
1221 ├──────────┼─────────────────────┼───────────────────┤
1222 │priority │ TC packet priority │ tc_handle │
1223 ├──────────┼─────────────────────┼───────────────────┤
1224 │mark │ Packet mark │ mark │
1225 ├──────────┼─────────────────────┼───────────────────┤
1226 │iif │ Input interface in‐ │ iface_index │
1227 │ │ dex │ │
1228 ├──────────┼─────────────────────┼───────────────────┤
1229 │iifname │ Input interface │ ifname │
1230 │ │ name │ │
1231 ├──────────┼─────────────────────┼───────────────────┤
1232 │iiftype │ Input interface │ iface_type │
1233 │ │ type │ │
1234 ├──────────┼─────────────────────┼───────────────────┤
1235 │oif │ Output interface │ iface_index │
1236 │ │ index │ │
1237 ├──────────┼─────────────────────┼───────────────────┤
1238 │oifname │ Output interface │ ifname │
1239 │ │ name │ │
1240 ├──────────┼─────────────────────┼───────────────────┤
1241 │oiftype │ Output interface │ iface_type │
1242 │ │ hardware type │ │
1243 ├──────────┼─────────────────────┼───────────────────┤
1244 │skuid │ UID associated with │ uid │
1245 │ │ originating socket │ │
1246 ├──────────┼─────────────────────┼───────────────────┤
1247 │skgid │ GID associated with │ gid │
1248 │ │ originating socket │ │
1249 ├──────────┼─────────────────────┼───────────────────┤
1250 │rtclassid │ Routing realm │ realm │
1251 ├──────────┼─────────────────────┼───────────────────┤
1252 │ibrname │ Input bridge inter‐ │ ifname │
1253 │ │ face name │ │
1254 ├──────────┼─────────────────────┼───────────────────┤
1255 │obrname │ Output bridge in‐ │ ifname │
1256 │ │ terface name │ │
1257 ├──────────┼─────────────────────┼───────────────────┤
1258 │pkttype │ packet type │ pkt_type │
1259 ├──────────┼─────────────────────┼───────────────────┤
1260 │cpu │ cpu number process‐ │ integer (32 bits) │
1261 │ │ ing the packet │ │
1262 ├──────────┼─────────────────────┼───────────────────┤
1263 │iifgroup │ incoming device │ devgroup │
1264 │ │ group │ │
1265 ├──────────┼─────────────────────┼───────────────────┤
1266 │oifgroup │ outgoing device │ devgroup │
1267 │ │ group │ │
1268 ├──────────┼─────────────────────┼───────────────────┤
1269 │cgroup │ control group id │ integer (32 bits) │
1270 ├──────────┼─────────────────────┼───────────────────┤
1271 │random │ pseudo-random num‐ │ integer (32 bits) │
1272 │ │ ber │ │
1273 ├──────────┼─────────────────────┼───────────────────┤
1274 │secpath │ boolean │ boolean (1 bit) │
1275 └──────────┴─────────────────────┴───────────────────┘
1276 Meta expression specific types
1277
1278 ┌──────────────┬────────────────────────────┐
1279 │Type │ Description │
1280 ├──────────────┼────────────────────────────┤
1281 │iface_index │ Interface index (32 bit │
1282 │ │ number). Can be specified │
1283 │ │ numerically or as name of │
1284 │ │ an existing interface. │
1285 ├──────────────┼────────────────────────────┤
1286 │ifname │ Interface name (16 byte │
1287 │ │ string). Does not have to │
1288 │ │ exist. │
1289 ├──────────────┼────────────────────────────┤
1290 │iface_type │ Interface type (16 bit │
1291 │ │ number). │
1292 ├──────────────┼────────────────────────────┤
1293 │uid │ User ID (32 bit number). │
1294 │ │ Can be specified numeri‐ │
1295 │ │ cally or as user name. │
1296 ├──────────────┼────────────────────────────┤
1297 │gid │ Group ID (32 bit number). │
1298 │ │ Can be specified numeri‐ │
1299 │ │ cally or as group name. │
1300 ├──────────────┼────────────────────────────┤
1301 │realm │ Routing Realm (32 bit num‐ │
1302 │ │ ber). Can be specified nu‐ │
1303 │ │ merically or as symbolic │
1304 │ │ name defined in │
1305 │ │ /etc/iproute2/rt_realms. │
1306 ├──────────────┼────────────────────────────┤
1307 │devgroup_type │ Device group (32 bit num‐ │
1308 │ │ ber). Can be specified nu‐ │
1309 │ │ merically or as symbolic │
1310 │ │ name defined in │
1311 │ │ /etc/iproute2/group. │
1312 ├──────────────┼────────────────────────────┤
1313 │pkt_type │ Packet type: Unicast (ad‐ │
1314 │ │ dressed to local host), │
1315 │ │ Broadcast (to all), Multi‐ │
1316 │ │ cast (to group). │
1317 └──────────────┴────────────────────────────┘
1318 Using meta expressions
1319
1320 # qualified meta expression
1321 filter output meta oif eth0
1322
1323 # unqualified meta expression
1324 filter output oif eth0
1325
1326 # packed was subject to ipsec processing
1327 raw prerouting meta secpath exists accept
1328
1329 FIB EXPRESSIONS
1330 fib {saddr | daddr | {mark | iif | oif}} {oif | oifname | type}
1331
1332 A fib expression queries the fib (forwarding information base) to ob‐
1333 tain information such as the output interface index a particular ad‐
1334 dress would use. The input is a tuple of elements that is used as input
1335 to the fib lookup functions.
1336
1337 fib expression specific types
1338
1339 ┌────────┬─────────────────────┬──────────────────┐
1340 │Keyword │ Description │ Type │
1341 ├────────┼─────────────────────┼──────────────────┤
1342 │oif │ Output interface │ integer (32 bit) │
1343 │ │ index │ │
1344 ├────────┼─────────────────────┼──────────────────┤
1345 │oifname │ Output interface │ string │
1346 │ │ name │ │
1347 ├────────┼─────────────────────┼──────────────────┤
1348 │type │ Address type │ fib_addrtype │
1349 └────────┴─────────────────────┴──────────────────┘
1350 Using fib expressions
1351
1352 # drop packets without a reverse path
1353 filter prerouting fib saddr . iif oif missing drop
1354
1355 # drop packets to address not configured on ininterface
1356 filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
1357
1358 # perform lookup in a specific 'blackhole' table (0xdead, needs ip appropriate ip rule)
1359 filter prerouting meta mark set 0xdead fib daddr . mark type vmap { blackhole : drop, prohibit : jump prohibited, unreachable : drop }
1360
1361 ROUTING EXPRESSIONS
1362 rt {classid | nexthop}
1363
1364 A routing expression refers to routing data associated with a packet.
1365
1366 Routing expression types
1367
1368 ┌────────┬─────────────────────┬─────────────────────┐
1369 │Keyword │ Description │ Type │
1370 ├────────┼─────────────────────┼─────────────────────┤
1371 │classid │ Routing realm │ realm │
1372 ├────────┼─────────────────────┼─────────────────────┤
1373 │nexthop │ Routing nexthop │ ipv4_addr/ipv6_addr │
1374 ├────────┼─────────────────────┼─────────────────────┤
1375 │mtu │ TCP maximum segment │ integer (16 bit) │
1376 │ │ size of route │ │
1377 └────────┴─────────────────────┴─────────────────────┘
1378 Routing expression specific types
1379
1380 ┌──────┬────────────────────────────┐
1381 │Type │ Description │
1382 ├──────┼────────────────────────────┤
1383 │realm │ Routing Realm (32 bit num‐ │
1384 │ │ ber). Can be specified nu‐ │
1385 │ │ merically or as symbolic │
1386 │ │ name defined in │
1387 │ │ /etc/iproute2/rt_realms. │
1388 └──────┴────────────────────────────┘
1389 Using routing expressions
1390
1391 # IP family independent rt expression
1392 filter output rt classid 10
1393
1394 # IP family dependent rt expressions
1395 ip filter output rt nexthop 192.168.0.1
1396 ip6 filter output rt nexthop fd00::1
1397 inet filter output rt ip nexthop 192.168.0.1
1398 inet filter output rt ip6 nexthop fd00::1
1399
1401 Payload expressions refer to data from the packet's payload.
1402
1403 ETHERNET HEADER EXPRESSION
1404 ether [Ethernet header field]
1405
1406 Ethernet header expression types
1407
1408 ┌────────┬─────────────────────┬────────────┐
1409 │Keyword │ Description │ Type │
1410 ├────────┼─────────────────────┼────────────┤
1411 │daddr │ Destination MAC ad‐ │ ether_addr │
1412 │ │ dress │ │
1413 ├────────┼─────────────────────┼────────────┤
1414 │saddr │ Source MAC address │ ether_addr │
1415 ├────────┼─────────────────────┼────────────┤
1416 │type │ EtherType │ ether_type │
1417 └────────┴─────────────────────┴────────────┘
1418 VLAN HEADER EXPRESSION
1419 vlan [VLAN header field]
1420
1421 VLAN header expression
1422
1423 ┌────────┬─────────────────────┬──────────────────┐
1424 │Keyword │ Description │ Type │
1425 ├────────┼─────────────────────┼──────────────────┤
1426 │id │ VLAN ID (VID) │ integer (12 bit) │
1427 ├────────┼─────────────────────┼──────────────────┤
1428 │cfi │ Canonical Format │ integer (1 bit) │
1429 │ │ Indicator │ │
1430 ├────────┼─────────────────────┼──────────────────┤
1431 │pcp │ Priority code point │ integer (3 bit) │
1432 ├────────┼─────────────────────┼──────────────────┤
1433 │type │ EtherType │ ether_type │
1434 └────────┴─────────────────────┴──────────────────┘
1435 ARP HEADER EXPRESSION
1436 arp [ARP header field]
1437
1438 ARP header expression
1439
1440 ┌──────────┬─────────────────────┬──────────────────┐
1441 │Keyword │ Description │ Type │
1442 ├──────────┼─────────────────────┼──────────────────┤
1443 │htype │ ARP hardware type │ integer (16 bit) │
1444 ├──────────┼─────────────────────┼──────────────────┤
1445 │ptype │ EtherType │ ether_type │
1446 ├──────────┼─────────────────────┼──────────────────┤
1447 │hlen │ Hardware address │ integer (8 bit) │
1448 │ │ len │ │
1449 ├──────────┼─────────────────────┼──────────────────┤
1450 │plen │ Protocol address │ integer (8 bit) │
1451 │ │ len │ │
1452 ├──────────┼─────────────────────┼──────────────────┤
1453 │operation │ Operation │ arp_op │
1454 └──────────┴─────────────────────┴──────────────────┘
1455 IPV4 HEADER EXPRESSION
1456 ip [IPv4 header field]
1457
1458 IPv4 header expression
1459
1460 ┌──────────┬─────────────────────┬─────────────────────┐
1461 │Keyword │ Description │ Type │
1462 ├──────────┼─────────────────────┼─────────────────────┤
1463 │version │ IP header version │ integer (4 bit) │
1464 │ │ (4) │ │
1465 ├──────────┼─────────────────────┼─────────────────────┤
1466 │hdrlength │ IP header length │ integer (4 bit) │
1467 │ │ including options │ FIXME scaling │
1468 ├──────────┼─────────────────────┼─────────────────────┤
1469 │dscp │ Differentiated Ser‐ │ dscp │
1470 │ │ vices Code Point │ │
1471 ├──────────┼─────────────────────┼─────────────────────┤
1472 │ecn │ Explicit Congestion │ ecn │
1473 │ │ Notification │ │
1474 ├──────────┼─────────────────────┼─────────────────────┤
1475 │length │ Total packet length │ integer (16 bit) │
1476 ├──────────┼─────────────────────┼─────────────────────┤
1477 │id │ IP ID │ integer (16 bit) │
1478 ├──────────┼─────────────────────┼─────────────────────┤
1479 │frag-off │ Fragment offset │ integer (16 bit) │
1480 ├──────────┼─────────────────────┼─────────────────────┤
1481 │ttl │ Time to live │ integer (8 bit) │
1482 ├──────────┼─────────────────────┼─────────────────────┤
1483 │protocol │ Upper layer proto‐ │ inet_proto │
1484 │ │ col │ │
1485 ├──────────┼─────────────────────┼─────────────────────┤
1486 │checksum │ IP header checksum │ integer (16 bit) │
1487 ├──────────┼─────────────────────┼─────────────────────┤
1488 │saddr │ Source address │ ipv4_addr │
1489 ├──────────┼─────────────────────┼─────────────────────┤
1490 │daddr │ Destination address │ ipv4_addr │
1491 └──────────┴─────────────────────┴─────────────────────┘
1492 ICMP HEADER EXPRESSION
1493 icmp [ICMP header field]
1494
1495 ICMP header expression
1496
1497 ┌─────────┬─────────────────────┬──────────────────┐
1498 │Keyword │ Description │ Type │
1499 ├─────────┼─────────────────────┼──────────────────┤
1500 │type │ ICMP type field │ icmp_type │
1501 ├─────────┼─────────────────────┼──────────────────┤
1502 │code │ ICMP code field │ integer (8 bit) │
1503 ├─────────┼─────────────────────┼──────────────────┤
1504 │checksum │ ICMP checksum field │ integer (16 bit) │
1505 ├─────────┼─────────────────────┼──────────────────┤
1506 │id │ ID of echo re‐ │ integer (16 bit) │
1507 │ │ quest/response │ │
1508 ├─────────┼─────────────────────┼──────────────────┤
1509 │sequence │ sequence number of │ integer (16 bit) │
1510 │ │ echo request/re‐ │ │
1511 │ │ sponse │ │
1512 ├─────────┼─────────────────────┼──────────────────┤
1513 │gateway │ gateway of redi‐ │ integer (32 bit) │
1514 │ │ rects │ │
1515 ├─────────┼─────────────────────┼──────────────────┤
1516 │mtu │ MTU of path MTU │ integer (16 bit) │
1517 │ │ discovery │ │
1518 └─────────┴─────────────────────┴──────────────────┘
1519 IPV6 HEADER EXPRESSION
1520 ip6 [IPv6 header field]
1521
1522 This expression refers to the ipv6 header fields. Caution when using
1523 ip6 nexthdr, the value only refers to the next header, i.e. ip6 nexthdr
1524 tcp will only match if the ipv6 packet does not contain any extension
1525 headers. Packets that are fragmented or e.g. contain a routing exten‐
1526 sion headers will not be matched. Please use meta l4proto if you wish
1527 to match the real transport header and ignore any additional extension
1528 headers instead.
1529
1530 IPv6 header expression
1531
1532 ┌──────────┬─────────────────────┬──────────────────┐
1533 │Keyword │ Description │ Type │
1534 ├──────────┼─────────────────────┼──────────────────┤
1535 │version │ IP header version │ integer (4 bit) │
1536 │ │ (6) │ │
1537 ├──────────┼─────────────────────┼──────────────────┤
1538 │dscp │ Differentiated Ser‐ │ dscp │
1539 │ │ vices Code Point │ │
1540 ├──────────┼─────────────────────┼──────────────────┤
1541 │ecn │ Explicit Congestion │ ecn │
1542 │ │ Notification │ │
1543 ├──────────┼─────────────────────┼──────────────────┤
1544 │flowlabel │ Flow label │ integer (20 bit) │
1545 ├──────────┼─────────────────────┼──────────────────┤
1546 │length │ Payload length │ integer (16 bit) │
1547 ├──────────┼─────────────────────┼──────────────────┤
1548 │nexthdr │ Nexthdr protocol │ inet_proto │
1549 ├──────────┼─────────────────────┼──────────────────┤
1550 │hoplimit │ Hop limit │ integer (8 bit) │
1551 ├──────────┼─────────────────────┼──────────────────┤
1552 │saddr │ Source address │ ipv6_addr │
1553 ├──────────┼─────────────────────┼──────────────────┤
1554 │daddr │ Destination address │ ipv6_addr │
1555 └──────────┴─────────────────────┴──────────────────┘
1556 matching if first extension header indicates a fragment
1557
1558 ip6 nexthdr ipv6-frag counter
1559
1560 ICMPV6 HEADER EXPRESSION
1561 icmpv6 [ICMPv6 header field]
1562
1563 ICMPv6 header expression
1564
1565 ┌──────────────────┬─────────────────────┬──────────────────┐
1566 │Keyword │ Description │ Type │
1567 ├──────────────────┼─────────────────────┼──────────────────┤
1568 │type │ ICMPv6 type field │ icmpv6_type │
1569 ├──────────────────┼─────────────────────┼──────────────────┤
1570 │code │ ICMPv6 code field │ integer (8 bit) │
1571 ├──────────────────┼─────────────────────┼──────────────────┤
1572 │checksum │ ICMPv6 checksum │ integer (16 bit) │
1573 │ │ field │ │
1574 ├──────────────────┼─────────────────────┼──────────────────┤
1575 │parameter-problem │ pointer to problem │ integer (32 bit) │
1576 ├──────────────────┼─────────────────────┼──────────────────┤
1577 │packet-too-big │ oversized MTU │ integer (32 bit) │
1578 ├──────────────────┼─────────────────────┼──────────────────┤
1579 │id │ ID of echo re‐ │ integer (16 bit) │
1580 │ │ quest/response │ │
1581 ├──────────────────┼─────────────────────┼──────────────────┤
1582 │sequence │ sequence number of │ integer (16 bit) │
1583 │ │ echo request/re‐ │ │
1584 │ │ sponse │ │
1585 ├──────────────────┼─────────────────────┼──────────────────┤
1586 │max-delay │ maximum response │ integer (16 bit) │
1587 │ │ delay of MLD │ │
1588 │ │ queries │ │
1589 └──────────────────┴─────────────────────┴──────────────────┘
1590 TCP HEADER EXPRESSION
1591 tcp [TCP header field]
1592
1593 TCP header expression
1594
1595 ┌─────────┬──────────────────┬─────────────────────┐
1596 │Keyword │ Description │ Type │
1597 ├─────────┼──────────────────┼─────────────────────┤
1598 │sport │ Source port │ inet_service │
1599 ├─────────┼──────────────────┼─────────────────────┤
1600 │dport │ Destination port │ inet_service │
1601 ├─────────┼──────────────────┼─────────────────────┤
1602 │sequence │ Sequence number │ integer (32 bit) │
1603 ├─────────┼──────────────────┼─────────────────────┤
1604 │ackseq │ Acknowledgement │ integer (32 bit) │
1605 │ │ number │ │
1606 ├─────────┼──────────────────┼─────────────────────┤
1607 │doff │ Data offset │ integer (4 bit) │
1608 │ │ │ FIXME scaling │
1609 ├─────────┼──────────────────┼─────────────────────┤
1610 │reserved │ Reserved area │ integer (4 bit) │
1611 ├─────────┼──────────────────┼─────────────────────┤
1612 │flags │ TCP flags │ tcp_flag │
1613 ├─────────┼──────────────────┼─────────────────────┤
1614 │window │ Window │ integer (16 bit) │
1615 ├─────────┼──────────────────┼─────────────────────┤
1616 │checksum │ Checksum │ integer (16 bit) │
1617 ├─────────┼──────────────────┼─────────────────────┤
1618 │urgptr │ Urgent pointer │ integer (16 bit) │
1619 └─────────┴──────────────────┴─────────────────────┘
1620 UDP HEADER EXPRESSION
1621 udp [UDP header field]
1622
1623 UDP header expression
1624
1625 ┌─────────┬─────────────────────┬──────────────────┐
1626 │Keyword │ Description │ Type │
1627 ├─────────┼─────────────────────┼──────────────────┤
1628 │sport │ Source port │ inet_service │
1629 ├─────────┼─────────────────────┼──────────────────┤
1630 │dport │ Destination port │ inet_service │
1631 ├─────────┼─────────────────────┼──────────────────┤
1632 │length │ Total packet length │ integer (16 bit) │
1633 ├─────────┼─────────────────────┼──────────────────┤
1634 │checksum │ Checksum │ integer (16 bit) │
1635 └─────────┴─────────────────────┴──────────────────┘
1636 UDP-LITE HEADER EXPRESSION
1637 udplite [UDP-Lite header field]
1638
1639 UDP-Lite header expression
1640
1641 ┌─────────┬──────────────────┬──────────────────┐
1642 │Keyword │ Description │ Type │
1643 ├─────────┼──────────────────┼──────────────────┤
1644 │sport │ Source port │ inet_service │
1645 ├─────────┼──────────────────┼──────────────────┤
1646 │dport │ Destination port │ inet_service │
1647 ├─────────┼──────────────────┼──────────────────┤
1648 │checksum │ Checksum │ integer (16 bit) │
1649 └─────────┴──────────────────┴──────────────────┘
1650 SCTP HEADER EXPRESSION
1651 sctp [SCTP header field]
1652
1653 SCTP header expression
1654
1655 ┌─────────┬──────────────────┬──────────────────┐
1656 │Keyword │ Description │ Type │
1657 ├─────────┼──────────────────┼──────────────────┤
1658 │sport │ Source port │ inet_service │
1659 ├─────────┼──────────────────┼──────────────────┤
1660 │dport │ Destination port │ inet_service │
1661 ├─────────┼──────────────────┼──────────────────┤
1662 │vtag │ Verification Tag │ integer (32 bit) │
1663 ├─────────┼──────────────────┼──────────────────┤
1664 │checksum │ Checksum │ integer (32 bit) │
1665 └─────────┴──────────────────┴──────────────────┘
1666 DCCP HEADER EXPRESSION
1667 dccp [DCCP header field]
1668
1669 DCCP header expression
1670
1671 ┌────────┬──────────────────┬──────────────┐
1672 │Keyword │ Description │ Type │
1673 ├────────┼──────────────────┼──────────────┤
1674 │sport │ Source port │ inet_service │
1675 ├────────┼──────────────────┼──────────────┤
1676 │dport │ Destination port │ inet_service │
1677 └────────┴──────────────────┴──────────────┘
1678 AUTHENTICATION HEADER EXPRESSION
1679 ah [AH header field]
1680
1681 AH header expression
1682
1683 ┌──────────┬─────────────────────┬──────────────────┐
1684 │Keyword │ Description │ Type │
1685 ├──────────┼─────────────────────┼──────────────────┤
1686 │nexthdr │ Next header proto‐ │ inet_proto │
1687 │ │ col │ │
1688 ├──────────┼─────────────────────┼──────────────────┤
1689 │hdrlength │ AH Header length │ integer (8 bit) │
1690 ├──────────┼─────────────────────┼──────────────────┤
1691 │reserved │ Reserved area │ integer (16 bit) │
1692 ├──────────┼─────────────────────┼──────────────────┤
1693 │spi │ Security Parameter │ integer (32 bit) │
1694 │ │ Index │ │
1695 ├──────────┼─────────────────────┼──────────────────┤
1696 │sequence │ Sequence number │ integer (32 bit) │
1697 └──────────┴─────────────────────┴──────────────────┘
1698 ENCRYPTED SECURITY PAYLOAD HEADER EXPRESSION
1699 esp [ESP header field]
1700
1701 ESP header expression
1702
1703 ┌─────────┬─────────────────────┬──────────────────┐
1704 │Keyword │ Description │ Type │
1705 ├─────────┼─────────────────────┼──────────────────┤
1706 │spi │ Security Parameter │ integer (32 bit) │
1707 │ │ Index │ │
1708 ├─────────┼─────────────────────┼──────────────────┤
1709 │sequence │ Sequence number │ integer (32 bit) │
1710 └─────────┴─────────────────────┴──────────────────┘
1711 IPCOMP HEADER EXPRESSION
1712 comp [IPComp header field]
1713
1714 IPComp header expression
1715
1716 ┌────────┬─────────────────────┬──────────────────┐
1717 │Keyword │ Description │ Type │
1718 ├────────┼─────────────────────┼──────────────────┤
1719 │nexthdr │ Next header proto‐ │ inet_proto │
1720 │ │ col │ │
1721 ├────────┼─────────────────────┼──────────────────┤
1722 │flags │ Flags │ bitmask │
1723 ├────────┼─────────────────────┼──────────────────┤
1724 │cpi │ Compression Parame‐ │ integer (16 bit) │
1725 │ │ ter Index │ │
1726 └────────┴─────────────────────┴──────────────────┘
1727 RAW PAYLOAD EXPRESSION
1728 @ [base,offset,length]
1729
1730 The raw payload expression instructs to load lengthbits starting at
1731 offsetbits. Bit 0 refers the the very first bit -- in the C program‐
1732 ming language, this corresponds to the topmost bit, i.e. 0x80 in case
1733 of an octet. They are useful to match headers that do not have a hu‐
1734 man-readable template expression yet. Note that nft will not add de‐
1735 pendencies for Raw payload expressions. If you e.g. want to match pro‐
1736 tocol fields of a transport header with protocol number 5, you need to
1737 manually exclude packets that have a different transport header, for
1738 instance my using meta l4proto 5 before the raw expression.
1739
1740 Supported payload protocol bases
1741
1742 ┌─────┬────────────────────────────┐
1743 │Base │ Description │
1744 ├─────┼────────────────────────────┤
1745 │ll │ Link layer, for example │
1746 │ │ the Ethernet header │
1747 ├─────┼────────────────────────────┤
1748 │nh │ Network header, for exam‐ │
1749 │ │ ple IPv4 or IPv6 │
1750 ├─────┼────────────────────────────┤
1751 │th │ Transport Header, for ex‐ │
1752 │ │ ample TCP │
1753 └─────┴────────────────────────────┘
1754 Matching destination port of both UDP and TCP
1755
1756 inet filter input meta l4proto {tcp, udp} @th,16,16 { dns, http }
1757
1758 Rewrite arp packet target hardware address if target protocol address
1759 matches a given address
1760
1761 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
1762
1763 EXTENSION HEADER EXPRESSIONS
1764 Extension header expressions refer to data from variable-sized protocol
1765 headers, such as IPv6 extension headers and TCP options.
1766
1767 nftables currently supports matching (finding) a given ipv6 extension
1768 header or TCP option.
1769 hbh {nexthdr | hdrlength}
1770 frag {nexthdr | frag-off | more-fragments | id}
1771 rt {nexthdr | hdrlength | type | seg-left}
1772 dst {nexthdr | hdrlength}
1773 mh {nexthdr | hdrlength | checksum | type}
1774 srh {flags | tag | sid | seg-left}
1775 tcp option {eol | noop | maxseg | window | sack-permitted | sack |
1776 sack0 | sack1 | sack2 | sack3 | timestamp} tcp_option_field
1777
1778 The following syntaxes are valid only in a relational expression with
1779 boolean type on right-hand side for checking header existence only:
1780 exthdr {hbh | frag | rt | dst | mh}
1781 tcp option {eol | noop | maxseg | window | sack-permitted | sack |
1782 sack0 | sack1 | sack2 | sack3 | timestamp}
1783
1784 IPv6 extension headers
1785
1786 ┌────────┬────────────────────────┐
1787 │Keyword │ Description │
1788 ├────────┼────────────────────────┤
1789 │hbh │ Hop by Hop │
1790 ├────────┼────────────────────────┤
1791 │rt │ Routing Header │
1792 ├────────┼────────────────────────┤
1793 │frag │ Fragmentation header │
1794 ├────────┼────────────────────────┤
1795 │dst │ dst options │
1796 ├────────┼────────────────────────┤
1797 │mh │ Mobility Header │
1798 ├────────┼────────────────────────┤
1799 │srh │ Segment Routing Header │
1800 └────────┴────────────────────────┘
1801 TCP Options
1802
1803 ┌───────────────┬─────────────────────┬─────────────────────┐
1804 │Keyword │ Description │ TCP option fields │
1805 ├───────────────┼─────────────────────┼─────────────────────┤
1806 │eol │ End of option list │ kind │
1807 ├───────────────┼─────────────────────┼─────────────────────┤
1808 │noop │ 1 Byte TCP No-op │ kind │
1809 │ │ options │ │
1810 ├───────────────┼─────────────────────┼─────────────────────┤
1811 │maxseg │ TCP Maximum Segment │ kind, length, size │
1812 │ │ Size │ │
1813 ├───────────────┼─────────────────────┼─────────────────────┤
1814 │window │ TCP Window Scaling │ kind, length, count │
1815 ├───────────────┼─────────────────────┼─────────────────────┤
1816 │sack-permitted │ TCP SACK permitted │ kind, length │
1817 ├───────────────┼─────────────────────┼─────────────────────┤
1818 │sack │ TCP Selective Ac‐ │ kind, length, left, │
1819 │ │ knowledgement │ right │
1820 │ │ (alias of block 0) │ │
1821 ├───────────────┼─────────────────────┼─────────────────────┤
1822 │sack0 │ TCP Selective Ac‐ │ kind, length, left, │
1823 │ │ knowledgement │ right │
1824 │ │ (block 0) │ │
1825 ├───────────────┼─────────────────────┼─────────────────────┤
1826 │sack1 │ TCP Selective Ac‐ │ kind, length, left, │
1827 │ │ knowledgement │ right │
1828 │ │ (block 1) │ │
1829 ├───────────────┼─────────────────────┼─────────────────────┤
1830 │sack2 │ TCP Selective Ac‐ │ kind, length, left, │
1831 │ │ knowledgement │ right │
1832 │ │ (block 2) │ │
1833 ├───────────────┼─────────────────────┼─────────────────────┤
1834 │sack3 │ TCP Selective Ac‐ │ kind, length, left, │
1835 │ │ knowledgement │ right │
1836 │ │ (block 3) │ │
1837 ├───────────────┼─────────────────────┼─────────────────────┤
1838 │timestamp │ TCP Timestamps │ kind, length, │
1839 │ │ │ tsval, tsecr │
1840 └───────────────┴─────────────────────┴─────────────────────┘
1841 finding TCP options
1842
1843 filter input tcp option sack-permitted kind 1 counter
1844
1845 matching IPv6 exthdr
1846
1847 ip6 filter input frag more-fragments 1 counter
1848
1849 CONNTRACK EXPRESSIONS
1850 Conntrack expressions refer to meta data of the connection tracking en‐
1851 try associated with a packet.
1852
1853 There are three types of conntrack expressions. Some conntrack expres‐
1854 sions require the flow direction before the conntrack key, others must
1855 be used directly because they are direction agnostic. The packets,
1856 bytes and avgpkt keywords can be used with or without a direction. If
1857 the direction is omitted, the sum of the original and the reply direc‐
1858 tion is returned. The same is true for the zone, if a direction is giv‐
1859 en, the zone is only matched if the zone id is tied to the given direc‐
1860 tion.
1861
1862 ct {state | direction | status | mark | expiration | helper | label |
1863 l3proto | protocol | bytes | packets | avgpkt | zone}
1864 ct {original | reply} {l3proto | protocol | proto-src | proto-dst |
1865 bytes | packets | avgpkt | zone}
1866 ct {original | reply} {ip | ip6} {saddr | daddr}
1867
1868 Conntrack expressions
1869
1870 ┌───────────┬─────────────────────┬─────────────────────┐
1871 │Keyword │ Description │ Type │
1872 ├───────────┼─────────────────────┼─────────────────────┤
1873 │state │ State of the con‐ │ ct_state │
1874 │ │ nection │ │
1875 ├───────────┼─────────────────────┼─────────────────────┤
1876 │direction │ Direction of the │ ct_dir │
1877 │ │ packet relative to │ │
1878 │ │ the connection │ │
1879 ├───────────┼─────────────────────┼─────────────────────┤
1880 │status │ Status of the con‐ │ ct_status │
1881 │ │ nection │ │
1882 ├───────────┼─────────────────────┼─────────────────────┤
1883 │mark │ Connection mark │ mark │
1884 ├───────────┼─────────────────────┼─────────────────────┤
1885 │expiration │ Connection expira‐ │ time │
1886 │ │ tion time │ │
1887 ├───────────┼─────────────────────┼─────────────────────┤
1888 │helper │ Helper associated │ string │
1889 │ │ with the connection │ │
1890 ├───────────┼─────────────────────┼─────────────────────┤
1891 │label │ Connection tracking │ ct_label │
1892 │ │ label bit or sym‐ │ │
1893 │ │ bolic name defined │ │
1894 │ │ in connlabel.conf │ │
1895 │ │ in the nftables in‐ │ │
1896 │ │ clude path │ │
1897 ├───────────┼─────────────────────┼─────────────────────┤
1898 │l3proto │ Layer 3 protocol of │ nf_proto │
1899 │ │ the connection │ │
1900 ├───────────┼─────────────────────┼─────────────────────┤
1901 │saddr │ Source address of │ ipv4_addr/ipv6_addr │
1902 │ │ the connection for │ │
1903 │ │ the given direction │ │
1904 ├───────────┼─────────────────────┼─────────────────────┤
1905 │daddr │ Destination address │ ipv4_addr/ipv6_addr │
1906 │ │ of the connection │ │
1907 │ │ for the given di‐ │ │
1908 │ │ rection │ │
1909 ├───────────┼─────────────────────┼─────────────────────┤
1910 │protocol │ Layer 4 protocol of │ inet_proto │
1911 │ │ the connection for │ │
1912 │ │ the given direction │ │
1913 ├───────────┼─────────────────────┼─────────────────────┤
1914 │proto-src │ Layer 4 protocol │ integer (16 bit) │
1915 │ │ source for the giv‐ │ │
1916 │ │ en direction │ │
1917 ├───────────┼─────────────────────┼─────────────────────┤
1918 │proto-dst │ Layer 4 protocol │ integer (16 bit) │
1919 │ │ destination for the │ │
1920 │ │ given direction │ │
1921 ├───────────┼─────────────────────┼─────────────────────┤
1922 │packets │ packet count seen │ integer (64 bit) │
1923 │ │ in the given direc‐ │ │
1924 │ │ tion or sum of │ │
1925 │ │ original and reply │ │
1926 ├───────────┼─────────────────────┼─────────────────────┤
1927 │bytes │ byte count seen, │ integer (64 bit) │
1928 │ │ see description for │ │
1929 │ │ packets keyword │ │
1930 ├───────────┼─────────────────────┼─────────────────────┤
1931 │avgpkt │ average bytes per │ integer (64 bit) │
1932 │ │ packet, see de‐ │ │
1933 │ │ scription for pack‐ │ │
1934 │ │ ets keyword │ │
1935 ├───────────┼─────────────────────┼─────────────────────┤
1936 │zone │ conntrack zone │ integer (16 bit) │
1937 └───────────┴─────────────────────┴─────────────────────┘
1938 A description of conntrack-specific types listed above can be found
1939 sub-section CONNTRACK TYPES above.
1940
1942 Statements represent actions to be performed. They can alter control
1943 flow (return, jump to a different chain, accept or drop the packet) or
1944 can perform actions, such as logging, rejecting a packet, etc.
1945
1946 Statements exist in two kinds. Terminal statements unconditionally ter‐
1947 minate evaluation of the current rule, non-terminal statements either
1948 only conditionally or never terminate evaluation of the current rule,
1949 in other words, they are passive from the ruleset evaluation perspec‐
1950 tive. There can be an arbitrary amount of non-terminal statements in a
1951 rule, but only a single terminal statement as the final statement.
1952
1953 VERDICT STATEMENT
1954 The verdict statement alters control flow in the ruleset and issues
1955 policy decisions for packets.
1956
1957 {accept | drop | queue | continue | return}
1958 {jump | goto} chain
1959
1960 accept Terminate ruleset evaluation and accept the packet.
1961
1962 drop Terminate ruleset evaluation and drop the packet.
1963
1964 queue Terminate ruleset evaluation and queue the packet to userspace.
1965
1966 continue
1967 Continue ruleset evaluation with the next rule. FIXME
1968
1969 return Return from the current chain and continue evaluation at the
1970 next rule in the last chain. If issued in a base chain, it is
1971 equivalent to accept.
1972
1973 jump chain
1974 Continue evaluation at the first rule in chain. The current po‐
1975 sition in the ruleset is pushed to a call stack and evaluation
1976 will continue there when the new chain is entirely evaluated of
1977 a return verdict is issued.
1978
1979 goto chain
1980 Similar to jump, but the current position is not pushed to the
1981 call stack, meaning that after the new chain evaluation will
1982 continue at the last chain instead of the one containing the go‐
1983 to statement.
1984
1985 Verdict statements
1986
1987 # process packets from eth0 and the internal network in from_lan
1988 # chain, drop all packets from eth0 with different source addresses.
1989
1990 filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan
1991 filter input iif eth0 drop
1992
1993 PAYLOAD STATEMENT
1994 The payload statement alters packet content. It can be used for exam‐
1995 ple to set ip DSCP (differv) header field or ipv6 flow labels.
1996
1997 route some packets instead of bridging
1998
1999 # redirect tcp:http from 192.160.0.0/16 to local machine for routing instead of bridging
2000 # assumes 00:11:22:33:44:55 is local MAC address.
2001 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
2002
2003 Set IPv4 DSCP header field
2004
2005 ip forward ip dscp set 42
2006
2007 EXTENSION HEADER STATEMENT
2008 The extension header statement alters packet content in variable-sized
2009 headers. This can currently be used to alter the TCP Maximum segment
2010 size of packets, similar to TCPMSS.
2011
2012 change tcp mss
2013
2014 tcp flags syn tcp option maxseg size set 1360
2015 # set a size based on route information:
2016 tcp flags syn tcp option maxseg size set rt mtu
2017
2018 LOG STATEMENT
2019 log [prefix quoted_string] [level syslog-level] [flags log-flags]
2020 log group nflog_group [prefix quoted_string] [queue-threshold value]
2021 [snaplen size]
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). If the
2027 group number is specified, the Linux kernel will pass the packet to
2028 nfnetlink_log which will multicast the packet through a netlink socket
2029 to the specified multicast group. One or more userspace processes may
2030 subscribe to the group to receive the packets, see libnetfilter_queue
2031 documentation for details. This is a non-terminating statement, so the
2032 rule evaluation continues after the packet is logged.
2033
2034 log statement options
2035
2036 ┌────────────────┬─────────────────────┬─────────────────────┐
2037 │Keyword │ Description │ Type │
2038 ├────────────────┼─────────────────────┼─────────────────────┤
2039 │prefix │ Log message prefix │ quoted string │
2040 ├────────────────┼─────────────────────┼─────────────────────┤
2041 │level │ Syslog level of │ string: emerg, │
2042 │ │ logging │ alert, crit, err, │
2043 │ │ │ warn [default], no‐ │
2044 │ │ │ tice, info, debug │
2045 ├────────────────┼─────────────────────┼─────────────────────┤
2046 │group │ NFLOG group to send │ unsigned integer │
2047 │ │ messages to │ (16 bit) │
2048 ├────────────────┼─────────────────────┼─────────────────────┤
2049 │snaplen │ Length of packet │ unsigned integer │
2050 │ │ payload to include │ (32 bit) │
2051 │ │ in netlink message │ │
2052 ├────────────────┼─────────────────────┼─────────────────────┤
2053 │queue-threshold │ Number of packets │ unsigned integer │
2054 │ │ to queue inside the │ (32 bit) │
2055 │ │ kernel before send‐ │ │
2056 │ │ ing them to │ │
2057 │ │ userspace │ │
2058 └────────────────┴─────────────────────┴─────────────────────┘
2059 log-flags
2060
2061 ┌─────────────┬────────────────────────────┐
2062 │Flag │ Description │
2063 ├─────────────┼────────────────────────────┤
2064 │tcp sequence │ Log TCP sequence numbers. │
2065 ├─────────────┼────────────────────────────┤
2066 │tcp options │ Log options from the TCP │
2067 │ │ packet header. │
2068 ├─────────────┼────────────────────────────┤
2069 │ip options │ Log options from the │
2070 │ │ IP/IPv6 packet header. │
2071 ├─────────────┼────────────────────────────┤
2072 │skuid │ Log the userid of the │
2073 │ │ process which generated │
2074 │ │ the packet. │
2075 ├─────────────┼────────────────────────────┤
2076 │ether │ Decode MAC addresses and │
2077 │ │ protocol. │
2078 ├─────────────┼────────────────────────────┤
2079 │all │ Enable all log flags list‐ │
2080 │ │ ed above. │
2081 └─────────────┴────────────────────────────┘
2082 Using log statement
2083
2084 # log the UID which generated the packet and ip options
2085 ip filter output log flags skuid flags ip options
2086
2087 # log the tcp sequence numbers and tcp options from the TCP packet
2088 ip filter output log flags tcp sequence,options
2089
2090 # enable all supported log flags
2091 ip6 filter output log flags all
2092
2093 REJECT STATEMENT
2094 reject [ with {icmp | icmpv6 | icmpx} type {icmp_code | icmpv6_code |
2095 icmpx_code} ]
2096 reject [ with tcp reset ]
2097
2098 A reject statement is used to send back an error packet in response to
2099 the matched packet otherwise it is equivalent to drop so it is a termi‐
2100 nating statement, ending rule traversal. This statement is only valid
2101 in the input, forward and output chains, and user-defined chains which
2102 are only called from those chains.
2103
2104 The different ICMP reject variants are meant for use in different table
2105 families:
2106
2107 ┌────────┬────────┬─────────────┐
2108 │Variant │ Family │ Type │
2109 ├────────┼────────┼─────────────┤
2110 │icmp │ ip │ icmp_code │
2111 ├────────┼────────┼─────────────┤
2112 │icmpv6 │ ip6 │ icmpv6_code │
2113 ├────────┼────────┼─────────────┤
2114 │icmpx │ inet │ icmpx_code │
2115 └────────┴────────┴─────────────┘
2116 For a description of the different types and a list of supported key‐
2117 words refer to DATA TYPES section above. The common default reject
2118 value is port-unreachable.
2119
2120 Note that in bridge family, reject statement is only allowed in base
2121 chains which hook into input or prerouting.
2122
2123 COUNTER STATEMENT
2124 A counter statement sets the hit count of packets along with the number
2125 of bytes.
2126
2127 counter [ packets number bytes number ]
2128
2129 CONNTRACK STATEMENT
2130 The conntrack statement can be used to set the conntrack mark and con‐
2131 ntrack labels.
2132
2133 ct {mark | event | label | zone} set value
2134
2135 The ct statement sets meta data associated with a connection. The zone
2136 id has to be assigned before a conntrack lookup takes place, i.e. this
2137 has to be done in prerouting and possibly output (if locally generated
2138 packets need to be placed in a distinct zone), with a hook priority of
2139 -300.
2140
2141 Conntrack statement types
2142
2143 ┌────────┬─────────────────────┬─────────────────────┐
2144 │Keyword │ Description │ Value │
2145 ├────────┼─────────────────────┼─────────────────────┤
2146 │event │ conntrack event │ bitmask, integer │
2147 │ │ bits │ (32 bit) │
2148 ├────────┼─────────────────────┼─────────────────────┤
2149 │helper │ name of ct helper │ quoted string │
2150 │ │ object to assign to │ │
2151 │ │ the connection │ │
2152 ├────────┼─────────────────────┼─────────────────────┤
2153 │mark │ Connection tracking │ mark │
2154 │ │ mark │ │
2155 ├────────┼─────────────────────┼─────────────────────┤
2156 │label │ Connection tracking │ label │
2157 │ │ label │ │
2158 ├────────┼─────────────────────┼─────────────────────┤
2159 │zone │ conntrack zone │ integer (16 bit) │
2160 └────────┴─────────────────────┴─────────────────────┘
2161 save packet nfmark in conntrack
2162
2163 ct mark set meta mark
2164
2165 set zone mapped via interface
2166
2167 table inet raw {
2168 chain prerouting {
2169 type filter hook prerouting priority -300;
2170 ct zone set iif map { "eth1" : 1, "veth1" : 2 }
2171 }
2172 chain output {
2173 type filter hook output priority -300;
2174 ct zone set oif map { "eth1" : 1, "veth1" : 2 }
2175 }
2176 }
2177
2178 restrict events reported by ctnetlink
2179
2180 ct event set new,related,destroy
2181
2182 META STATEMENT
2183 A meta statement sets the value of a meta expression. The existing
2184 meta fields are: priority, mark, pkttype, nftrace.
2185
2186 meta {mark | priority | pkttype | nftrace} set value
2187
2188 A meta statement sets meta data associated with a packet.
2189
2190 Meta statement types
2191
2192 ┌─────────┬─────────────────────┬───────────┐
2193 │Keyword │ Description │ Value │
2194 ├─────────┼─────────────────────┼───────────┤
2195 │priority │ TC packet priority │ tc_handle │
2196 ├─────────┼─────────────────────┼───────────┤
2197 │mark │ Packet mark │ mark │
2198 ├─────────┼─────────────────────┼───────────┤
2199 │pkttype │ packet type │ pkt_type │
2200 ├─────────┼─────────────────────┼───────────┤
2201 │nftrace │ ruleset packet │ 0, 1 │
2202 │ │ tracing on/off. Use │ │
2203 │ │ monitor trace com‐ │ │
2204 │ │ mand to watch │ │
2205 │ │ traces │ │
2206 └─────────┴─────────────────────┴───────────┘
2207 LIMIT STATEMENT
2208 limit rate [over] packet_number / {second | minute | hour | day} [burst
2209 packet_number packets]
2210 limit rate [over] byte_number {bytes | kbytes | mbytes} / {second |
2211 minute | hour | day | week} [burst byte_number bytes]
2212
2213 A limit statement matches at a limited rate using a token bucket fil‐
2214 ter. A rule using this statement will match until this limit is
2215 reached. It can be used in combination with the log statement to give
2216 limited logging. The over keyword, that is optional, makes it match
2217 over the specified rate.
2218
2219 limit statement values
2220
2221 ┌──────────────┬───────────────────┬─────────────────────┐
2222 │Value │ Description │ Type │
2223 ├──────────────┼───────────────────┼─────────────────────┤
2224 │packet_number │ Number of packets │ unsigned integer │
2225 │ │ │ (32 bit) │
2226 ├──────────────┼───────────────────┼─────────────────────┤
2227 │byte_number │ Number of bytes │ unsigned integer │
2228 │ │ │ (32 bit) │
2229 └──────────────┴───────────────────┴─────────────────────┘
2230 NAT STATEMENTS
2231 snat to address [:port] [persistent, random, fully-random]
2232 snat to address - address [:port - port] [persistent, random, fully-
2233 random]
2234 dnat to address [:port] [persistent, random, fully-random]
2235 dnat to address [:port - port] [persistent, random, fully-random]
2236 masquerade to [:port] [persistent, random, fully-random]
2237 masquerade to [:port - port] [persistent, random, fully-random]
2238 redirect to [:port] [persistent, random, fully-random]
2239 redirect to [:port - port] [persistent, random, fully-random]
2240
2241 The nat statements are only valid from nat chain types.
2242
2243 The snat and masquerade statements specify that the source address of
2244 the packet should be modified. While snat is only valid in the
2245 postrouting and input chains, masquerade makes sense only in postrout‐
2246 ing. The dnat and redirect statements are only valid in the prerouting
2247 and output chains, they specify that the destination address of the
2248 packet should be modified. You can use non-base chains which are called
2249 from base chains of nat chain type too. All future packets in this con‐
2250 nection will also be mangled, and rules should cease being examined.
2251
2252 The masquerade statement is a special form of snat which always uses
2253 the outgoing interface's IP address to translate to. It is particularly
2254 useful on gateways with dynamic (public) IP addresses.
2255
2256 The redirect statement is a special form of dnat which always trans‐
2257 lates the destination address to the local host's one. It comes in
2258 handy if one only wants to alter the destination port of incoming traf‐
2259 fic on different interfaces.
2260
2261 Note that all nat statements require both prerouting and postrouting
2262 base chains to be present since otherwise packets on the return path
2263 won't be seen by netfilter and therefore no reverse translation will
2264 take place.
2265
2266 NAT statement values
2267
2268 ┌───────────┬─────────────────────┬─────────────────────┐
2269 │Expression │ Description │ Type │
2270 ├───────────┼─────────────────────┼─────────────────────┤
2271 │address │ Specifies that the │ ipv4_addr, ipv6_ad‐ │
2272 │ │ source/destination │ dr, e.g. │
2273 │ │ address of the │ abcd::1234, or you │
2274 │ │ packet should be │ can use a mapping, │
2275 │ │ modified. You may │ e.g. meta mark map │
2276 │ │ specify a mapping │ { 10 : 192.168.1.2, │
2277 │ │ to relate a list of │ 20 : 192.168.1.3 } │
2278 │ │ tuples composed of │ │
2279 │ │ arbitrary expres‐ │ │
2280 │ │ sion key with ad‐ │ │
2281 │ │ dress value. │ │
2282 ├───────────┼─────────────────────┼─────────────────────┤
2283 │port │ Specifies that the │ port number (16 │
2284 │ │ source/destination │ bits) │
2285 │ │ address of the │ │
2286 │ │ packet should be │ │
2287 │ │ modified. │ │
2288 └───────────┴─────────────────────┴─────────────────────┘
2289 NAT statement flags
2290
2291 ┌─────────────┬────────────────────────────┐
2292 │Flag │ Description │
2293 ├─────────────┼────────────────────────────┤
2294 │persistent │ Gives a client the same │
2295 │ │ source-/destination-ad‐ │
2296 │ │ dress for each connection. │
2297 ├─────────────┼────────────────────────────┤
2298 │random │ If used then port mapping │
2299 │ │ will be randomized using a │
2300 │ │ random seeded MD5 hash mix │
2301 │ │ using source and destina‐ │
2302 │ │ tion address and destina‐ │
2303 │ │ tion port. │
2304 ├─────────────┼────────────────────────────┤
2305 │fully-random │ If used then port mapping │
2306 │ │ is generated based on a │
2307 │ │ 32-bit pseudo-random algo‐ │
2308 │ │ rithm. │
2309 └─────────────┴────────────────────────────┘
2310 Using NAT statements
2311
2312 # create a suitable table/chain setup for all further examples
2313 add table nat
2314 add chain nat prerouting { type nat hook prerouting priority 0; }
2315 add chain nat postrouting { type nat hook postrouting priority 100; }
2316
2317 # translate source addresses of all packets leaving via eth0 to address 1.2.3.4
2318 add rule nat postrouting oif eth0 snat to 1.2.3.4
2319
2320 # redirect all traffic entering via eth0 to destination address 192.168.1.120
2321 add rule nat prerouting iif eth0 dnat to 192.168.1.120
2322
2323 # translate source addresses of all packets leaving via eth0 to whatever
2324 # locally generated packets would use as source to reach the same destination
2325 add rule nat postrouting oif eth0 masquerade
2326
2327 # redirect incoming TCP traffic for port 22 to port 2222
2328 add rule nat prerouting tcp dport 22 redirect to :2222
2329
2330 FLOW OFFLOAD STATEMENT
2331 A flow offload statement allows us to select what flows you want to ac‐
2332 celerate forwarding through layer 3 network stack bypass. You have to
2333 specify the flowtable name where you want to offload this flow.
2334
2335 flow offload @flowtable
2336
2337 QUEUE STATEMENT
2338 This statement passes the packet to userspace using the nfnetlink_queue
2339 handler. The packet is put into the queue identified by its 16-bit
2340 queue number. Userspace can inspect and modify the packet if desired.
2341 Userspace must then drop or re-inject the packet into the kernel. See
2342 libnetfilter_queue documentation for details.
2343
2344 queue [num queue_number] [bypass]
2345 queue [num queue_number_from - queue_number_to] [bypass,fanout]
2346
2347 queue statement values
2348
2349 ┌──────────────────┬─────────────────────┬─────────────────────┐
2350 │Value │ Description │ Type │
2351 ├──────────────────┼─────────────────────┼─────────────────────┤
2352 │queue_number │ Sets queue number, │ unsigned integer │
2353 │ │ default is 0. │ (16 bit) │
2354 ├──────────────────┼─────────────────────┼─────────────────────┤
2355 │queue_number_from │ Sets initial queue │ unsigned integer │
2356 │ │ in the range, if │ (16 bit) │
2357 │ │ fanout is used. │ │
2358 ├──────────────────┼─────────────────────┼─────────────────────┤
2359 │queue_number_to │ Sets closing queue │ unsigned integer │
2360 │ │ in the range, if │ (16 bit) │
2361 │ │ fanout is used. │ │
2362 └──────────────────┴─────────────────────┴─────────────────────┘
2363 queue statement flags
2364
2365 ┌───────┬────────────────────────────┐
2366 │Flag │ Description │
2367 ├───────┼────────────────────────────┤
2368 │bypass │ Let packets go through if │
2369 │ │ userspace application can‐ │
2370 │ │ not back off. Before using │
2371 │ │ this flag, read libnetfil‐ │
2372 │ │ ter_queue documentation │
2373 │ │ for performance tuning │
2374 │ │ recommendations. │
2375 ├───────┼────────────────────────────┤
2376 │fanout │ Distribute packets between │
2377 │ │ several queues. │
2378 └───────┴────────────────────────────┘
2379 DUP STATEMENT
2380 The dup statement is used to duplicate a packet and send the copy to a
2381 different destination.
2382
2383 dup to device
2384 dup to address device device
2385
2386 Dup statement values
2387
2388 ┌───────────┬─────────────────────┬─────────────────────┐
2389 │Expression │ Description │ Type │
2390 ├───────────┼─────────────────────┼─────────────────────┤
2391 │address │ Specifies that the │ ipv4_addr, ipv6_ad‐ │
2392 │ │ copy of the packet │ dr, e.g. │
2393 │ │ should be sent to a │ abcd::1234, or you │
2394 │ │ new gateway. │ can use a mapping, │
2395 │ │ │ e.g. ip saddr map { │
2396 │ │ │ 192.168.1.2 : │
2397 │ │ │ 10.1.1.1 } │
2398 ├───────────┼─────────────────────┼─────────────────────┤
2399 │device │ Specifies that the │ string │
2400 │ │ copy should be │ │
2401 │ │ transmitted via de‐ │ │
2402 │ │ vice. │ │
2403 └───────────┴─────────────────────┴─────────────────────┘
2404 Using the dup statement
2405
2406 # send to machine with ip address 10.2.3.4 on eth0
2407 ip filter forward dup to 10.2.3.4 device "eth0"
2408
2409 # copy raw frame to another interface
2410 netdetv ingress dup to "eth0"
2411 dup to "eth0"
2412
2413 # combine with map dst addr to gateways
2414 dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" }
2415
2416 FWD STATEMENT
2417 The fwd statement is used to redirect a raw packet to another inter‐
2418 face. Its is only available in the netdev family ingress hook. It is
2419 similar to the dup statement except that no copy is made.
2420
2421 fwd to device
2422
2423 SET STATEMENT
2424 The set statement is used to dynamically add or update elements in a
2425 set from the packet path. The set setname must already exist in the
2426 given table. Furthermore, any set that will be dynamically updated
2427 from the nftables ruleset must specify both a maximum set size (to pre‐
2428 vent memory exhaustion) and a timeout (so that number of entries in set
2429 will not grow indefinitely). The set statement can be used to e.g.
2430 create dynamic blacklists.
2431
2432 {add | update} @setname { expression [timeout timeout] [comment string]
2433 }
2434
2435 Example for simple blacklist
2436
2437 # declare a set, bound to table "filter", in family "ip". Timeout and size are mandatory because we will add elements from packet path.
2438 nft add set ip filter blackhole "{ type ipv4_addr; flags timeout; size 65536; }"
2439
2440 # whitelist internal interface.
2441 nft add rule ip filter input meta iifname "internal" accept
2442
2443 # drop packets coming from blacklisted ip addresses.
2444 nft add rule ip filter input ip saddr @blackhole counter drop
2445
2446 # add source ip addresses to the blacklist if more than 10 tcp connection requests occurred per second and ip address.
2447 # entries will timeout after one minute, after which they might be re-added if limit condition persists.
2448 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
2449
2450 # inspect state of the rate limit meter:
2451 nft list meter ip filter flood
2452
2453 # inspect content of blackhole:
2454 nft list set ip filter blackhole
2455
2456 # manually add two addresses to the set:
2457 nft add element filter blackhole { 10.2.3.4, 10.23.1.42 }
2458
2460 These are some additional commands included in nft.
2461
2462 MONITOR
2463 The monitor command allows you to listen to Netlink events produced by
2464 the nf_tables subsystem, related to creation and deletion of objects.
2465 When they occur, nft will print to stdout the monitored events in ei‐
2466 ther XML, JSON or native nft format.
2467
2468 To filter events related to a concrete object, use one of the keywords
2469 'tables', 'chains', 'sets', 'rules', 'elements', 'ruleset'.
2470
2471 To filter events related to a concrete action, use keyword 'new' or
2472 'destroy'.
2473
2474 Hit ^C to finish the monitor operation.
2475
2476 Listen to all events, report in native nft format
2477
2478 % nft monitor
2479
2480 Listen to added tables, report in XML format
2481
2482 % nft monitor new tables xml
2483
2484 Listen to deleted rules, report in JSON format
2485
2486 % nft monitor destroy rules json
2487
2488 Listen to both new and destroyed chains, in native nft format
2489
2490 % nft monitor chains
2491
2492 Listen to ruleset events such as table, chain, rule, set, counters and
2493 quotas, in native nft format
2494
2495 % nft monitor ruleset
2496
2498 When an error is detected, nft shows the line(s) containing the error,
2499 the position of the erroneous parts in the input stream and marks up
2500 the erroneous parts using carets (^). If the error results from the
2501 combination of two expressions or statements, the part imposing the
2502 constraints which are violated is marked using tildes (~).
2503
2504 For errors returned by the kernel, nft can't detect which parts of the
2505 input caused the error and the entire command is marked.
2506
2507 Error caused by single incorrect expression
2508
2509 <cmdline>:1:19-22: Error: Interface does not exist
2510 filter output oif eth0
2511 ^^^^
2512
2513 Error caused by invalid combination of two expressions
2514
2515 <cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
2516 filter output tcp dport == tcp dport
2517 ~~ ^^^^^^^^^
2518
2519 Error returned by the kernel
2520
2521 <cmdline>:0:0-23: Error: Could not process rule: Operation not permitted
2522 filter output oif wlan0
2523 ^^^^^^^^^^^^^^^^^^^^^^^
2524
2526 On success, nft exits with a status of 0. Unspecified errors cause it
2527 to exit with a status of 1, memory allocation errors with a status of
2528 2, unable to open Netlink socket with 3.
2529
2531 iptables(8), ip6tables(8), arptables(8), ebtables(8), ip(8), tc(8)
2532
2533 There is an official wiki at: https://wiki.nftables.org
2534
2536 nftables was written by Patrick McHardy and Pablo Neira Ayuso, among
2537 many other contributors from the Netfilter community.
2538
2540 Copyright 2008-2014 Patrick McHardy <kaber@trash.net>
2541 Copyright 2013-2016 Pablo Neira Ayuso <pablo@netfilter.org>
2542
2543 nftables is free software; you can redistribute it and/or modify it un‐
2544 der the terms of the GNU General Public License version 2 as published
2545 by the Free Software Foundation.
2546
2547 This documentation is licensed under the terms of the Creative Commons
2548 Attribution-ShareAlike 4.0 license, CC BY-SA 4.0 ⟨http://
2549 creativecommons.org/licenses/by-sa/4.0/⟩ .
2550
2551
2552
2553 14 July 2018 nft(8)