1nft(8) nft(8)
2
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 -h, --help
24 Show help message and all options.
25 -v, --version
27 Show version.
28 -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 -N, --reversedns
36 Translate IP addresses to names. Usually requires network traf‐
37 fic for DNS lookup.
38 -s, --stateless
40 Omit stateful information of rules and stateful objects.
41 -c, --check
43 Check commands validity without actually applying the changes.
44 -a, --handle
46 Show object handles in output.
47 -e, --echo
49 When inserting items into the ruleset using add, insert or re‐
50 place commands, print notifications just like nft monitor.
51 -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 -f, --file filename
58 Read input from filename. If filename is -, read from stdin.
59 nft scripts must start #!/usr/sbin/nft -f
61 -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 A hash sign (#) begins a comment. All following characters on the same
74 line are ignored.
75 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 INCLUDE FILES
83 include filename
84 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 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 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 SYMBOLIC VARIABLES
105 define variable expr
106 $variable
107 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 Using symbolic variables
114 define int_if1 = eth0
116 define int_if2 = eth1
117 define int_ifs = { $int_if1, $int_if2 }
118 filter input iif $int_ifs accept
120
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 ip IPv4 address family.
129 ip6 IPv6 address family.
131 inet Internet (IPv4/IPv6) address family.
133 arp ARP address family, handling IPv4 ARP packets.
135 bridge Bridge address family, handling packets which traverse a bridge
137 device.
138 netdev Netdev address family, handling packets from ingress.
140 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 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 IPv4/IPv6/Inet address family hooks
152 ┌────────────┬────────────────────────────┐
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 ARP address family hooks
187 ┌───────┬────────────────────────────┐
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 The list of supported hooks is identical to IPv4/IPv6/Inet address fam‐
204 ilies above.
205 NETDEV ADDRESS FAMILY
207 The Netdev address family handles packets from ingress.
208 Netdev address family hooks
210 ┌────────┬────────────────────────────┐
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 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 list Print the ruleset in human-readable format.
231 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 export Print the ruleset in machine readable format. The mandatory for‐
238 mat parameter may be either xml or json.
239 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 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 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 Table flags
264 ┌────────┬────────────────────────────┐
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 # start nft in interactive mode
275 nft --interactive
276 # create a new table.
278 create table inet mytable
279 # add a new base chain: get input packets
281 add chain inet mytable myin { type filter hook input priority 0; }
282 # add a single counter to the chain
284 add rule inet mytable myin counter
285 # disable the table temporarily -- rules are not evaluated anymore
287 add table inet mytable { flags dormant; }
288 # make table active again:
290 add table inet mytable
291 add Add a new table for the given family with the given name.
294 delete Delete the specified table.
296 list List all chains and rules of the specified table.
298 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 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 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 create Similar to the add command, but returns an error if the chain
318 already exists.
319 delete Delete the specified chain. The chain must not contain any rules
321 or be used as jump target.
322 rename Rename the specified chain.
324 list List all rules of the specified chain.
326 flush Flush all rules of the specified chain.
328 For base chains, type, hook and priority parameters are mandatory.
330 Supported chain types
332 ┌───────┬──────────┬──────────────────┬──────────────────┐
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 · 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 · arp family supports only input and output hooks, both in chains of
385 type filter.
386 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 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 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 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 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 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 replace
427 Similar to the add command, but the rule replaces the specified
428 rule.
429 delete Delete the specified rule.
431 add a rule to ip table input chain
433 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 delete rule from inet table
441 # 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
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 Using anonymous sets to accept particular subnets and ports
463 nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept
465 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 Using named sets to accept addresses and ports
473 nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept
475 The sets allowed_hosts and allowed_ports need to be created first. The
478 next section describes nft set syntax in more detail.
479 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 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 add Add a new set in the specified table.
491 delete Delete the specified set.
493 list Display the elements in the specified set.
495 flush Remove all elements from the specified set.
497 add element
499 Comma-separated list of elements to add into the specified set.
500 delete element
502 Comma-separated list of elements to delete from the specified
503 set.
504 Set specifications
506 ┌────────────┬─────────────────────┬─────────────────────┐
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 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 add Add a new map in the specified table.
562 delete Delete the specified map.
564 list Display the elements in the specified map.
566 flush Remove all elements from the specified map.
568 add element
570 Comma-separated list of elements to add into the specified map.
571 delete element
573 Comma-separated list of element keys to delete from the speci‐
574 fied map.
575 Map specifications
577 ┌─────────┬─────────────────────┬─────────────────────┐
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 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 add Add a new flowtable for the given family with the given name.
625 delete Delete the specified flowtable.
627 list List all flowtables.
629
631 {add | delete | list | reset} type [family] table object
632 delete type [family] table handle handle
633 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 add Add a new stateful object in the specified table.
639 delete Delete the specified object.
641 list Display stateful information the object holds.
643 reset List-and-reset stateful object.
645 CT
647 ct helper helper { type type protocol protocol ; [l3proto family ;] }
648 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 conntrack helper specifications
656 ┌─────────┬─────────────────────┬─────────────────────┐
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 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 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 COUNTER
686 counter [packets bytes]
687 Counter specifications
689 ┌────────┬─────────────────────┬─────────────────────┐
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 Quota specifications
703 ┌────────┬─────────────────────┬─────────────────────┐
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 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 DESCRIBE COMMAND
734 describe expression
735 The describe command shows information about the type of an expression
737 and its data type.
738 The describe command
740 $ nft describe tcp flags
742 payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits
743 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 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 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 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 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 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 String specification
800 # Interface name
802 filter input iifname eth0
803 # Weird interface name
805 filter input iifname "(eth0)"
806 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 Link layer address specification
819 # Ethernet destination MAC address
821 filter input ether daddr 20:c9:d0:43:12:d9
822 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 IPv4 address specification
835 # dotted decimal notation
837 filter output ip daddr 127.0.0.1
838 # host name
840 filter output ip daddr localhost
841 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 IPv6 address specificationIPv6 address specification with bracket nota‐
854 tion
855 # abbreviated loopback address
857 filter output ip6 daddr ::1
858 # 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 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 The following keywords will automatically resolve into a boolean type
874 with given value:
875 ┌────────┬───────┐
877 │Keyword │ Value │
878 ├────────┼───────┤
879 │exists │ 1 │
880 ├────────┼───────┤
881 │missing │ 0 │
882 └────────┴───────┘
883 Boolean specification
884 The following expressions support a boolean comparison:
886 ┌───────────┬────────────────────────────┐
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 # match only non-fragmented packets in IPv6 traffic
902 filter input exthdr frag missing
903 # match if TCP timestamp option is present
905 filter input tcp option timestamp exists
906 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 The following keywords may be used when specifying the ICMP type:
917 ┌────────────────────────┬───────┐
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 # match ping packets
954 filter output icmp type { echo-request, echo-reply }
955 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 The following keywords may be used when specifying the ICMP code:
966 ┌─────────────────┬───────┐
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 The following keywords may be used when specifying the ICMPv6 type:
994 ┌────────────────────────┬───────┐
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 # match ICMPv6 ping packets
1039 filter output icmpv6 type { echo-request, echo-reply }
1040 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 The following keywords may be used when specifying the ICMPv6 code:
1051 ┌─────────────────┬───────┐
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 The following keywords may be used when specifying the ICMPvX code:
1077 ┌─────────────────┬───────┐
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 ┌─────────────────┬───────────┬─────────┬───────────┐
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 conntrack state (ct_state)
1110 ┌────────────┬───────┐
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 ┌─────────┬───────┐
1127 │Keyword │ Value │
1128 ├─────────┼───────┤
1129 │original │ 0 │
1130 ├─────────┼───────┤
1131 │reply │ 1 │
1132 └─────────┴───────┘
1133 conntrack status (ct_status)
1134 ┌───────────┬───────┐
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 ┌──────────┬───────┐
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 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 A meta expression refers to meta data associated with a packet.
1194 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 Meta expression types
1204 ┌──────────┬─────────────────────┬───────────────────┐
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 ┌──────────────┬────────────────────────────┐
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 # qualified meta expression
1321 filter output meta oif eth0
1322 # unqualified meta expression
1324 filter output oif eth0
1325 # packed was subject to ipsec processing
1327 raw prerouting meta secpath exists accept
1328 FIB EXPRESSIONS
1330 fib {saddr | daddr | {mark | iif | oif}} {oif | oifname | type}
1331 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 fib expression specific types
1338 ┌────────┬─────────────────────┬──────────────────┐
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 # drop packets without a reverse path
1353 filter prerouting fib saddr . iif oif missing drop
1354 # drop packets to address not configured on ininterface
1356 filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
1357 # 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 ROUTING EXPRESSIONS
1362 rt {classid | nexthop}
1363 A routing expression refers to routing data associated with a packet.
1365 Routing expression types
1367 ┌────────┬─────────────────────┬─────────────────────┐
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 ┌──────┬────────────────────────────┐
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 # IP family independent rt expression
1392 filter output rt classid 10
1393 # 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 ETHERNET HEADER EXPRESSION
1404 ether [Ethernet header field]
1405 Ethernet header expression types
1407 ┌────────┬─────────────────────┬────────────┐
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 VLAN header expression
1422 ┌────────┬─────────────────────┬──────────────────┐
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 ARP header expression
1439 ┌──────────┬─────────────────────┬──────────────────┐
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 IPv4 header expression
1459 ┌──────────┬─────────────────────┬─────────────────────┐
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 ICMP header expression
1496 ┌─────────┬─────────────────────┬──────────────────┐
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 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 IPv6 header expression
1531 ┌──────────┬─────────────────────┬──────────────────┐
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 ip6 nexthdr ipv6-frag counter
1559 ICMPV6 HEADER EXPRESSION
1561 icmpv6 [ICMPv6 header field]
1562 ICMPv6 header expression
1564 ┌──────────────────┬─────────────────────┬──────────────────┐
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 TCP header expression
1594 ┌─────────┬──────────────────┬─────────────────────┐
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 UDP header expression
1624 ┌─────────┬─────────────────────┬──────────────────┐
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 UDP-Lite header expression
1640 ┌─────────┬──────────────────┬──────────────────┐
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 SCTP header expression
1654 ┌─────────┬──────────────────┬──────────────────┐
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 DCCP header expression
1670 ┌────────┬──────────────────┬──────────────┐
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 AH header expression
1682 ┌──────────┬─────────────────────┬──────────────────┐
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 ESP header expression
1702 ┌─────────┬─────────────────────┬──────────────────┐
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 IPComp header expression
1715 ┌────────┬─────────────────────┬──────────────────┐
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 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 Supported payload protocol bases
1741 ┌─────┬────────────────────────────┐
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 inet filter input meta l4proto {tcp, udp} @th,16,16 { dns, http }
1757 Rewrite arp packet target hardware address if target protocol address
1759 matches a given address
1760 input meta iifname enp2s0 arp ptype 0x0800 arp htype 1 arp hlen 6 arp plen 4 @nh,192,32 0xc0a88f10 @nh,144,48 set 0x112233445566 accept
1762 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 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 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 IPv6 extension headers
1785 ┌────────┬────────────────────────┐
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 ┌───────────────┬─────────────────────┬─────────────────────┐
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 filter input tcp option sack-permitted kind 1 counter
1844 matching IPv6 exthdr
1846 ip6 filter input frag more-fragments 1 counter
1848 CONNTRACK EXPRESSIONS
1850 Conntrack expressions refer to meta data of the connection tracking en‐
1851 try associated with a packet.
1852 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 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 Conntrack expressions
1869 ┌───────────┬─────────────────────┬─────────────────────┐
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 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 VERDICT STATEMENT
1954 The verdict statement alters control flow in the ruleset and issues
1955 policy decisions for packets.
1956 {accept | drop | queue | continue | return}
1958 {jump | goto} chain
1959 accept Terminate ruleset evaluation and accept the packet.
1961 drop Terminate ruleset evaluation and drop the packet.
1963 queue Terminate ruleset evaluation and queue the packet to userspace.
1965 continue
1967 Continue ruleset evaluation with the next rule. FIXME
1968 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 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 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 Verdict statements
1986 # process packets from eth0 and the internal network in from_lan
1988 # chain, drop all packets from eth0 with different source addresses.
1989 filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan
1991 filter input iif eth0 drop
1992 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 route some packets instead of bridging
1998 # 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 Set IPv4 DSCP header field
2004 ip forward ip dscp set 42
2006 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 change tcp mss
2013 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 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 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 log statement options
2035 ┌────────────────┬─────────────────────┬─────────────────────┐
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 ┌─────────────┬────────────────────────────┐
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 # log the UID which generated the packet and ip options
2085 ip filter output log flags skuid flags ip options
2086 # log the tcp sequence numbers and tcp options from the TCP packet
2088 ip filter output log flags tcp sequence,options
2089 # enable all supported log flags
2091 ip6 filter output log flags all
2092 REJECT STATEMENT
2094 reject [ with {icmp | icmpv6 | icmpx} type {icmp_code | icmpv6_code |
2095 icmpx_code} ]
2096 reject [ with tcp reset ]
2097 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 The different ICMP reject variants are meant for use in different table
2105 families:
2106 ┌────────┬────────┬─────────────┐
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 Note that in bridge family, reject statement is only allowed in base
2121 chains which hook into input or prerouting.
2122 COUNTER STATEMENT
2124 A counter statement sets the hit count of packets along with the number
2125 of bytes.
2126 counter [ packets number bytes number ]
2128 CONNTRACK STATEMENT
2130 The conntrack statement can be used to set the conntrack mark and con‐
2131 ntrack labels.
2132 ct {mark | event | label | zone} set value
2134 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 Conntrack statement types
2142 ┌────────┬─────────────────────┬─────────────────────┐
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 ct mark set meta mark
2164 set zone mapped via interface
2166 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 restrict events reported by ctnetlink
2179 ct event set new,related,destroy
2181 META STATEMENT
2183 A meta statement sets the value of a meta expression. The existing
2184 meta fields are: priority, mark, pkttype, nftrace.
2185 meta {mark | priority | pkttype | nftrace} set value
2187 A meta statement sets meta data associated with a packet.
2189 Meta statement types
2191 ┌─────────┬─────────────────────┬───────────┐
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 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 limit statement values
2220 ┌──────────────┬───────────────────┬─────────────────────┐
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 The nat statements are only valid from nat chain types.
2242 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 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 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 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 NAT statement values
2267 ┌───────────┬─────────────────────┬─────────────────────┐
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 ┌─────────────┬────────────────────────────┐
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 # 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 # 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 # 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 # 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 # redirect incoming TCP traffic for port 22 to port 2222
2328 add rule nat prerouting tcp dport 22 redirect to :2222
2329 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 flow offload @flowtable
2336 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 queue [num queue_number] [bypass]
2345 queue [num queue_number_from - queue_number_to] [bypass,fanout]
2346 queue statement values
2348 ┌──────────────────┬─────────────────────┬─────────────────────┐
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 ┌───────┬────────────────────────────┐
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 dup to device
2384 dup to address device device
2385 Dup statement values
2387 ┌───────────┬─────────────────────┬─────────────────────┐
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 # 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 # copy raw frame to another interface
2410 netdetv ingress dup to "eth0"
2411 dup to "eth0"
2412 # combine with map dst addr to gateways
2414 dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" }
2415 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 fwd to device
2422 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 {add | update} @setname { expression [timeout timeout] [comment string]
2433 }
2434 Example for simple blacklist
2436 # 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 # whitelist internal interface.
2441 nft add rule ip filter input meta iifname "internal" accept
2442 # drop packets coming from blacklisted ip addresses.
2444 nft add rule ip filter input ip saddr @blackhole counter drop
2445 # 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 # inspect state of the rate limit meter:
2451 nft list meter ip filter flood
2452 # inspect content of blackhole:
2454 nft list set ip filter blackhole
2455 # 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 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 To filter events related to a concrete object, use one of the keywords
2469 'tables', 'chains', 'sets', 'rules', 'elements', 'ruleset'.
2470 To filter events related to a concrete action, use keyword 'new' or
2472 'destroy'.
2473 Hit ^C to finish the monitor operation.
2475 Listen to all events, report in native nft format
2477 % nft monitor
2479 Listen to added tables, report in XML format
2481 % nft monitor new tables xml
2483 Listen to deleted rules, report in JSON format
2485 % nft monitor destroy rules json
2487 Listen to both new and destroyed chains, in native nft format
2489 % nft monitor chains
2491 Listen to ruleset events such as table, chain, rule, set, counters and
2493 quotas, in native nft format
2494 % 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 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 Error caused by single incorrect expression
2508 <cmdline>:1:19-22: Error: Interface does not exist
2510 filter output oif eth0
2511 ^^^^
2512 Error caused by invalid combination of two expressions
2514 <cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
2516 filter output tcp dport == tcp dport
2517 ~~ ^^^^^^^^^
2518 Error returned by the kernel
2520 <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 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 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 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 17 February 2019 nft(8)