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