1NFT(8) NFT(8)
2
6 nft - Administration tool of the nftables framework for packet
7 filtering and classification
8
10 nft [ -nNscaeSupyj ] [ -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
16 packet filtering and classification rules in the Linux kernel, in the
17 nftables framework. The Linux kernel subsystem is known as nf_tables,
18 and ‘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 Print fully numerical output.
31 -s, --stateless
33 Omit stateful information of rules and stateful objects.
34 -N, --reversedns
36 Translate IP address to names via reverse DNS lookup. This may slow
37 down your listing since it generates network traffic.
38 -S, --service
40 Translate ports to service names as defined by /etc/services.
41 -u, --guid
43 Translate numeric UID/GID to names as defined by /etc/passwd and
44 /etc/group.
45 -p, --numeric-protocol
47 Display layer 4 protocol numerically.
48 -y, --numeric-priority
50 Display base chain priority numerically.
51 -c, --check
53 Check commands validity without actually applying the changes.
54 -a, --handle
56 Show object handles in output.
57 -e, --echo
59 When inserting items into the ruleset using add, insert or replace
60 commands, print notifications just like nft monitor.
61 -j, --json
63 Format output in JSON. See libnftables-json(5) for a schema
64 description.
65 -I, --includepath directory
67 Add the directory directory to the list of directories to be
68 searched for included files. This option may be specified multiple
69 times.
70 -f, --file filename
72 Read input from filename. If filename is -, read from stdin.
73 nft scripts must start #!/usr/sbin/nft -f
75 -i, --interactive
77 Read input from an interactive readline CLI. You can use quit to
78 exit, or use the EOF marker, normally this is CTRL-D.
79
81 LEXICAL CONVENTIONS
82 Input is parsed line-wise. When the last character of a line, just
83 before the newline character, is a non-quoted backslash (\), the next
84 line is treated as a continuation. Multiple commands on the same line
85 can be separated using a semicolon (;).
86 A hash sign (#) begins a comment. All following characters on the same
88 line are ignored.
89 Identifiers begin with an alphabetic character (a-z,A-Z), followed zero
91 or more alphanumeric characters (a-z,A-Z,0-9) and the characters slash
92 (/), backslash (\), underscore (_) and dot (.). Identifiers using
93 different characters or clashing with a keyword need to be enclosed in
94 double quotes (").
95 INCLUDE FILES
97 include filename
98 Other files can be included by using the include statement. The
100 directories to be searched for include files can be specified using the
101 -I/--includepath option. You can override this behaviour either by
102 prepending ‘./’ to your path to force inclusion of files located in the
103 current working directory (i.e. relative path) or / for file location
104 expressed as an absolute path.
105 If -I/--includepath is not specified, then nft relies on the default
107 directory that is specified at compile time. You can retrieve this
108 default directory via -h/--help option.
109 Include statements support the usual shell wildcard symbols (\*,?,[]).
111 Having no matches for an include statement is not an error, if wildcard
112 symbols are used in the include statement. This allows having
113 potentially empty include directories for statements like include
114 "/etc/firewall/rules/". The wildcard matches are loaded in alphabetical
115 order. Files beginning with dot (.) are not matched by include
116 statements.
117 SYMBOLIC VARIABLES
119 define variable = expr
120 $variable
121 Symbolic variables can be defined using the define statement. Variable
123 references are expressions and can be used initialize other variables.
124 The scope of a definition is the current block and all blocks contained
125 within.
126 Using symbolic variables.
128 define int_if1 = eth0
130 define int_if2 = eth1
131 define int_ifs = { $int_if1, $int_if2 }
132 filter input iif $int_ifs accept
134
137 Address families determine the type of packets which are processed. For
138 each address family, the kernel contains so called hooks at specific
139 stages of the packet processing paths, which invoke nftables if rules
140 for these hooks exist.
141 ip IPv4 address family.
144 ip6 IPv6 address family.
146 inet Internet (IPv4/IPv6)
148 address family.
149 arp ARP address family,
151 handling IPv4 ARP packets.
152 bridge Bridge address family,
154 handling packets which
155 traverse a bridge device.
156 netdev Netdev address family,
158 handling packets from
159 ingress.
160 All nftables objects exist in address family specific namespaces,
163 therefore all identifiers include an address family. If an identifier
164 is specified without an address family, the ip family is used by
165 default.
166 IPV4/IPV6/INET ADDRESS FAMILIES
168 The IPv4/IPv6/Inet address families handle IPv4, IPv6 or both types of
169 packets. They contain five hooks at different packet processing stages
170 in the network stack.
171 Table 1. IPv4/IPv6/Inet address family hooks
173 ┌────────────┬────────────────────────────┐
174 │Hook │ Description │
175 ├────────────┼────────────────────────────┤
176 │ │ │
177 │prerouting │ All packets entering the │
178 │ │ system are processed by │
179 │ │ the prerouting hook. It is │
180 │ │ invoked before the routing │
181 │ │ process and is used for │
182 │ │ early filtering or │
183 │ │ changing packet attributes │
184 │ │ that affect routing. │
185 ├────────────┼────────────────────────────┤
186 │ │ │
187 │input │ Packets delivered to the │
188 │ │ local system are processed │
189 │ │ by the input hook. │
190 ├────────────┼────────────────────────────┤
191 │ │ │
192 │forward │ Packets forwarded to a │
193 │ │ different host are │
194 │ │ processed by the forward │
195 │ │ hook. │
196 ├────────────┼────────────────────────────┤
197 │ │ │
198 │output │ Packets sent by local │
199 │ │ processes are processed by │
200 │ │ the output hook. │
201 ├────────────┼────────────────────────────┤
202 │ │ │
203 │postrouting │ All packets leaving the │
204 │ │ system are processed by │
205 │ │ the postrouting hook. │
206 └────────────┴────────────────────────────┘
207 ARP ADDRESS FAMILY
209 The ARP address family handles ARP packets received and sent by the
210 system. It is commonly used to mangle ARP packets for clustering.
211 Table 2. ARP address family hooks
213 ┌───────┬────────────────────────────┐
214 │Hook │ Description │
215 ├───────┼────────────────────────────┤
216 │ │ │
217 │input │ Packets delivered to the │
218 │ │ local system are processed │
219 │ │ by the input hook. │
220 ├───────┼────────────────────────────┤
221 │ │ │
222 │output │ Packets send by the local │
223 │ │ system are processed by │
224 │ │ the output hook. │
225 └───────┴────────────────────────────┘
226 BRIDGE ADDRESS FAMILY
228 The bridge address family handles Ethernet packets traversing bridge
229 devices.
230 The list of supported hooks is identical to IPv4/IPv6/Inet address
232 families above.
233 NETDEV ADDRESS FAMILY
235 The Netdev address family handles packets from ingress.
236 Table 3. Netdev address family hooks
238 ┌────────┬──────────────────────────┐
239 │Hook │ Description │
240 ├────────┼──────────────────────────┤
241 │ │ │
242 │ingress │ All packets entering the │
243 │ │ system are processed by │
244 │ │ this hook. It is invoked │
245 │ │ before layer 3 protocol │
246 │ │ handlers and it can be │
247 │ │ used for early filtering │
248 │ │ and policing. │
249 └────────┴──────────────────────────┘
250
252 {list | flush} ruleset [family]
253 The ruleset keyword is used to identify the whole set of tables,
255 chains, etc. currently in place in kernel. The following ruleset
256 commands exist:
257 list Print the ruleset in
260 human-readable format.
261 flush Clear the whole ruleset.
263 Note that, unlike
264 iptables, this will remove
265 all tables and whatever
266 they contain, effectively
267 leading to an empty
268 ruleset - no packet
269 filtering will happen
270 anymore, so the kernel
271 accepts any valid packet
272 it receives.
273 It is possible to limit list and flush to a specific address family
276 only. For a list of valid family names, see the section called “ADDRESS
277 FAMILIES” above.
278 By design, list ruleset command output may be used as input to nft -f.
280 Effectively, this is the nft-equivalent of iptables-save and
281 iptables-restore.
282
284 {add | create} table [family] table [{ flags flags ; }]
285 {delete | list | flush} table [family] table
286 list tables
287 delete table [family] handle handle
288 Tables are containers for chains, sets and stateful objects. They are
290 identified by their address family and their name. The address family
291 must be one of ip, ip6, inet, arp, bridge, netdev. The inet address
292 family is a dummy family which is used to create hybrid IPv4/IPv6
293 tables. The meta expression nfproto keyword can be used to test which
294 family (ipv4 or ipv6) context the packet is being processed in. When no
295 address family is specified, ip is used by default. The only difference
296 between add and create is that the former will not return an error if
297 the specified table already exists while create will return an error.
298 Table 4. Table flags
300 ┌────────┬────────────────────────────┐
301 │Flag │ Description │
302 ├────────┼────────────────────────────┤
303 │ │ │
304 │dormant │ table is not evaluated any │
305 │ │ more (base chains are │
306 │ │ unregistered). │
307 └────────┴────────────────────────────┘
308 Add, change, delete a table.
310 # start nft in interactive mode
312 nft --interactive
313 # create a new table.
315 create table inet mytable
316 # add a new base chain: get input packets
318 add chain inet mytable myin { type filter hook input priority 0; }
319 # add a single counter to the chain
321 add rule inet mytable myin counter
322 # disable the table temporarily -- rules are not evaluated anymore
324 add table inet mytable { flags dormant; }
325 # make table active again:
327 add table inet mytable
328 add Add a new table for the
332 given family with the
333 given name.
334 delete Delete the specified
336 table.
337 list List all chains and rules
339 of the specified table.
340 flush Flush all chains and rules
342 of the specified table.
343
346 {add | create} chain [family] table chain [{ type type hook hook [device device] priority priority ; [policy policy ;] }]
347 {delete | list | flush} chain [family] table chain
348 list chains
349 delete chain [family] table handle handle
350 rename chain [family] table chain newname
351 Chains are containers for rules. They exist in two kinds, base chains
353 and regular chains. A base chain is an entry point for packets from the
354 networking stack, a regular chain may be used as jump target and is
355 used for better rule organization.
356 add Add a new chain in the
360 specified table. When a
361 hook and priority value
362 are specified, the chain
363 is created as a base chain
364 and hooked up to the
365 networking stack.
366 create Similar to the add
368 command, but returns an
369 error if the chain already
370 exists.
371 delete Delete the specified
373 chain. The chain must not
374 contain any rules or be
375 used as jump target.
376 rename Rename the specified
378 chain.
379 list List all rules of the
381 specified chain.
382 flush Flush all rules of the
384 specified chain.
385 For base chains, type, hook and priority parameters are mandatory.
388 Table 5. Supported chain types
390 ┌───────┬───────────────┬────────────────┬──────────────────┐
391 │Type │ Families │ Hooks │ Description │
392 ├───────┼───────────────┼────────────────┼──────────────────┤
393 │ │ │ │ │
394 │filter │ all │ all │ Standard chain │
395 │ │ │ │ type to use in │
396 │ │ │ │ doubt. │
397 ├───────┼───────────────┼────────────────┼──────────────────┤
398 │ │ │ │ │
399 │nat │ ip, ip6, inet │ prerouting, │ Chains of this │
400 │ │ │ input, output, │ type perform │
401 │ │ │ postrouting │ Native Address │
402 │ │ │ │ Translation │
403 │ │ │ │ based on │
404 │ │ │ │ conntrack │
405 │ │ │ │ entries. Only │
406 │ │ │ │ the first packet │
407 │ │ │ │ of a connection │
408 │ │ │ │ actually │
409 │ │ │ │ traverses this │
410 │ │ │ │ chain - its │
411 │ │ │ │ rules usually │
412 │ │ │ │ define details │
413 │ │ │ │ of the created │
414 │ │ │ │ conntrack entry │
415 │ │ │ │ (NAT statements │
416 │ │ │ │ for instance). │
417 ├───────┼───────────────┼────────────────┼──────────────────┤
418 │ │ │ │ │
419 │route │ ip, ip6 │ output │ If a packet has │
420 │ │ │ │ traversed a │
421 │ │ │ │ chain of this │
422 │ │ │ │ type and is │
423 │ │ │ │ about to be │
424 │ │ │ │ accepted, a new │
425 │ │ │ │ route lookup is │
426 │ │ │ │ performed if │
427 │ │ │ │ relevant parts │
428 │ │ │ │ of the IP header │
429 │ │ │ │ have changed. │
430 │ │ │ │ This allows to │
431 │ │ │ │ e.g. implement │
432 │ │ │ │ policy routing │
433 │ │ │ │ selectors in │
434 │ │ │ │ nftables. │
435 └───────┴───────────────┴────────────────┴──────────────────┘
436 Apart from the special cases illustrated above (e.g. nat type not
438 supporting forward hook or route type only supporting output hook),
439 there are two further quirks worth noticing:
440 · The netdev family supports merely a single combination, namely
442 filter type and ingress hook. Base chains in this family also
443 require the device parameter to be present since they exist per
444 incoming interface only.
445 · The arp family supports only the input and output hooks, both in
447 chains of type filter.
448 The priority parameter accepts a signed integer value or a standard
450 priority name which specifies the order in which chains with same hook
451 value are traversed. The ordering is ascending, i.e. lower priority
452 values have precedence over higher ones.
453 Standard priority values can be replaced with easily memorizable names.
455 Not all names make sense in every family with every hook (see the
456 compatibility matrices below) but their numerical value can still be
457 used for prioritizing chains.
458 These names and values are defined and made available based on what
460 priorities are used by xtables when registering their default chains.
461 Most of the families use the same values, but bridge uses different
463 ones from the others. See the following tables that describe the values
464 and compatibility.
465 Table 6. Standard priority names, family and hook compatibility matrix
467 ┌─────────┬───────┬────────────────┬─────────────┐
468 │Name │ Value │ Families │ Hooks │
469 ├─────────┼───────┼────────────────┼─────────────┤
470 │ │ │ │ │
471 │raw │ -300 │ ip, ip6, inet │ all │
472 ├─────────┼───────┼────────────────┼─────────────┤
473 │ │ │ │ │
474 │mangle │ -150 │ ip, ip6, inet │ all │
475 ├─────────┼───────┼────────────────┼─────────────┤
476 │ │ │ │ │
477 │dstnat │ -100 │ ip, ip6, inet │ prerouting │
478 ├─────────┼───────┼────────────────┼─────────────┤
479 │ │ │ │ │
480 │filter │ 0 │ ip, ip6, inet, │ all │
481 │ │ │ arp, netdev │ │
482 ├─────────┼───────┼────────────────┼─────────────┤
483 │ │ │ │ │
484 │security │ 50 │ ip, ip6, inet │ all │
485 ├─────────┼───────┼────────────────┼─────────────┤
486 │ │ │ │ │
487 │srcnat │ 100 │ ip, ip6, inet │ postrouting │
488 └─────────┴───────┴────────────────┴─────────────┘
489 Table 7. Standard priority names and hook compatibility for the bridge
491 family
492 ┌───────┬───────┬─────────────┐
493 │ │ │ │
494 │Name │ Value │ Hooks │
495 ├───────┼───────┼─────────────┤
496 │ │ │ │
497 │dstnat │ -300 │ prerouting │
498 ├───────┼───────┼─────────────┤
499 │ │ │ │
500 │filter │ -200 │ all │
501 ├───────┼───────┼─────────────┤
502 │ │ │ │
503 │out │ 100 │ output │
504 ├───────┼───────┼─────────────┤
505 │ │ │ │
506 │srcnat │ 300 │ postrouting │
507 └───────┴───────┴─────────────┘
508 Basic arithmetic expressions (addition and subtraction) can also be
510 achieved with these standard names to ease relative prioritizing, e.g.
511 mangle - 5 stands for -155. Values will also be printed like this until
512 the value is not further than 10 form the standard value.
513 Base chains also allow to set the chain’s policy, i.e. what happens to
515 packets not explicitly accepted or refused in contained rules.
516 Supported policy values are accept (which is the default) or drop.
517
519 {add | insert} rule [family] table chain [handle handle | index index] statement ... [comment comment]
520 replace rule [family] table chain handle handle statement ... [comment comment]
521 delete rule [family] table chain handle handle
522 Rules are added to chains in the given table. If the family is not
524 specified, the ip family is used. Rules are constructed from two kinds
525 of components according to a set of grammatical rules: expressions and
526 statements.
527 The add and insert commands support an optional location specifier,
529 which is either a handle or the index (starting at zero) of an existing
530 rule. Internally, rule locations are always identified by handle and
531 the translation from index happens in userspace. This has two potential
532 implications in case a concurrent ruleset change happens after the
533 translation was done: The effective rule index might change if a rule
534 was inserted or deleted before the referred one. If the referred rule
535 was deleted, the command is rejected by the kernel just as if an
536 invalid handle was given.
537 A comment is a single word or a double-quoted (") multi-word string
539 which can be used to make notes regarding the actual rule. Note: If you
540 use bash for adding rules, you have to escape the quotation marks, e.g.
541 \"enable ssh for servers\".
542 add Add a new rule described
545 by the list of statements.
546 The rule is appended to
547 the given chain unless a
548 location is specified, in
549 which case the rule is
550 inserted after the
551 specified rule.
552 insert Same as add except the
554 rule is inserted at the
555 beginning of the chain or
556 before the specified rule.
557 replace Similar to add, but the
559 rule replaces the
560 specified rule.
561 delete Delete the specified rule.
563 add a rule to ip table input chain.
566 nft add rule filter output ip daddr 192.168.0.0/24 accept # 'ip filter' is assumed
568 # same command, slightly more verbose
569 nft add rule ip filter output ip daddr 192.168.0.0/24 accept
570 delete rule from inet table.
572 # nft -a list ruleset
574 table inet filter {
575 chain input {
576 type filter hook input priority 0; policy accept;
577 ct state established,related accept # handle 4
578 ip saddr 10.1.1.1 tcp dport ssh accept # handle 5
579 ...
580 # delete the rule with handle 5
581 # nft delete rule inet filter input handle 5
582
585 nftables offers two kinds of set concepts. Anonymous sets are sets that
586 have no specific name. The set members are enclosed in curly braces,
587 with commas to separate elements when creating the rule the set is used
588 in. Once that rule is removed, the set is removed as well. They cannot
589 be updated, i.e. once an anonymous set is declared it cannot be changed
590 anymore except by removing/altering the rule that uses the anonymous
591 set.
592 Using anonymous sets to accept particular subnets and ports.
594 nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept
596 Named sets are sets that need to be defined first before they can be
598 referenced in rules. Unlike anonymous sets, elements can be added to or
599 removed from a named set at any time. Sets are referenced from rules
600 using an @ prefixed to the sets name.
601 Using named sets to accept addresses and ports.
603 nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept
605 The sets allowed_hosts and allowed_ports need to be created first. The
607 next section describes nft set syntax in more detail.
608 add set [family] table set { type type ; [flags flags ;] [timeout timeout ;] [gc-interval gc-interval ;] [elements = { element[, ...] } ;] [size size ;] [policy policy ;] [auto-merge ;] }
610 {delete | list | flush} set [family] table set
611 list sets
612 delete set [family] table handle handle
613 {add | delete} element [family] table set { element[, ...] }
614 Sets are element containers of a user-defined data type, they are
616 uniquely identified by a user-defined name and attached to tables.
617 Their behaviour can be tuned with the flags that can be specified at
618 set creation time.
619 add Add a new set in the
622 specified table. See the
623 Set specification table
624 below for more information
625 about how to specify a
626 sets properties.
627 delete Delete the specified set.
629 list Display the elements in
631 the specified set.
632 flush Remove all elements from
634 the specified set.
635 add element Comma-separated list of
637 elements to add into the
638 specified set.
639 delete element Comma-separated list of
641 elements to delete from
642 the specified set.
643 Table 8. Set specifications
646 ┌────────────┬──────────────────────┬─────────────────────┐
647 │Keyword │ Description │ Type │
648 ├────────────┼──────────────────────┼─────────────────────┤
649 │ │ │ │
650 │type │ data type of set │ string: ipv4_addr, │
651 │ │ elements │ ipv6_addr, │
652 │ │ │ ether_addr, │
653 │ │ │ inet_proto, │
654 │ │ │ inet_service, mark │
655 ├────────────┼──────────────────────┼─────────────────────┤
656 │ │ │ │
657 │flags │ set flags │ string: constant, │
658 │ │ │ dynamic, interval, │
659 │ │ │ timeout │
660 ├────────────┼──────────────────────┼─────────────────────┤
661 │ │ │ │
662 │timeout │ time an element │ string, decimal │
663 │ │ stays in the set, │ followed by unit. │
664 │ │ mandatory if set is │ Units are: d, h, m, │
665 │ │ added to from the │ s │
666 │ │ packet path │ │
667 │ │ (ruleset). │ │
668 ├────────────┼──────────────────────┼─────────────────────┤
669 │ │ │ │
670 │gc-interval │ garbage collection │ string, decimal │
671 │ │ interval, only │ followed by unit. │
672 │ │ available when │ Units are: d, h, m, │
673 │ │ timeout or flag │ s │
674 │ │ timeout are active │ │
675 ├────────────┼──────────────────────┼─────────────────────┤
676 │ │ │ │
677 │elements │ elements contained │ set data type │
678 │ │ by the set │ │
679 ├────────────┼──────────────────────┼─────────────────────┤
680 │ │ │ │
681 │size │ maximum number of │ unsigned integer │
682 │ │ elements in the │ (64 bit) │
683 │ │ set, mandatory if │ │
684 │ │ set is added to │ │
685 │ │ from the packet │ │
686 │ │ path (ruleset). │ │
687 ├────────────┼──────────────────────┼─────────────────────┤
688 │ │ │ │
689 │policy │ set policy │ string: performance │
690 │ │ │ [default], memory │
691 ├────────────┼──────────────────────┼─────────────────────┤
692 │ │ │ │
693 │auto-merge │ automatic merge of │ │
694 │ │ adjacent/overlapping │ │
695 │ │ set elements (only │ │
696 │ │ for interval sets) │ │
697 └────────────┴──────────────────────┴─────────────────────┘
698
700 add map [family] table map { type type [flags flags ;] [elements = { element[, ...] } ;] [size size ;] [policy policy ;] }
701 {delete | list | flush} map [family] table map
702 list maps
703 {add | delete} element [family] table map { elements = { element[, ...] } ; }
704 Maps store data based on some specific key used as input. They are
706 uniquely identified by a user-defined name and attached to tables.
707 add Add a new map in the
710 specified table.
711 delete Delete the specified map.
713 list Display the elements in
715 the specified map.
716 flush Remove all elements from
718 the specified map.
719 add element Comma-separated list of
721 elements to add into the
722 specified map.
723 delete element Comma-separated list of
725 element keys to delete
726 from the specified map.
727 Table 9. Map specifications
730 ┌─────────┬─────────────────────┬─────────────────────┐
731 │Keyword │ Description │ Type │
732 ├─────────┼─────────────────────┼─────────────────────┤
733 │ │ │ │
734 │type │ data type of map │ string ‘:’ string: │
735 │ │ elements │ ipv4_addr, │
736 │ │ │ ipv6_addr, │
737 │ │ │ ether_addr, │
738 │ │ │ inet_proto, │
739 │ │ │ inet_service, mark, │
740 │ │ │ counter, quota. │
741 │ │ │ Counter and quota │
742 │ │ │ can’t be used as │
743 │ │ │ keys │
744 ├─────────┼─────────────────────┼─────────────────────┤
745 │ │ │ │
746 │flags │ map flags │ string: constant, │
747 │ │ │ interval │
748 ├─────────┼─────────────────────┼─────────────────────┤
749 │ │ │ │
750 │elements │ elements contained │ map data type │
751 │ │ by the map │ │
752 ├─────────┼─────────────────────┼─────────────────────┤
753 │ │ │ │
754 │size │ maximum number of │ unsigned integer │
755 │ │ elements in the map │ (64 bit) │
756 ├─────────┼─────────────────────┼─────────────────────┤
757 │ │ │ │
758 │policy │ map policy │ string: performance │
759 │ │ │ [default], memory │
760 └─────────┴─────────────────────┴─────────────────────┘
761
763 {add | create} flowtable [family] table flowtable { hook hook priority priority ; devices = { device[, ...] } ; }
764 {delete | list} flowtable [family] table flowtable
765 Flowtables allow you to accelerate packet forwarding in software.
767 Flowtables entries are represented through a tuple that is composed of
768 the input interface, source and destination address, source and
769 destination port; and layer 3/4 protocols. Each entry also caches the
770 destination interface and the gateway address - to update the
771 destination link-layer address - to forward packets. The ttl and
772 hoplimit fields are also decremented. Hence, flowtables provides an
773 alternative path that allow packets to bypass the classic forwarding
774 path. Flowtables reside in the ingress hook that is located before the
775 prerouting hook. You can select which flows you want to offload through
776 the flow expression from the forward chain. Flowtables are identified
777 by their address family and their name. The address family must be one
778 of ip, ip6, or inet. The inet address family is a dummy family which is
779 used to create hybrid IPv4/IPv6 tables. When no address family is
780 specified, ip is used by default.
781 The priority can be a signed integer or filter which stands for 0.
783 Addition and subtraction can be used to set relative priority, e.g.
784 filter + 5 equals to 5.
785 add Add a new flowtable for
788 the given family with the
789 given name.
790 delete Delete the specified
792 flowtable.
793 list List all flowtables.
795
798 {add | delete | list | reset} type [family] table object
799 delete type [family] table handle handle
800 list counters
801 list quotas
802 Stateful objects are attached to tables and are identified by an unique
804 name. They group stateful information from rules, to reference them in
805 rules the keywords "type name" are used e.g. "counter name".
806 add Add a new stateful object
809 in the specified table.
810 delete Delete the specified
812 object.
813 list Display stateful
815 information the object
816 holds.
817 reset List-and-reset stateful
819 object.
820 CT HELPER
823 ct helper helper { type type protocol protocol ; [l3proto family ;] }
824 Ct helper is used to define connection tracking helpers that can then
826 be used in combination with the ct helper set statement. type and
827 protocol are mandatory, l3proto is derived from the table family by
828 default, i.e. in the inet table the kernel will try to load both the
829 ipv4 and ipv6 helper backends, if they are supported by the kernel.
830 Table 10. conntrack helper specifications
832 ┌─────────┬─────────────────────┬─────────────────────┐
833 │Keyword │ Description │ Type │
834 ├─────────┼─────────────────────┼─────────────────────┤
835 │ │ │ │
836 │type │ name of helper type │ quoted string (e.g. │
837 │ │ │ "ftp") │
838 ├─────────┼─────────────────────┼─────────────────────┤
839 │ │ │ │
840 │protocol │ layer 4 protocol of │ string (e.g. ip) │
841 │ │ the helper │ │
842 ├─────────┼─────────────────────┼─────────────────────┤
843 │ │ │ │
844 │l3proto │ layer 3 protocol of │ address family │
845 │ │ the helper │ (e.g. ip) │
846 └─────────┴─────────────────────┴─────────────────────┘
847 defining and assigning ftp helper.
849 Unlike iptables, helper assignment needs to be performed after the conntrack
851 lookup has completed, for example with the default 0 hook priority.
852 table inet myhelpers {
854 ct helper ftp-standard {
855 type "ftp" protocol tcp
856 }
857 chain prerouting {
858 type filter hook prerouting priority 0;
859 tcp dport 21 ct helper set "ftp-standard"
860 }
861 }
862 CT TIMEOUT
865 ct timeout name { protocol protocol ; policy = { state: value [, ...] } ; [l3proto family ;] }
866 Ct timeout is used to update connection tracking timeout values.Timeout
868 policies are assigned with the ct timeout set statement. protocol and
869 policy are mandatory, l3proto is derived from the table family by
870 default.
871 Table 11. conntrack timeout specifications
873 ┌─────────┬─────────────────────┬──────────────────┐
874 │Keyword │ Description │ Type │
875 ├─────────┼─────────────────────┼──────────────────┤
876 │ │ │ │
877 │protocol │ layer 4 protocol of │ string (e.g. ip) │
878 │ │ the timeout object │ │
879 ├─────────┼─────────────────────┼──────────────────┤
880 │ │ │ │
881 │state │ connection state │ string (e.g. │
882 │ │ name │ "established") │
883 ├─────────┼─────────────────────┼──────────────────┤
884 │ │ │ │
885 │value │ timeout value for │ unsigned integer │
886 │ │ connection state │ │
887 ├─────────┼─────────────────────┼──────────────────┤
888 │ │ │ │
889 │l3proto │ layer 3 protocol of │ address family │
890 │ │ the timeout object │ (e.g. ip) │
891 └─────────┴─────────────────────┴──────────────────┘
892 defining and assigning ct timeout policy.
894 table ip filter {
896 ct timeout customtimeout {
897 protocol tcp;
898 l3proto ip
899 policy = { established: 120, close: 20 }
900 }
901 chain output {
903 type filter hook output priority filter; policy accept;
904 ct timeout set "customtimeout"
905 }
906 }
907 testing the updated timeout policy.
909 % conntrack -E
911 It should display:
913 [UPDATE] tcp 6 120 ESTABLISHED src=172.16.19.128 dst=172.16.19.1
915 sport=22 dport=41360 [UNREPLIED] src=172.16.19.1 dst=172.16.19.128
916 sport=41360 dport=22
917 COUNTER
920 counter [packets bytes]
921 Table 12. Counter specifications
923 ┌────────┬──────────────────┬──────────────────┐
924 │Keyword │ Description │ Type │
925 ├────────┼──────────────────┼──────────────────┤
926 │ │ │ │
927 │packets │ initial count of │ unsigned integer │
928 │ │ packets │ (64 bit) │
929 ├────────┼──────────────────┼──────────────────┤
930 │ │ │ │
931 │bytes │ initial count of │ unsigned integer │
932 │ │ bytes │ (64 bit) │
933 └────────┴──────────────────┴──────────────────┘
934 QUOTA
936 quota [over | until] [used]
937 Table 13. Quota specifications
939 ┌────────┬───────────────────┬────────────────────┐
940 │Keyword │ Description │ Type │
941 ├────────┼───────────────────┼────────────────────┤
942 │ │ │ │
943 │quota │ quota limit, used │ Two arguments, │
944 │ │ as the quota name │ unsigned integer │
945 │ │ │ (64 bit) and │
946 │ │ │ string: bytes, │
947 │ │ │ kbytes, mbytes. │
948 │ │ │ "over" and "until" │
949 │ │ │ go before these │
950 │ │ │ arguments │
951 ├────────┼───────────────────┼────────────────────┤
952 │ │ │ │
953 │used │ initial value of │ Two arguments, │
954 │ │ used quota │ unsigned integer │
955 │ │ │ (64 bit) and │
956 │ │ │ string: bytes, │
957 │ │ │ kbytes, mbytes │
958 └────────┴───────────────────┴────────────────────┘
959
961 Expressions represent values, either constants like network addresses,
962 port numbers, etc., or data gathered from the packet during ruleset
963 evaluation. Expressions can be combined using binary, logical,
964 relational and other types of expressions to form complex or relational
965 (match) expressions. They are also used as arguments to certain types
966 of operations, like NAT, packet marking etc.
967 Each expression has a data type, which determines the size, parsing and
969 representation of symbolic values and type compatibility with other
970 expressions.
971 DESCRIBE COMMAND
973 describe expression
974 The describe command shows information about the type of an expression
976 and its data type.
977 The describe command.
979 $ nft describe tcp flags
981 payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits
982 predefined symbolic constants:
984 fin 0x01
985 syn 0x02
986 rst 0x04
987 psh 0x08
988 ack 0x10
989 urg 0x20
990 ecn 0x40
991 cwr 0x80
992
995 Data types determine the size, parsing and representation of symbolic
996 values and type compatibility of expressions. A number of global data
997 types exist, in addition some expression types define further data
998 types specific to the expression type. Most data types have a fixed
999 size, some however may have a dynamic size, f.i. the string type.
1000 Types may be derived from lower order types, f.i. the IPv4 address type
1002 is derived from the integer type, meaning an IPv4 address can also be
1003 specified as an integer value.
1004 In certain contexts (set and map definitions), it is necessary to
1006 explicitly specify a data type. Each type has a name which is used for
1007 this.
1008 INTEGER TYPE
1010 ┌────────┬─────────┬──────────┬───────────┐
1011 │Name │ Keyword │ Size │ Base type │
1012 ├────────┼─────────┼──────────┼───────────┤
1013 │ │ │ │ │
1014 │Integer │ integer │ variable │ - │
1015 └────────┴─────────┴──────────┴───────────┘
1016 The integer type is used for numeric values. It may be specified as a
1018 decimal, hexadecimal or octal number. The integer type does not have a
1019 fixed size, its size is determined by the expression for which it is
1020 used.
1021 BITMASK TYPE
1023 ┌────────┬─────────┬──────────┬───────────┐
1024 │Name │ Keyword │ Size │ Base type │
1025 ├────────┼─────────┼──────────┼───────────┤
1026 │ │ │ │ │
1027 │Bitmask │ bitmask │ variable │ integer │
1028 └────────┴─────────┴──────────┴───────────┘
1029 The bitmask type (bitmask) is used for bitmasks.
1031 STRING TYPE
1033 ┌───────┬─────────┬──────────┬───────────┐
1034 │Name │ Keyword │ Size │ Base type │
1035 ├───────┼─────────┼──────────┼───────────┤
1036 │ │ │ │ │
1037 │String │ string │ variable │ - │
1038 └───────┴─────────┴──────────┴───────────┘
1039 The string type is used for character strings. A string begins with an
1041 alphabetic character (a-zA-Z) followed by zero or more alphanumeric
1042 characters or the characters /, -, _ and .. In addition, anything
1043 enclosed in double quotes (") is recognized as a string.
1044 String specification.
1046 # Interface name
1048 filter input iifname eth0
1049 # Weird interface name
1051 filter input iifname "(eth0)"
1052 LINK LAYER ADDRESS TYPE
1055 ┌───────────┬─────────┬──────────┬───────────┐
1056 │Name │ Keyword │ Size │ Base type │
1057 ├───────────┼─────────┼──────────┼───────────┤
1058 │ │ │ │ │
1059 │Link layer │ lladdr │ variable │ integer │
1060 │address │ │ │ │
1061 └───────────┴─────────┴──────────┴───────────┘
1062 The link layer address type is used for link layer addresses. Link
1064 layer addresses are specified as a variable amount of groups of two
1065 hexadecimal digits separated using colons (:).
1066 Link layer address specification.
1068 # Ethernet destination MAC address
1070 filter input ether daddr 20:c9:d0:43:12:d9
1071 IPV4 ADDRESS TYPE
1074 ┌─────────────┬───────────┬────────┬───────────┐
1075 │Name │ Keyword │ Size │ Base type │
1076 ├─────────────┼───────────┼────────┼───────────┤
1077 │ │ │ │ │
1078 │IPV4 address │ ipv4_addr │ 32 bit │ integer │
1079 └─────────────┴───────────┴────────┴───────────┘
1080 The IPv4 address type is used for IPv4 addresses. Addresses are
1082 specified in either dotted decimal, dotted hexadecimal, dotted octal,
1083 decimal, hexadecimal, octal notation or as a host name. A host name
1084 will be resolved using the standard system resolver.
1085 IPv4 address specification.
1087 # dotted decimal notation
1089 filter output ip daddr 127.0.0.1
1090 # host name
1092 filter output ip daddr localhost
1093 IPV6 ADDRESS TYPE
1096 ┌─────────────┬───────────┬─────────┬───────────┐
1097 │Name │ Keyword │ Size │ Base type │
1098 ├─────────────┼───────────┼─────────┼───────────┤
1099 │ │ │ │ │
1100 │IPv6 address │ ipv6_addr │ 128 bit │ integer │
1101 └─────────────┴───────────┴─────────┴───────────┘
1102 The IPv6 address type is used for IPv6 addresses. Addresses are
1104 specified as a host name or as hexadecimal halfwords separated by
1105 colons. Addresses might be enclosed in square brackets ("[]") to
1106 differentiate them from port numbers.
1107 IPv6 address specification.
1109 # abbreviated loopback address
1111 filter output ip6 daddr ::1
1112 IPv6 address specification with bracket notation.
1114 # without [] the port number (22) would be parsed as part of the
1116 # ipv6 address
1117 ip6 nat prerouting tcp dport 2222 dnat to [1ce::d0]:22
1118 BOOLEAN TYPE
1121 ┌────────┬─────────┬───────┬───────────┐
1122 │Name │ Keyword │ Size │ Base type │
1123 ├────────┼─────────┼───────┼───────────┤
1124 │ │ │ │ │
1125 │Boolean │ boolean │ 1 bit │ integer │
1126 └────────┴─────────┴───────┴───────────┘
1127 The boolean type is a syntactical helper type in userspace. Its use is
1129 in the right-hand side of a (typically implicit) relational expression
1130 to change the expression on the left-hand side into a boolean check
1131 (usually for existence).
1132 Table 14. The following keywords will automatically resolve into a
1134 boolean type with given value
1135 ┌────────┬───────┐
1136 │Keyword │ Value │
1137 ├────────┼───────┤
1138 │ │ │
1139 │exists │ 1 │
1140 ├────────┼───────┤
1141 │ │ │
1142 │missing │ 0 │
1143 └────────┴───────┘
1144 Table 15. expressions support a boolean comparison
1146 ┌───────────┬─────────────────────────┐
1147 │Expression │ Behaviour │
1148 ├───────────┼─────────────────────────┤
1149 │ │ │
1150 │fib │ Check route existence. │
1151 ├───────────┼─────────────────────────┤
1152 │ │ │
1153 │exthdr │ Check IPv6 extension │
1154 │ │ header existence. │
1155 ├───────────┼─────────────────────────┤
1156 │ │ │
1157 │tcp option │ Check TCP option header │
1158 │ │ existence. │
1159 └───────────┴─────────────────────────┘
1160 Boolean specification.
1162 # match if route exists
1164 filter input fib daddr . iif oif exists
1165 # match only non-fragmented packets in IPv6 traffic
1167 filter input exthdr frag missing
1168 # match if TCP timestamp option is present
1170 filter input tcp option timestamp exists
1171 ICMP TYPE TYPE
1174 ┌──────────┬───────────┬───────┬───────────┐
1175 │Name │ Keyword │ Size │ Base type │
1176 ├──────────┼───────────┼───────┼───────────┤
1177 │ │ │ │ │
1178 │ICMP Type │ icmp_type │ 8 bit │ integer │
1179 └──────────┴───────────┴───────┴───────────┘
1180 The ICMP Type type is used to conveniently specify the ICMP header’s
1182 type field.
1183 Table 16. Keywords may be used when specifying the ICMP type
1185 ┌────────────────────────┬───────┐
1186 │Keyword │ Value │
1187 ├────────────────────────┼───────┤
1188 │ │ │
1189 │echo-reply │ 0 │
1190 ├────────────────────────┼───────┤
1191 │ │ │
1192 │destination-unreachable │ 3 │
1193 ├────────────────────────┼───────┤
1194 │ │ │
1195 │source-quench │ 4 │
1196 ├────────────────────────┼───────┤
1197 │ │ │
1198 │redirect │ 5 │
1199 ├────────────────────────┼───────┤
1200 │ │ │
1201 │echo-request │ 8 │
1202 ├────────────────────────┼───────┤
1203 │ │ │
1204 │router-advertisement │ 9 │
1205 ├────────────────────────┼───────┤
1206 │ │ │
1207 │router-solicitation │ 10 │
1208 ├────────────────────────┼───────┤
1209 │ │ │
1210 │time-exceeded │ 11 │
1211 ├────────────────────────┼───────┤
1212 │ │ │
1213 │parameter-problem │ 12 │
1214 ├────────────────────────┼───────┤
1215 │ │ │
1216 │timestamp-request │ 13 │
1217 ├────────────────────────┼───────┤
1218 │ │ │
1219 │timestamp-reply │ 14 │
1220 ├────────────────────────┼───────┤
1221 │ │ │
1222 │info-request │ 15 │
1223 ├────────────────────────┼───────┤
1224 │ │ │
1225 │info-reply │ 16 │
1226 ├────────────────────────┼───────┤
1227 │ │ │
1228 │address-mask-request │ 17 │
1229 ├────────────────────────┼───────┤
1230 │ │ │
1231 │address-mask-reply │ 18 │
1232 └────────────────────────┴───────┘
1233 ICMP Type specification.
1235 # match ping packets
1237 filter output icmp type { echo-request, echo-reply }
1238 ICMP CODE TYPE
1241 ┌──────────┬───────────┬───────┬───────────┐
1242 │Name │ Keyword │ Size │ Base type │
1243 ├──────────┼───────────┼───────┼───────────┤
1244 │ │ │ │ │
1245 │ICMP Code │ icmp_code │ 8 bit │ integer │
1246 └──────────┴───────────┴───────┴───────────┘
1247 The ICMP Code type is used to conveniently specify the ICMP header’s
1249 code field.
1250 Table 17. Keywords may be used when specifying the ICMP code
1252 ┌─────────────────┬───────┐
1253 │Keyword │ Value │
1254 ├─────────────────┼───────┤
1255 │ │ │
1256 │net-unreachable │ 0 │
1257 ├─────────────────┼───────┤
1258 │ │ │
1259 │host-unreachable │ 1 │
1260 ├─────────────────┼───────┤
1261 │ │ │
1262 │prot-unreachable │ 2 │
1263 ├─────────────────┼───────┤
1264 │ │ │
1265 │port-unreachable │ 3 │
1266 ├─────────────────┼───────┤
1267 │ │ │
1268 │net-prohibited │ 9 │
1269 ├─────────────────┼───────┤
1270 │ │ │
1271 │host-prohibited │ 10 │
1272 ├─────────────────┼───────┤
1273 │ │ │
1274 │admin-prohibited │ 13 │
1275 └─────────────────┴───────┘
1276 ICMPV6 TYPE TYPE
1278 ┌────────────┬────────────┬───────┬───────────┐
1279 │Name │ Keyword │ Size │ Base type │
1280 ├────────────┼────────────┼───────┼───────────┤
1281 │ │ │ │ │
1282 │ICMPv6 Type │ icmpx_code │ 8 bit │ integer │
1283 └────────────┴────────────┴───────┴───────────┘
1284 The ICMPv6 Type type is used to conveniently specify the ICMPv6
1286 header’s type field.
1287 Table 18. keywords may be used when specifying the ICMPv6 type:
1289 ┌────────────────────────┬───────┐
1290 │Keyword │ Value │
1291 ├────────────────────────┼───────┤
1292 │ │ │
1293 │destination-unreachable │ 1 │
1294 ├────────────────────────┼───────┤
1295 │ │ │
1296 │packet-too-big │ 2 │
1297 ├────────────────────────┼───────┤
1298 │ │ │
1299 │time-exceeded │ 3 │
1300 ├────────────────────────┼───────┤
1301 │ │ │
1302 │parameter-problem │ 4 │
1303 ├────────────────────────┼───────┤
1304 │ │ │
1305 │echo-request │ 128 │
1306 ├────────────────────────┼───────┤
1307 │ │ │
1308 │echo-reply │ 129 │
1309 ├────────────────────────┼───────┤
1310 │ │ │
1311 │mld-listener-query │ 130 │
1312 ├────────────────────────┼───────┤
1313 │ │ │
1314 │mld-listener-report │ 131 │
1315 ├────────────────────────┼───────┤
1316 │ │ │
1317 │mld-listener-done │ 132 │
1318 ├────────────────────────┼───────┤
1319 │ │ │
1320 │mld-listener-reduction │ 132 │
1321 ├────────────────────────┼───────┤
1322 │ │ │
1323 │nd-router-solicit │ 133 │
1324 ├────────────────────────┼───────┤
1325 │ │ │
1326 │nd-router-advert │ 134 │
1327 ├────────────────────────┼───────┤
1328 │ │ │
1329 │nd-neighbor-solicit │ 135 │
1330 ├────────────────────────┼───────┤
1331 │ │ │
1332 │nd-neighbor-advert │ 136 │
1333 ├────────────────────────┼───────┤
1334 │ │ │
1335 │nd-redirect │ 137 │
1336 ├────────────────────────┼───────┤
1337 │ │ │
1338 │router-renumbering │ 138 │
1339 ├────────────────────────┼───────┤
1340 │ │ │
1341 │ind-neighbor-solicit │ 141 │
1342 ├────────────────────────┼───────┤
1343 │ │ │
1344 │ind-neighbor-advert │ 142 │
1345 ├────────────────────────┼───────┤
1346 │ │ │
1347 │mld2-listener-report │ 143 │
1348 └────────────────────────┴───────┘
1349 ICMPv6 Type specification.
1351 # match ICMPv6 ping packets
1353 filter output icmpv6 type { echo-request, echo-reply }
1354 ICMPV6 CODE TYPE
1357 ┌────────────┬─────────────┬───────┬───────────┐
1358 │Name │ Keyword │ Size │ Base type │
1359 ├────────────┼─────────────┼───────┼───────────┤
1360 │ │ │ │ │
1361 │ICMPv6 Code │ icmpv6_code │ 8 bit │ integer │
1362 └────────────┴─────────────┴───────┴───────────┘
1363 The ICMPv6 Code type is used to conveniently specify the ICMPv6
1365 header’s code field.
1366 Table 19. keywords may be used when specifying the ICMPv6 code
1368 ┌─────────────────┬───────┐
1369 │Keyword │ Value │
1370 ├─────────────────┼───────┤
1371 │ │ │
1372 │no-route │ 0 │
1373 ├─────────────────┼───────┤
1374 │ │ │
1375 │admin-prohibited │ 1 │
1376 ├─────────────────┼───────┤
1377 │ │ │
1378 │addr-unreachable │ 3 │
1379 ├─────────────────┼───────┤
1380 │ │ │
1381 │port-unreachable │ 4 │
1382 ├─────────────────┼───────┤
1383 │ │ │
1384 │policy-fail │ 5 │
1385 ├─────────────────┼───────┤
1386 │ │ │
1387 │reject-route │ 6 │
1388 └─────────────────┴───────┘
1389 ICMPVX CODE TYPE
1391 ┌────────────┬─────────────┬───────┬───────────┐
1392 │Name │ Keyword │ Size │ Base type │
1393 ├────────────┼─────────────┼───────┼───────────┤
1394 │ │ │ │ │
1395 │ICMPvX Code │ icmpv6_type │ 8 bit │ integer │
1396 └────────────┴─────────────┴───────┴───────────┘
1397 The ICMPvX Code type abstraction is a set of values which overlap
1399 between ICMP and ICMPv6 Code types to be used from the inet family.
1400 Table 20. keywords may be used when specifying the ICMPvX code
1402 ┌─────────────────┬───────┐
1403 │Keyword │ Value │
1404 ├─────────────────┼───────┤
1405 │ │ │
1406 │no-route │ 0 │
1407 ├─────────────────┼───────┤
1408 │ │ │
1409 │port-unreachable │ 1 │
1410 ├─────────────────┼───────┤
1411 │ │ │
1412 │host-unreachable │ 2 │
1413 ├─────────────────┼───────┤
1414 │ │ │
1415 │admin-prohibited │ 3 │
1416 └─────────────────┴───────┘
1417 CONNTRACK TYPES
1419 Table 21. overview of types used in ct expression and statement
1420 ┌─────────────────┬───────────┬─────────┬───────────┐
1421 │Name │ Keyword │ Size │ Base type │
1422 ├─────────────────┼───────────┼─────────┼───────────┤
1423 │ │ │ │ │
1424 │conntrack state │ ct_state │ 4 byte │ bitmask │
1425 ├─────────────────┼───────────┼─────────┼───────────┤
1426 │ │ │ │ │
1427 │conntrack │ ct_dir │ 8 bit │ integer │
1428 │direction │ │ │ │
1429 ├─────────────────┼───────────┼─────────┼───────────┤
1430 │ │ │ │ │
1431 │conntrack status │ ct_status │ 4 byte │ bitmask │
1432 ├─────────────────┼───────────┼─────────┼───────────┤
1433 │ │ │ │ │
1434 │conntrack event │ ct_event │ 4 byte │ bitmask │
1435 │bits │ │ │ │
1436 ├─────────────────┼───────────┼─────────┼───────────┤
1437 │ │ │ │ │
1438 │conntrack label │ ct_label │ 128 bit │ bitmask │
1439 └─────────────────┴───────────┴─────────┴───────────┘
1440 For each of the types above, keywords are available for convenience:
1442 Table 22. conntrack state (ct_state)
1444 ┌────────────┬───────┐
1445 │Keyword │ Value │
1446 ├────────────┼───────┤
1447 │ │ │
1448 │invalid │ 1 │
1449 ├────────────┼───────┤
1450 │ │ │
1451 │established │ 2 │
1452 ├────────────┼───────┤
1453 │ │ │
1454 │related │ 4 │
1455 ├────────────┼───────┤
1456 │ │ │
1457 │new │ 8 │
1458 ├────────────┼───────┤
1459 │ │ │
1460 │untracked │ 64 │
1461 └────────────┴───────┘
1462 Table 23. conntrack direction (ct_dir)
1464 ┌─────────┬───────┐
1465 │Keyword │ Value │
1466 ├─────────┼───────┤
1467 │ │ │
1468 │original │ 0 │
1469 ├─────────┼───────┤
1470 │ │ │
1471 │reply │ 1 │
1472 └─────────┴───────┘
1473 Table 24. conntrack status (ct_status)
1475 ┌───────────┬───────┐
1476 │Keyword │ Value │
1477 ├───────────┼───────┤
1478 │ │ │
1479 │expected │ 1 │
1480 ├───────────┼───────┤
1481 │ │ │
1482 │seen-reply │ 2 │
1483 ├───────────┼───────┤
1484 │ │ │
1485 │assured │ 4 │
1486 ├───────────┼───────┤
1487 │ │ │
1488 │confirmed │ 8 │
1489 ├───────────┼───────┤
1490 │ │ │
1491 │snat │ 16 │
1492 ├───────────┼───────┤
1493 │ │ │
1494 │dnat │ 32 │
1495 ├───────────┼───────┤
1496 │ │ │
1497 │dying │ 512 │
1498 └───────────┴───────┘
1499 Table 25. conntrack event bits (ct_event)
1501 ┌──────────┬───────┐
1502 │Keyword │ Value │
1503 ├──────────┼───────┤
1504 │ │ │
1505 │new │ 1 │
1506 ├──────────┼───────┤
1507 │ │ │
1508 │related │ 2 │
1509 ├──────────┼───────┤
1510 │ │ │
1511 │destroy │ 4 │
1512 ├──────────┼───────┤
1513 │ │ │
1514 │reply │ 8 │
1515 ├──────────┼───────┤
1516 │ │ │
1517 │assured │ 16 │
1518 ├──────────┼───────┤
1519 │ │ │
1520 │protoinfo │ 32 │
1521 ├──────────┼───────┤
1522 │ │ │
1523 │helper │ 64 │
1524 ├──────────┼───────┤
1525 │ │ │
1526 │mark │ 128 │
1527 ├──────────┼───────┤
1528 │ │ │
1529 │seqadj │ 256 │
1530 ├──────────┼───────┤
1531 │ │ │
1532 │secmark │ 512 │
1533 ├──────────┼───────┤
1534 │ │ │
1535 │label │ 1024 │
1536 └──────────┴───────┘
1537 Possible keywords for conntrack label type (ct_label) are read at
1539 runtime from /etc/connlabel.conf.
1540
1542 The lowest order expression is a primary expression, representing
1543 either a constant or a single datum from a packet’s payload, meta data
1544 or a stateful module.
1545 META EXPRESSIONS
1547 meta {length | nfproto | l4proto | protocol | priority}
1548 [meta] {mark | iif | iifname | iiftype | oif | oifname | oiftype | skuid | skgid | nftrace | rtclassid | ibrname | obrname | pkttype | cpu | iifgroup | oifgroup | cgroup | random | ipsec | iifkind | oifkind}
1549 A meta expression refers to meta data associated with a packet.
1551 There are two types of meta expressions: unqualified and qualified meta
1553 expressions. Qualified meta expressions require the meta keyword before
1554 the meta key, unqualified meta expressions can be specified by using
1555 the meta key directly or as qualified meta expressions. Meta l4proto is
1556 useful to match a particular transport protocol that is part of either
1557 an IPv4 or IPv6 packet. It will also skip any IPv6 extension headers
1558 present in an IPv6 packet.
1559 meta iif, oif, iifname and oifname are used to match the interface a
1561 packet arrived on or is about to be sent out on.
1562 iif and oif are used to match on the interface index, whereas iifname
1564 and oifname are used to match on the interface name. This is not the
1565 same — assuming the rule
1566 filter input meta iif "foo"
1568 Then this rule can only be added if the interface "foo" exists. Also,
1570 the rule will continue to match even if the interface "foo" is renamed
1571 to "bar".
1572 This is because internally the interface index is used. In case of
1574 dynamically created interfaces, such as tun/tap or dialup interfaces
1575 (ppp for example), it might be better to use iifname or oifname
1576 instead.
1577 In these cases, the name is used so the interface doesn’t have to exist
1579 to add such a rule, it will stop matching if the interface gets renamed
1580 and it will match again in case interface gets deleted and later a new
1581 interface with the same name is created.
1582 Table 26. Meta expression types
1584 ┌──────────┬─────────────────────┬──────────────────┐
1585 │Keyword │ Description │ Type │
1586 ├──────────┼─────────────────────┼──────────────────┤
1587 │ │ │ │
1588 │length │ Length of the │ integer (32-bit) │
1589 │ │ packet in bytes │ │
1590 ├──────────┼─────────────────────┼──────────────────┤
1591 │ │ │ │
1592 │nfproto │ real hook protocol │ integer (32 bit) │
1593 │ │ family, useful only │ │
1594 │ │ in inet table │ │
1595 ├──────────┼─────────────────────┼──────────────────┤
1596 │ │ │ │
1597 │l4proto │ layer 4 protocol, │ integer (8 bit) │
1598 │ │ skips ipv6 │ │
1599 │ │ extension headers │ │
1600 ├──────────┼─────────────────────┼──────────────────┤
1601 │ │ │ │
1602 │protocol │ EtherType protocol │ ether_type │
1603 │ │ value │ │
1604 ├──────────┼─────────────────────┼──────────────────┤
1605 │ │ │ │
1606 │priority │ TC packet priority │ tc_handle │
1607 ├──────────┼─────────────────────┼──────────────────┤
1608 │ │ │ │
1609 │mark │ Packet mark │ mark │
1610 ├──────────┼─────────────────────┼──────────────────┤
1611 │ │ │ │
1612 │iif │ Input interface │ iface_index │
1613 │ │ index │ │
1614 ├──────────┼─────────────────────┼──────────────────┤
1615 │ │ │ │
1616 │iifname │ Input interface │ ifname │
1617 │ │ name │ │
1618 ├──────────┼─────────────────────┼──────────────────┤
1619 │ │ │ │
1620 │iiftype │ Input interface │ iface_type │
1621 │ │ type │ │
1622 ├──────────┼─────────────────────┼──────────────────┤
1623 │ │ │ │
1624 │oif │ Output interface │ iface_index │
1625 │ │ index │ │
1626 ├──────────┼─────────────────────┼──────────────────┤
1627 │ │ │ │
1628 │oifname │ Output interface │ ifname │
1629 │ │ name │ │
1630 ├──────────┼─────────────────────┼──────────────────┤
1631 │ │ │ │
1632 │oiftype │ Output interface │ iface_type │
1633 │ │ hardware type │ │
1634 ├──────────┼─────────────────────┼──────────────────┤
1635 │ │ │ │
1636 │skuid │ UID associated with │ uid │
1637 │ │ originating socket │ │
1638 ├──────────┼─────────────────────┼──────────────────┤
1639 │ │ │ │
1640 │skgid │ GID associated with │ gid │
1641 │ │ originating socket │ │
1642 ├──────────┼─────────────────────┼──────────────────┤
1643 │ │ │ │
1644 │rtclassid │ Routing realm │ realm │
1645 ├──────────┼─────────────────────┼──────────────────┤
1646 │ │ │ │
1647 │ibrname │ Input bridge │ ifname │
1648 │ │ interface name │ │
1649 ├──────────┼─────────────────────┼──────────────────┤
1650 │ │ │ │
1651 │obrname │ Output bridge │ ifname │
1652 │ │ interface name │ │
1653 ├──────────┼─────────────────────┼──────────────────┤
1654 │ │ │ │
1655 │pkttype │ packet type │ pkt_type │
1656 ├──────────┼─────────────────────┼──────────────────┤
1657 │ │ │ │
1658 │cpu │ cpu number │ integer (32 bit) │
1659 │ │ processing the │ │
1660 │ │ packet │ │
1661 ├──────────┼─────────────────────┼──────────────────┤
1662 │ │ │ │
1663 │iifgroup │ incoming device │ devgroup │
1664 │ │ group │ │
1665 ├──────────┼─────────────────────┼──────────────────┤
1666 │ │ │ │
1667 │oifgroup │ outgoing device │ devgroup │
1668 │ │ group │ │
1669 ├──────────┼─────────────────────┼──────────────────┤
1670 │ │ │ │
1671 │cgroup │ control group id │ integer (32 bit) │
1672 ├──────────┼─────────────────────┼──────────────────┤
1673 │ │ │ │
1674 │random │ pseudo-random │ integer (32 bit) │
1675 │ │ number │ │
1676 ├──────────┼─────────────────────┼──────────────────┤
1677 │ │ │ │
1678 │ipsec │ boolean │ boolean (1 bit) │
1679 ├──────────┼─────────────────────┼──────────────────┤
1680 │ │ │ │
1681 │iifkind │ Input interface │ │
1682 │ │ kind │ │
1683 └──────────┴─────────────────────┴──────────────────┘
1684 Table 27. Meta expression specific types
1686 ┌──────────────┬────────────────────────────┐
1687 │Type │ Description │
1688 ├──────────────┼────────────────────────────┤
1689 │ │ │
1690 │iface_index │ Interface index (32 bit │
1691 │ │ number). Can be specified │
1692 │ │ numerically or as name of │
1693 │ │ an existing interface. │
1694 ├──────────────┼────────────────────────────┤
1695 │ │ │
1696 │ifname │ Interface name (16 byte │
1697 │ │ string). Does not have to │
1698 │ │ exist. │
1699 ├──────────────┼────────────────────────────┤
1700 │ │ │
1701 │iface_type │ Interface type (16 bit │
1702 │ │ number). │
1703 ├──────────────┼────────────────────────────┤
1704 │ │ │
1705 │uid │ User ID (32 bit number). │
1706 │ │ Can be specified │
1707 │ │ numerically or as user │
1708 │ │ name. │
1709 ├──────────────┼────────────────────────────┤
1710 │ │ │
1711 │gid │ Group ID (32 bit number). │
1712 │ │ Can be specified │
1713 │ │ numerically or as group │
1714 │ │ name. │
1715 ├──────────────┼────────────────────────────┤
1716 │ │ │
1717 │realm │ Routing Realm (32 bit │
1718 │ │ number). Can be specified │
1719 │ │ numerically or as symbolic │
1720 │ │ name defined in │
1721 │ │ /etc/iproute2/rt_realms. │
1722 ├──────────────┼────────────────────────────┤
1723 │ │ │
1724 │devgroup_type │ Device group (32 bit │
1725 │ │ number). Can be specified │
1726 │ │ numerically or as symbolic │
1727 │ │ name defined in │
1728 │ │ /etc/iproute2/group. │
1729 ├──────────────┼────────────────────────────┤
1730 │ │ │
1731 │pkt_type │ Packet type: host │
1732 │ │ (addressed to local host), │
1733 │ │ broadcast (to all), │
1734 │ │ multicast (to group), │
1735 │ │ other (addressed to │
1736 │ │ another host). │
1737 ├──────────────┼────────────────────────────┤
1738 │ │ │
1739 │ifkind │ Interface kind (16 byte │
1740 │ │ string). Does not have to │
1741 │ │ exist. │
1742 └──────────────┴────────────────────────────┘
1743 Using meta expressions.
1745 # qualified meta expression
1747 filter output meta oif eth0
1748 # unqualified meta expression
1750 filter output oif eth0
1751 # packet was subject to ipsec processing
1753 raw prerouting meta ipsec exists accept
1754 SOCKET EXPRESSION
1757 socket {transparent | mark}
1758 Socket expression can be used to search for an existing open TCP/UDP
1760 socket and its attributes that can be associated with a packet. It
1761 looks for an established or non-zero bound listening socket (possibly
1762 with a non-local address).
1763 Table 28. Available socket attributes
1765 ┌────────────┬─────────────────────┬─────────────────┐
1766 │Name │ Description │ Type │
1767 ├────────────┼─────────────────────┼─────────────────┤
1768 │ │ │ │
1769 │transparent │ Value of the │ boolean (1 bit) │
1770 │ │ IP_TRANSPARENT │ │
1771 │ │ socket option in │ │
1772 │ │ the found socket. │ │
1773 │ │ It can be 0 or 1. │ │
1774 ├────────────┼─────────────────────┼─────────────────┤
1775 │ │ │ │
1776 │mark │ Value of the socket │ mark │
1777 │ │ mark (SOL_SOCKET, │ │
1778 │ │ SO_MARK). │ │
1779 └────────────┴─────────────────────┴─────────────────┘
1780 Using socket expression.
1782 # Mark packets that correspond to a transparent socket
1784 table inet x {
1785 chain y {
1786 type filter hook prerouting priority -150; policy accept;
1787 socket transparent 1 mark set 0x00000001 accept
1788 }
1789 }
1790 # Trace packets that corresponds to a socket with a mark value of 15
1792 table inet x {
1793 chain y {
1794 type filter hook prerouting priority -150; policy accept;
1795 socket mark 0x0000000f nftrace set 1
1796 }
1797 }
1798 # Set packet mark to socket mark
1800 table inet x {
1801 chain y {
1802 type filter hook prerouting priority -150; policy accept;
1803 tcp dport 8080 mark set socket mark
1804 }
1805 }
1806 OSF EXPRESSION
1809 osf [ttl {loose | skip}] {name | version}
1810 The osf expression does passive operating system fingerprinting. This
1812 expression compares some data (Window Size, MSS, options and their
1813 order, DF, and others) from packets with the SYN bit set.
1814 Table 29. Available osf attributes
1816 ┌────────┬─────────────────────┬────────┐
1817 │Name │ Description │ Type │
1818 ├────────┼─────────────────────┼────────┤
1819 │ │ │ │
1820 │ttl │ Do TTL checks on │ string │
1821 │ │ the packet to │ │
1822 │ │ determine the │ │
1823 │ │ operating system. │ │
1824 ├────────┼─────────────────────┼────────┤
1825 │ │ │ │
1826 │version │ Do OS version │ │
1827 │ │ checks on the │ │
1828 │ │ packet. │ │
1829 ├────────┼─────────────────────┼────────┤
1830 │ │ │ │
1831 │name │ Name of the OS │ string │
1832 │ │ signature to match. │ │
1833 │ │ All signatures can │ │
1834 │ │ be found at pf.os │ │
1835 │ │ file. Use "unknown" │ │
1836 │ │ for OS signatures │ │
1837 │ │ that the expression │ │
1838 │ │ could not detect. │ │
1839 └────────┴─────────────────────┴────────┘
1840 Available ttl values.
1842 If no TTL attribute is passed, make a true IP header and fingerprint TTL true comparison. This generally works for LANs.
1844 * loose: Check if the IP header's TTL is less than the fingerprint one. Works for globally-routable addresses.
1846 * skip: Do not compare the TTL at all.
1847 Using osf expression.
1849 # Accept packets that match the "Linux" OS genre signature without comparing TTL.
1851 table inet x {
1852 chain y {
1853 type filter hook input priority 0; policy accept;
1854 osf ttl skip name "Linux"
1855 }
1856 }
1857 FIB EXPRESSIONS
1860 fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}
1861 A fib expression queries the fib (forwarding information base) to
1863 obtain information such as the output interface index a particular
1864 address would use. The input is a tuple of elements that is used as
1865 input to the fib lookup functions.
1866 Table 30. fib expression specific types
1868 ┌────────┬──────────────────┬──────────────────┐
1869 │Keyword │ Description │ Type │
1870 ├────────┼──────────────────┼──────────────────┤
1871 │ │ │ │
1872 │oif │ Output interface │ integer (32 bit) │
1873 │ │ index │ │
1874 ├────────┼──────────────────┼──────────────────┤
1875 │ │ │ │
1876 │oifname │ Output interface │ string │
1877 │ │ name │ │
1878 ├────────┼──────────────────┼──────────────────┤
1879 │ │ │ │
1880 │type │ Address type │ fib_addrtype │
1881 └────────┴──────────────────┴──────────────────┘
1882 Using fib expressions.
1884 # drop packets without a reverse path
1886 filter prerouting fib saddr . iif oif missing drop
1887 # drop packets to address not configured on ininterface
1889 filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
1890 # perform lookup in a specific 'blackhole' table (0xdead, needs ip appropriate ip rule)
1892 filter prerouting meta mark set 0xdead fib daddr . mark type vmap { blackhole : drop, prohibit : jump prohibited, unreachable : drop }
1893 ROUTING EXPRESSIONS
1896 rt [ip | ip6] {classid | nexthop | mtu | ipsec}
1897 A routing expression refers to routing data associated with a packet.
1899 Table 31. Routing expression types
1901 ┌────────┬─────────────────────┬─────────────────────┐
1902 │Keyword │ Description │ Type │
1903 ├────────┼─────────────────────┼─────────────────────┤
1904 │ │ │ │
1905 │classid │ Routing realm │ realm │
1906 ├────────┼─────────────────────┼─────────────────────┤
1907 │ │ │ │
1908 │nexthop │ Routing nexthop │ ipv4_addr/ipv6_addr │
1909 ├────────┼─────────────────────┼─────────────────────┤
1910 │ │ │ │
1911 │mtu │ TCP maximum segment │ integer (16 bit) │
1912 │ │ size of route │ │
1913 ├────────┼─────────────────────┼─────────────────────┤
1914 │ │ │ │
1915 │ipsec │ route via ipsec │ boolean │
1916 │ │ tunnel or transport │ │
1917 └────────┴─────────────────────┴─────────────────────┘
1918 Table 32. Routing expression specific types
1920 ┌──────┬────────────────────────────┐
1921 │Type │ Description │
1922 ├──────┼────────────────────────────┤
1923 │ │ │
1924 │realm │ Routing Realm (32 bit │
1925 │ │ number). Can be specified │
1926 │ │ numerically or as symbolic │
1927 │ │ name defined in │
1928 │ │ /etc/iproute2/rt_realms. │
1929 └──────┴────────────────────────────┘
1930 Using routing expressions.
1932 # IP family independent rt expression
1934 filter output rt classid 10
1935 filter output rt ipsec missing
1936 # IP family dependent rt expressions
1938 ip filter output rt nexthop 192.168.0.1
1939 ip6 filter output rt nexthop fd00::1
1940 inet filter output rt ip nexthop 192.168.0.1
1941 inet filter output rt ip6 nexthop fd00::1
1942 IPSEC EXPRESSIONS
1945 ipsec {in | out} [ spnum NUM ] {reqid | spi}
1946 ipsec {in | out} [ spnum NUM ] {ip | ip6} {saddr | daddr}
1947 An ipsec expression refers to ipsec data associated with a packet.
1949 The in or out keyword needs to be used to specify if the expression
1951 should examine inbound or outbound policies. The in keyword can be used
1952 in the prerouting, input and forward hooks. The out keyword applies to
1953 forward, output and postrouting hooks. The optional keyword spnum can
1954 be used to match a specific state in a chain, it defaults to 0.
1955 Table 33. Ipsec expression types
1957 ┌────────┬─────────────────────┬─────────────────────┐
1958 │Keyword │ Description │ Type │
1959 ├────────┼─────────────────────┼─────────────────────┤
1960 │ │ │ │
1961 │reqid │ Request ID │ integer (32 bit) │
1962 ├────────┼─────────────────────┼─────────────────────┤
1963 │ │ │ │
1964 │spi │ Security Parameter │ integer (32 bit) │
1965 │ │ Index │ │
1966 ├────────┼─────────────────────┼─────────────────────┤
1967 │ │ │ │
1968 │saddr │ Source address of │ ipv4_addr/ipv6_addr │
1969 │ │ the tunnel │ │
1970 ├────────┼─────────────────────┼─────────────────────┤
1971 │ │ │ │
1972 │daddr │ Destination address │ ipv4_addr/ipv6_addr │
1973 │ │ of the tunnel │ │
1974 └────────┴─────────────────────┴─────────────────────┘
1975
1977 Payload expressions refer to data from the packet’s payload.
1978 ETHERNET HEADER EXPRESSION
1980 ether {daddr | saddr | type}
1981 Table 34. Ethernet header expression types
1983 ┌────────┬────────────────────┬────────────┐
1984 │Keyword │ Description │ Type │
1985 ├────────┼────────────────────┼────────────┤
1986 │ │ │ │
1987 │daddr │ Destination MAC │ ether_addr │
1988 │ │ address │ │
1989 ├────────┼────────────────────┼────────────┤
1990 │ │ │ │
1991 │saddr │ Source MAC address │ ether_addr │
1992 ├────────┼────────────────────┼────────────┤
1993 │ │ │ │
1994 │type │ EtherType │ ether_type │
1995 └────────┴────────────────────┴────────────┘
1996 VLAN HEADER EXPRESSION
1998 vlan {id | cfi | pcp | type}
1999 Table 35. VLAN header expression
2001 ┌────────┬─────────────────────┬──────────────────┐
2002 │Keyword │ Description │ Type │
2003 ├────────┼─────────────────────┼──────────────────┤
2004 │ │ │ │
2005 │id │ VLAN ID (VID) │ integer (12 bit) │
2006 ├────────┼─────────────────────┼──────────────────┤
2007 │ │ │ │
2008 │cfi │ Canonical Format │ integer (1 bit) │
2009 │ │ Indicator │ │
2010 ├────────┼─────────────────────┼──────────────────┤
2011 │ │ │ │
2012 │pcp │ Priority code point │ integer (3 bit) │
2013 ├────────┼─────────────────────┼──────────────────┤
2014 │ │ │ │
2015 │type │ EtherType │ ether_type │
2016 └────────┴─────────────────────┴──────────────────┘
2017 ARP HEADER EXPRESSION
2019 arp {htype | ptype | hlen | plen | operation | saddr { ip | ether } | daddr { ip | ether }
2020 Table 36. ARP header expression
2022 ┌────────────┬─────────────────────┬──────────────────┐
2023 │Keyword │ Description │ Type │
2024 ├────────────┼─────────────────────┼──────────────────┤
2025 │ │ │ │
2026 │htype │ ARP hardware type │ integer (16 bit) │
2027 ├────────────┼─────────────────────┼──────────────────┤
2028 │ │ │ │
2029 │ptype │ EtherType │ ether_type │
2030 ├────────────┼─────────────────────┼──────────────────┤
2031 │ │ │ │
2032 │hlen │ Hardware address │ integer (8 bit) │
2033 │ │ len │ │
2034 ├────────────┼─────────────────────┼──────────────────┤
2035 │ │ │ │
2036 │plen │ Protocol address │ integer (8 bit) │
2037 │ │ len │ │
2038 ├────────────┼─────────────────────┼──────────────────┤
2039 │ │ │ │
2040 │operation │ Operation │ arp_op │
2041 ├────────────┼─────────────────────┼──────────────────┤
2042 │ │ │ │
2043 │saddr ether │ Ethernet sender │ ether_addr │
2044 │ │ address │ │
2045 ├────────────┼─────────────────────┼──────────────────┤
2046 │ │ │ │
2047 │daddr ether │ Ethernet target │ ether_addr │
2048 │ │ address │ │
2049 ├────────────┼─────────────────────┼──────────────────┤
2050 │ │ │ │
2051 │saddr ip │ IPv4 sender address │ ipv4_addr │
2052 ├────────────┼─────────────────────┼──────────────────┤
2053 │ │ │ │
2054 │daddr ip │ IPv4 target address │ ipv4_addr │
2055 └────────────┴─────────────────────┴──────────────────┘
2056 IPV4 HEADER EXPRESSION
2058 ip {version | hdrlength | dscp | ecn | length | id | frag-off | ttl | protocol | checksum | saddr | daddr }
2059 Table 37. IPv4 header expression
2061 ┌──────────┬─────────────────────┬──────────────────┐
2062 │Keyword │ Description │ Type │
2063 ├──────────┼─────────────────────┼──────────────────┤
2064 │ │ │ │
2065 │version │ IP header version │ integer (4 bit) │
2066 │ │ (4) │ │
2067 ├──────────┼─────────────────────┼──────────────────┤
2068 │ │ │ │
2069 │hdrlength │ IP header length │ integer (4 bit) │
2070 │ │ including options │ FIXME scaling │
2071 ├──────────┼─────────────────────┼──────────────────┤
2072 │ │ │ │
2073 │dscp │ Differentiated │ dscp │
2074 │ │ Services Code Point │ │
2075 ├──────────┼─────────────────────┼──────────────────┤
2076 │ │ │ │
2077 │ecn │ Explicit Congestion │ ecn │
2078 │ │ Notification │ │
2079 ├──────────┼─────────────────────┼──────────────────┤
2080 │ │ │ │
2081 │length │ Total packet length │ integer (16 bit) │
2082 ├──────────┼─────────────────────┼──────────────────┤
2083 │ │ │ │
2084 │id │ IP ID │ integer (16 bit) │
2085 ├──────────┼─────────────────────┼──────────────────┤
2086 │ │ │ │
2087 │frag-off │ Fragment offset │ integer (16 bit) │
2088 ├──────────┼─────────────────────┼──────────────────┤
2089 │ │ │ │
2090 │ttl │ Time to live │ integer (8 bit) │
2091 ├──────────┼─────────────────────┼──────────────────┤
2092 │ │ │ │
2093 │protocol │ Upper layer │ inet_proto │
2094 │ │ protocol │ │
2095 ├──────────┼─────────────────────┼──────────────────┤
2096 │ │ │ │
2097 │checksum │ IP header checksum │ integer (16 bit) │
2098 ├──────────┼─────────────────────┼──────────────────┤
2099 │ │ │ │
2100 │saddr │ Source address │ ipv4_addr │
2101 ├──────────┼─────────────────────┼──────────────────┤
2102 │ │ │ │
2103 │daddr │ Destination address │ ipv4_addr │
2104 └──────────┴─────────────────────┴──────────────────┘
2105 ICMP HEADER EXPRESSION
2107 icmp {type | code | checksum | id | sequence | gateway | mtu}
2108 This expression refers to ICMP header fields. When using it in inet,
2110 bridge or netdev families, it will cause an implicit dependency on IPv4
2111 to be created. To match on unusual cases like ICMP over IPv6, one has
2112 to add an explicit meta protocol ip6 match to the rule.
2113 Table 38. ICMP header expression
2115 ┌─────────┬─────────────────────┬──────────────────┐
2116 │Keyword │ Description │ Type │
2117 ├─────────┼─────────────────────┼──────────────────┤
2118 │ │ │ │
2119 │type │ ICMP type field │ icmp_type │
2120 ├─────────┼─────────────────────┼──────────────────┤
2121 │ │ │ │
2122 │code │ ICMP code field │ integer (8 bit) │
2123 ├─────────┼─────────────────────┼──────────────────┤
2124 │ │ │ │
2125 │checksum │ ICMP checksum field │ integer (16 bit) │
2126 ├─────────┼─────────────────────┼──────────────────┤
2127 │ │ │ │
2128 │id │ ID of echo │ integer (16 bit) │
2129 │ │ request/response │ │
2130 ├─────────┼─────────────────────┼──────────────────┤
2131 │ │ │ │
2132 │sequence │ sequence number of │ integer (16 bit) │
2133 │ │ echo │ │
2134 │ │ request/response │ │
2135 ├─────────┼─────────────────────┼──────────────────┤
2136 │ │ │ │
2137 │gateway │ gateway of │ integer (32 bit) │
2138 │ │ redirects │ │
2139 ├─────────┼─────────────────────┼──────────────────┤
2140 │ │ │ │
2141 │mtu │ MTU of path MTU │ integer (16 bit) │
2142 │ │ discovery │ │
2143 └─────────┴─────────────────────┴──────────────────┘
2144 IGMP HEADER EXPRESSION
2146 igmp {type | mrt | checksum | group}
2147 This expression refers to IGMP header fields. When using it in inet,
2149 bridge or netdev families, it will cause an implicit dependency on IPv4
2150 to be created. To match on unusual cases like IGMP over IPv6, one has
2151 to add an explicit meta protocol ip6 match to the rule.
2152 Table 39. IGMP header expression
2154 ┌─────────┬─────────────────────┬──────────────────┐
2155 │Keyword │ Description │ Type │
2156 ├─────────┼─────────────────────┼──────────────────┤
2157 │ │ │ │
2158 │type │ IGMP type field │ igmp_type │
2159 ├─────────┼─────────────────────┼──────────────────┤
2160 │ │ │ │
2161 │mrt │ IGMP maximum │ integer (8 bit) │
2162 │ │ response time field │ │
2163 ├─────────┼─────────────────────┼──────────────────┤
2164 │ │ │ │
2165 │checksum │ ICMP checksum field │ integer (16 bit) │
2166 ├─────────┼─────────────────────┼──────────────────┤
2167 │ │ │ │
2168 │group │ Group address │ integer (32 bit) │
2169 └─────────┴─────────────────────┴──────────────────┘
2170 IPV6 HEADER EXPRESSION
2172 ip6 {version | dscp | ecn | flowlabel | length | nexthdr | hoplimit | saddr | daddr}
2173 This expression refers to the ipv6 header fields. Caution when using
2175 ip6 nexthdr, the value only refers to the next header, i.e. ip6 nexthdr
2176 tcp will only match if the ipv6 packet does not contain any extension
2177 headers. Packets that are fragmented or e.g. contain a routing
2178 extension headers will not be matched. Please use meta l4proto if you
2179 wish to match the real transport header and ignore any additional
2180 extension headers instead.
2181 Table 40. IPv6 header expression
2183 ┌──────────┬─────────────────────┬──────────────────┐
2184 │Keyword │ Description │ Type │
2185 ├──────────┼─────────────────────┼──────────────────┤
2186 │ │ │ │
2187 │version │ IP header version │ integer (4 bit) │
2188 │ │ (6) │ │
2189 ├──────────┼─────────────────────┼──────────────────┤
2190 │ │ │ │
2191 │dscp │ Differentiated │ dscp │
2192 │ │ Services Code Point │ │
2193 ├──────────┼─────────────────────┼──────────────────┤
2194 │ │ │ │
2195 │ecn │ Explicit Congestion │ ecn │
2196 │ │ Notification │ │
2197 ├──────────┼─────────────────────┼──────────────────┤
2198 │ │ │ │
2199 │flowlabel │ Flow label │ integer (20 bit) │
2200 ├──────────┼─────────────────────┼──────────────────┤
2201 │ │ │ │
2202 │length │ Payload length │ integer (16 bit) │
2203 ├──────────┼─────────────────────┼──────────────────┤
2204 │ │ │ │
2205 │nexthdr │ Nexthdr protocol │ inet_proto │
2206 ├──────────┼─────────────────────┼──────────────────┤
2207 │ │ │ │
2208 │hoplimit │ Hop limit │ integer (8 bit) │
2209 ├──────────┼─────────────────────┼──────────────────┤
2210 │ │ │ │
2211 │saddr │ Source address │ ipv6_addr │
2212 ├──────────┼─────────────────────┼──────────────────┤
2213 │ │ │ │
2214 │daddr │ Destination address │ ipv6_addr │
2215 └──────────┴─────────────────────┴──────────────────┘
2216 Using ip6 header expressions.
2218 # matching if first extension header indicates a fragment
2220 ip6 nexthdr ipv6-frag
2221 ICMPV6 HEADER EXPRESSION
2224 icmpv6 {type | code | checksum | parameter-problem | packet-too-big | id | sequence | max-delay}
2225 This expression refers to ICMPv6 header fields. When using it in inet,
2227 bridge or netdev families, it will cause an implicit dependency on IPv6
2228 to be created. To match on unusual cases like ICMPv6 over IPv4, one has
2229 to add an explicit meta protocol ip match to the rule.
2230 Table 41. ICMPv6 header expression
2232 ┌──────────────────┬────────────────────┬──────────────────┐
2233 │Keyword │ Description │ Type │
2234 ├──────────────────┼────────────────────┼──────────────────┤
2235 │ │ │ │
2236 │type │ ICMPv6 type field │ icmpv6_type │
2237 ├──────────────────┼────────────────────┼──────────────────┤
2238 │ │ │ │
2239 │code │ ICMPv6 code field │ integer (8 bit) │
2240 ├──────────────────┼────────────────────┼──────────────────┤
2241 │ │ │ │
2242 │checksum │ ICMPv6 checksum │ integer (16 bit) │
2243 │ │ field │ │
2244 ├──────────────────┼────────────────────┼──────────────────┤
2245 │ │ │ │
2246 │parameter-problem │ pointer to problem │ integer (32 bit) │
2247 ├──────────────────┼────────────────────┼──────────────────┤
2248 │ │ │ │
2249 │packet-too-big │ oversized MTU │ integer (32 bit) │
2250 ├──────────────────┼────────────────────┼──────────────────┤
2251 │ │ │ │
2252 │id │ ID of echo │ integer (16 bit) │
2253 │ │ request/response │ │
2254 ├──────────────────┼────────────────────┼──────────────────┤
2255 │ │ │ │
2256 │sequence │ sequence number of │ integer (16 bit) │
2257 │ │ echo │ │
2258 │ │ request/response │ │
2259 ├──────────────────┼────────────────────┼──────────────────┤
2260 │ │ │ │
2261 │max-delay │ maximum response │ integer (16 bit) │
2262 │ │ delay of MLD │ │
2263 │ │ queries │ │
2264 └──────────────────┴────────────────────┴──────────────────┘
2265 TCP HEADER EXPRESSION
2267 tcp {sport | dport | sequence | ackseq | doff | reserved | flags | window | checksum | urgptr}
2268 Table 42. TCP header expression
2270 ┌─────────┬──────────────────┬──────────────────┐
2271 │Keyword │ Description │ Type │
2272 ├─────────┼──────────────────┼──────────────────┤
2273 │ │ │ │
2274 │sport │ Source port │ inet_service │
2275 ├─────────┼──────────────────┼──────────────────┤
2276 │ │ │ │
2277 │dport │ Destination port │ inet_service │
2278 ├─────────┼──────────────────┼──────────────────┤
2279 │ │ │ │
2280 │sequence │ Sequence number │ integer (32 bit) │
2281 ├─────────┼──────────────────┼──────────────────┤
2282 │ │ │ │
2283 │ackseq │ Acknowledgement │ integer (32 bit) │
2284 │ │ number │ │
2285 ├─────────┼──────────────────┼──────────────────┤
2286 │ │ │ │
2287 │doff │ Data offset │ integer (4 bit) │
2288 │ │ │ FIXME scaling │
2289 ├─────────┼──────────────────┼──────────────────┤
2290 │ │ │ │
2291 │reserved │ Reserved area │ integer (4 bit) │
2292 ├─────────┼──────────────────┼──────────────────┤
2293 │ │ │ │
2294 │flags │ TCP flags │ tcp_flag │
2295 ├─────────┼──────────────────┼──────────────────┤
2296 │ │ │ │
2297 │window │ Window │ integer (16 bit) │
2298 ├─────────┼──────────────────┼──────────────────┤
2299 │ │ │ │
2300 │checksum │ Checksum │ integer (16 bit) │
2301 ├─────────┼──────────────────┼──────────────────┤
2302 │ │ │ │
2303 │urgptr │ Urgent pointer │ integer (16 bit) │
2304 └─────────┴──────────────────┴──────────────────┘
2305 UDP HEADER EXPRESSION
2307 udp {sport | dport | length | checksum}
2308 Table 43. UDP header expression
2310 ┌─────────┬─────────────────────┬──────────────────┐
2311 │Keyword │ Description │ Type │
2312 ├─────────┼─────────────────────┼──────────────────┤
2313 │ │ │ │
2314 │sport │ Source port │ inet_service │
2315 ├─────────┼─────────────────────┼──────────────────┤
2316 │ │ │ │
2317 │dport │ Destination port │ inet_service │
2318 ├─────────┼─────────────────────┼──────────────────┤
2319 │ │ │ │
2320 │length │ Total packet length │ integer (16 bit) │
2321 ├─────────┼─────────────────────┼──────────────────┤
2322 │ │ │ │
2323 │checksum │ Checksum │ integer (16 bit) │
2324 └─────────┴─────────────────────┴──────────────────┘
2325 UDP-LITE HEADER EXPRESSION
2327 udplite {sport | dport | checksum}
2328 Table 44. UDP-Lite header expression
2330 ┌─────────┬──────────────────┬──────────────────┐
2331 │Keyword │ Description │ Type │
2332 ├─────────┼──────────────────┼──────────────────┤
2333 │ │ │ │
2334 │sport │ Source port │ inet_service │
2335 ├─────────┼──────────────────┼──────────────────┤
2336 │ │ │ │
2337 │dport │ Destination port │ inet_service │
2338 ├─────────┼──────────────────┼──────────────────┤
2339 │ │ │ │
2340 │checksum │ Checksum │ integer (16 bit) │
2341 └─────────┴──────────────────┴──────────────────┘
2342 SCTP HEADER EXPRESSION
2344 sctp {sport | dport | vtag | checksum}
2345 Table 45. SCTP header expression
2347 ┌─────────┬──────────────────┬──────────────────┐
2348 │Keyword │ Description │ Type │
2349 ├─────────┼──────────────────┼──────────────────┤
2350 │ │ │ │
2351 │sport │ Source port │ inet_service │
2352 ├─────────┼──────────────────┼──────────────────┤
2353 │ │ │ │
2354 │dport │ Destination port │ inet_service │
2355 ├─────────┼──────────────────┼──────────────────┤
2356 │ │ │ │
2357 │vtag │ Verification Tag │ integer (32 bit) │
2358 ├─────────┼──────────────────┼──────────────────┤
2359 │ │ │ │
2360 │checksum │ Checksum │ integer (32 bit) │
2361 └─────────┴──────────────────┴──────────────────┘
2362 DCCP HEADER EXPRESSION
2364 dccp {sport | dport}
2365 Table 46. DCCP header expression
2367 ┌────────┬──────────────────┬──────────────┐
2368 │Keyword │ Description │ Type │
2369 ├────────┼──────────────────┼──────────────┤
2370 │ │ │ │
2371 │sport │ Source port │ inet_service │
2372 ├────────┼──────────────────┼──────────────┤
2373 │ │ │ │
2374 │dport │ Destination port │ inet_service │
2375 └────────┴──────────────────┴──────────────┘
2376 AUTHENTICATION HEADER EXPRESSION
2378 ah {nexthdr | hdrlength | reserved | spi | sequence}
2379 Table 47. AH header expression
2381 ┌──────────┬────────────────────┬──────────────────┐
2382 │Keyword │ Description │ Type │
2383 ├──────────┼────────────────────┼──────────────────┤
2384 │ │ │ │
2385 │nexthdr │ Next header │ inet_proto │
2386 │ │ protocol │ │
2387 ├──────────┼────────────────────┼──────────────────┤
2388 │ │ │ │
2389 │hdrlength │ AH Header length │ integer (8 bit) │
2390 ├──────────┼────────────────────┼──────────────────┤
2391 │ │ │ │
2392 │reserved │ Reserved area │ integer (16 bit) │
2393 ├──────────┼────────────────────┼──────────────────┤
2394 │ │ │ │
2395 │spi │ Security Parameter │ integer (32 bit) │
2396 │ │ Index │ │
2397 ├──────────┼────────────────────┼──────────────────┤
2398 │ │ │ │
2399 │sequence │ Sequence number │ integer (32 bit) │
2400 └──────────┴────────────────────┴──────────────────┘
2401 ENCRYPTED SECURITY PAYLOAD HEADER EXPRESSION
2403 esp {spi | sequence}
2404 Table 48. ESP header expression
2406 ┌─────────┬────────────────────┬──────────────────┐
2407 │Keyword │ Description │ Type │
2408 ├─────────┼────────────────────┼──────────────────┤
2409 │ │ │ │
2410 │spi │ Security Parameter │ integer (32 bit) │
2411 │ │ Index │ │
2412 ├─────────┼────────────────────┼──────────────────┤
2413 │ │ │ │
2414 │sequence │ Sequence number │ integer (32 bit) │
2415 └─────────┴────────────────────┴──────────────────┘
2416 IPCOMP HEADER EXPRESSION
2418 comp {nexthdr | flags | cpi}
2419 Table 49. IPComp header expression
2421 ┌────────┬─────────────────┬──────────────────┐
2422 │Keyword │ Description │ Type │
2423 ├────────┼─────────────────┼──────────────────┤
2424 │ │ │ │
2425 │nexthdr │ Next header │ inet_proto │
2426 │ │ protocol │ │
2427 ├────────┼─────────────────┼──────────────────┤
2428 │ │ │ │
2429 │flags │ Flags │ bitmask │
2430 ├────────┼─────────────────┼──────────────────┤
2431 │ │ │ │
2432 │cpi │ compression │ integer (16 bit) │
2433 │ │ Parameter Index │ │
2434 └────────┴─────────────────┴──────────────────┘
2435 RAW PAYLOAD EXPRESSION
2437 @base,offset,length
2438 The raw payload expression instructs to load length bits starting at
2440 offset bits. Bit 0 refers to the very first bit — in the C programming
2441 language, this corresponds to the topmost bit, i.e. 0x80 in case of an
2442 octet. They are useful to match headers that do not have a
2443 human-readable template expression yet. Note that nft will not add
2444 dependencies for Raw payload expressions. If you e.g. want to match
2445 protocol fields of a transport header with protocol number 5, you need
2446 to manually exclude packets that have a different transport header, for
2447 instance by using meta l4proto 5 before the raw expression.
2448 Table 50. Supported payload protocol bases
2450 ┌─────┬─────────────────────────┐
2451 │Base │ Description │
2452 ├─────┼─────────────────────────┤
2453 │ │ │
2454 │ll │ Link layer, for example │
2455 │ │ the Ethernet header │
2456 ├─────┼─────────────────────────┤
2457 │ │ │
2458 │nh │ Network header, for │
2459 │ │ example IPv4 or IPv6 │
2460 ├─────┼─────────────────────────┤
2461 │ │ │
2462 │th │ Transport Header, for │
2463 │ │ example TCP │
2464 └─────┴─────────────────────────┘
2465 Matching destination port of both UDP and TCP.
2467 inet filter input meta l4proto {tcp, udp} @th,16,16 { 53, 80 }
2469 Rewrite arp packet target hardware address if target protocol address
2471 matches a given address.
2472 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
2474 EXTENSION HEADER EXPRESSIONS
2477 Extension header expressions refer to data from variable-sized protocol
2478 headers, such as IPv6 extension headers and TCP options.
2479 nftables currently supports matching (finding) a given ipv6 extension
2481 header or TCP option.
2482 hbh {nexthdr | hdrlength}
2484 frag {nexthdr | frag-off | more-fragments | id}
2485 rt {nexthdr | hdrlength | type | seg-left}
2486 dst {nexthdr | hdrlength}
2487 mh {nexthdr | hdrlength | checksum | type}
2488 srh {flags | tag | sid | seg-left}
2489 tcp option {eol | noop | maxseg | window | sack-permitted | sack | sack0 | sack1 | sack2 | sack3 | timestamp} tcp_option_field
2490 The following syntaxes are valid only in a relational expression with
2492 boolean type on right-hand side for checking header existence only:
2493 exthdr {hbh | frag | rt | dst | mh}
2495 tcp option {eol | noop | maxseg | window | sack-permitted | sack | sack0 | sack1 | sack2 | sack3 | timestamp}
2496 Table 51. IPv6 extension headers
2498 ┌────────┬────────────────────────┐
2499 │Keyword │ Description │
2500 ├────────┼────────────────────────┤
2501 │ │ │
2502 │hbh │ Hop by Hop │
2503 ├────────┼────────────────────────┤
2504 │ │ │
2505 │rt │ Routing Header │
2506 ├────────┼────────────────────────┤
2507 │ │ │
2508 │frag │ Fragmentation header │
2509 ├────────┼────────────────────────┤
2510 │ │ │
2511 │dst │ dst options │
2512 ├────────┼────────────────────────┤
2513 │ │ │
2514 │mh │ Mobility Header │
2515 ├────────┼────────────────────────┤
2516 │ │ │
2517 │srh │ Segment Routing Header │
2518 └────────┴────────────────────────┘
2519 Table 52. TCP Options
2521 ┌───────────────┬─────────────────────┬─────────────────────┐
2522 │Keyword │ Description │ TCP option fields │
2523 ├───────────────┼─────────────────────┼─────────────────────┤
2524 │ │ │ │
2525 │eol │ End if option list │ kind │
2526 ├───────────────┼─────────────────────┼─────────────────────┤
2527 │ │ │ │
2528 │noop │ 1 Byte TCP No-op │ kind │
2529 │ │ options │ │
2530 ├───────────────┼─────────────────────┼─────────────────────┤
2531 │ │ │ │
2532 │maxseg │ TCP Maximum Segment │ kind, length, size │
2533 │ │ Size │ │
2534 ├───────────────┼─────────────────────┼─────────────────────┤
2535 │ │ │ │
2536 │window │ TCP Window Scaling │ kind, length, count │
2537 ├───────────────┼─────────────────────┼─────────────────────┤
2538 │ │ │ │
2539 │sack-permitted │ TCP SACK permitted │ kind, length │
2540 ├───────────────┼─────────────────────┼─────────────────────┤
2541 │ │ │ │
2542 │sack │ TCP Selective │ kind, length, left, │
2543 │ │ Acknowledgement │ right │
2544 │ │ (alias of block 0) │ │
2545 ├───────────────┼─────────────────────┼─────────────────────┤
2546 │ │ │ │
2547 │sack0 │ TCP Selective │ kind, length, left, │
2548 │ │ Acknowledgement │ right │
2549 │ │ (block 0) │ │
2550 ├───────────────┼─────────────────────┼─────────────────────┤
2551 │ │ │ │
2552 │sack1 │ TCP Selective │ kind, length, left, │
2553 │ │ Acknowledgement │ right │
2554 │ │ (block 1) │ │
2555 ├───────────────┼─────────────────────┼─────────────────────┤
2556 │ │ │ │
2557 │sack2 │ TCP Selective │ kind, length, left, │
2558 │ │ Acknowledgement │ right │
2559 │ │ (block 2) │ │
2560 ├───────────────┼─────────────────────┼─────────────────────┤
2561 │ │ │ │
2562 │sack3 │ TCP Selective │ kind, length, left, │
2563 │ │ Acknowledgement │ right │
2564 │ │ (block 3) │ │
2565 ├───────────────┼─────────────────────┼─────────────────────┤
2566 │ │ │ │
2567 │timestamp │ TCP Timestamps │ kind, length, │
2568 │ │ │ tsval, tsecr │
2569 └───────────────┴─────────────────────┴─────────────────────┘
2570 finding TCP options.
2572 filter input tcp option sack-permitted kind 1 counter
2574 matching IPv6 exthdr.
2576 ip6 filter input frag more-fragments 1 counter
2578 CONNTRACK EXPRESSIONS
2581 Conntrack expressions refer to meta data of the connection tracking
2582 entry associated with a packet.
2583 There are three types of conntrack expressions. Some conntrack
2585 expressions require the flow direction before the conntrack key, others
2586 must be used directly because they are direction agnostic. The packets,
2587 bytes and avgpkt keywords can be used with or without a direction. If
2588 the direction is omitted, the sum of the original and the reply
2589 direction is returned. The same is true for the zone, if a direction is
2590 given, the zone is only matched if the zone id is tied to the given
2591 direction.
2592 ct {state | direction | status | mark | expiration | helper | label}
2594 ct [original | reply] {l3proto | protocol | bytes | packets | avgpkt | zone}
2595 ct {original | reply} {proto-src | proto-dst}
2596 ct {original | reply} {ip | ip6} {saddr | daddr}
2597 Table 53. Conntrack expressions
2599 ┌───────────┬─────────────────────┬─────────────────────┐
2600 │Keyword │ Description │ Type │
2601 ├───────────┼─────────────────────┼─────────────────────┤
2602 │ │ │ │
2603 │state │ State of the │ ct_state │
2604 │ │ connection │ │
2605 ├───────────┼─────────────────────┼─────────────────────┤
2606 │ │ │ │
2607 │direction │ Direction of the │ ct_dir │
2608 │ │ packet relative to │ │
2609 │ │ the connection │ │
2610 ├───────────┼─────────────────────┼─────────────────────┤
2611 │ │ │ │
2612 │status │ Status of the │ ct_status │
2613 │ │ connection │ │
2614 ├───────────┼─────────────────────┼─────────────────────┤
2615 │ │ │ │
2616 │mark │ Connection mark │ mark │
2617 ├───────────┼─────────────────────┼─────────────────────┤
2618 │ │ │ │
2619 │expiration │ Connection │ time │
2620 │ │ expiration time │ │
2621 ├───────────┼─────────────────────┼─────────────────────┤
2622 │ │ │ │
2623 │helper │ Helper associated │ string │
2624 │ │ with the connection │ │
2625 ├───────────┼─────────────────────┼─────────────────────┤
2626 │ │ │ │
2627 │label │ Connection tracking │ ct_label │
2628 │ │ label bit or │ │
2629 │ │ symbolic name │ │
2630 │ │ defined in │ │
2631 │ │ connlabel.conf in │ │
2632 │ │ the nftables │ │
2633 │ │ include path │ │
2634 ├───────────┼─────────────────────┼─────────────────────┤
2635 │ │ │ │
2636 │l3proto │ Layer 3 protocol of │ nf_proto │
2637 │ │ the connection │ │
2638 ├───────────┼─────────────────────┼─────────────────────┤
2639 │ │ │ │
2640 │saddr │ Source address of │ ipv4_addr/ipv6_addr │
2641 │ │ the connection for │ │
2642 │ │ the given direction │ │
2643 ├───────────┼─────────────────────┼─────────────────────┤
2644 │ │ │ │
2645 │daddr │ Destination address │ ipv4_addr/ipv6_addr │
2646 │ │ of the connection │ │
2647 │ │ for the given │ │
2648 │ │ direction │ │
2649 ├───────────┼─────────────────────┼─────────────────────┤
2650 │ │ │ │
2651 │protocol │ Layer 4 protocol of │ inet_proto │
2652 │ │ the connection for │ │
2653 │ │ the given direction │ │
2654 ├───────────┼─────────────────────┼─────────────────────┤
2655 │ │ │ │
2656 │proto-src │ Layer 4 protocol │ integer (16 bit) │
2657 │ │ source for the │ │
2658 │ │ given direction │ │
2659 ├───────────┼─────────────────────┼─────────────────────┤
2660 │ │ │ │
2661 │proto-dst │ Layer 4 protocol │ integer (16 bit) │
2662 │ │ destination for the │ │
2663 │ │ given direction │ │
2664 ├───────────┼─────────────────────┼─────────────────────┤
2665 │ │ │ │
2666 │packets │ packet count seen │ integer (64 bit) │
2667 │ │ in the given │ │
2668 │ │ direction or sum of │ │
2669 │ │ original and reply │ │
2670 ├───────────┼─────────────────────┼─────────────────────┤
2671 │ │ │ │
2672 │bytes │ byte count seen, │ integer (64 bit) │
2673 │ │ see description for │ │
2674 │ │ packets keyword │ │
2675 ├───────────┼─────────────────────┼─────────────────────┤
2676 │ │ │ │
2677 │avgpkt │ average bytes per │ integer (64 bit) │
2678 │ │ packet, see │ │
2679 │ │ description for │ │
2680 │ │ packets keyword │ │
2681 ├───────────┼─────────────────────┼─────────────────────┤
2682 │ │ │ │
2683 │zone │ conntrack zone │ integer (16 bit) │
2684 └───────────┴─────────────────────┴─────────────────────┘
2685 A description of conntrack-specific types listed above can be found
2687 sub-section CONNTRACK TYPES above.
2688 restrict the number of parallel connections to a server.
2690 filter input tcp dport 22 meter test { ip saddr ct count over 2 } reject
2692
2695 Statements represent actions to be performed. They can alter control
2696 flow (return, jump to a different chain, accept or drop the packet) or
2697 can perform actions, such as logging, rejecting a packet, etc.
2698 Statements exist in two kinds. Terminal statements unconditionally
2700 terminate evaluation of the current rule, non-terminal statements
2701 either only conditionally or never terminate evaluation of the current
2702 rule, in other words, they are passive from the ruleset evaluation
2703 perspective. There can be an arbitrary amount of non-terminal
2704 statements in a rule, but only a single terminal statement as the final
2705 statement.
2706 VERDICT STATEMENT
2708 The verdict statement alters control flow in the ruleset and issues
2709 policy decisions for packets.
2710 {accept | drop | queue | continue | return}
2712 {jump | goto} chain
2713 accept and drop are absolute verdicts — they terminate ruleset
2715 evaluation immediately.
2716 accept Terminate ruleset
2719 evaluation and accept the
2720 packet. The packet can
2721 still be dropped later by
2722 another hook, for instance
2723 accept in the forward hook
2724 still allows to drop the
2725 packet later in the
2726 postrouting hook, or
2727 another forward base chain
2728 that has a higher priority
2729 number and is evaluated
2730 afterwards in the
2731 processing pipeline.
2732 drop Terminate ruleset
2736 evaluation and drop the
2737 packet. The drop occurs
2738 instantly, no further
2739 chains or hooks are
2740 evaluated. It is not
2741 possible to accept the
2742 packet in a later chain
2743 again, as those are not
2744 evaluated anymore for the
2745 packet.
2746 queue Terminate ruleset
2748 evaluation and queue the
2749 packet to userspace.
2750 Userspace must provide a
2751 drop or accept verdict. In
2752 case of accept, processing
2753 resumes with the next base
2754 chain hook, not the rule
2755 following the queue
2756 verdict.
2757 continue Continue ruleset
2759 evaluation with the next
2760 rule. This is the default
2761 behaviour in case a rule
2762 issues no verdict.
2763 return Return from the current
2765 chain and continue
2766 evaluation at the next
2767 rule in the last chain. If
2768 issued in a base chain, it
2769 is equivalent to the base
2770 chain policy.
2771 jump chain Continue evaluation at the
2773 first rule in chain. The
2774 current position in the
2775 ruleset is pushed to a
2776 call stack and evaluation
2777 will continue there when
2778 the new chain is entirely
2779 evaluated or a return
2780 verdict is issued. In case
2781 an absolute verdict is
2782 issued by a rule in the
2783 chain, ruleset evaluation
2784 terminates immediately and
2785 the specific action is
2786 taken.
2787 goto chain Similar to jump, but the
2789 current position is not
2790 pushed to the call stack,
2791 meaning that after the new
2792 chain evaluation will
2793 continue at the last chain
2794 instead of the one
2795 containing the goto
2796 statement.
2797 Using verdict statements.
2800 # process packets from eth0 and the internal network in from_lan
2802 # chain, drop all packets from eth0 with different source addresses.
2803 filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan
2805 filter input iif eth0 drop
2806 PAYLOAD STATEMENT
2809 payload_expression set value
2810 The payload statement alters packet content. It can be used for example
2812 to set ip DSCP (diffserv) header field or ipv6 flow labels.
2813 route some packets instead of bridging.
2815 # redirect tcp:http from 192.160.0.0/16 to local machine for routing instead of bridging
2817 # assumes 00:11:22:33:44:55 is local MAC address.
2818 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
2819 Set IPv4 DSCP header field.
2821 ip forward ip dscp set 42
2823 EXTENSION HEADER STATEMENT
2826 extension_header_expression set value
2827 The extension header statement alters packet content in variable-sized
2829 headers. This can currently be used to alter the TCP Maximum segment
2830 size of packets, similar to TCPMSS.
2831 change tcp mss.
2833 tcp flags syn tcp option maxseg size set 1360
2835 # set a size based on route information:
2836 tcp flags syn tcp option maxseg size set rt mtu
2837 LOG STATEMENT
2840 log [prefix quoted_string] [level syslog-level] [flags log-flags]
2841 log group nflog_group [prefix quoted_string] [queue-threshold value] [snaplen size]
2842 log level audit
2843 The log statement enables logging of matching packets. When this
2845 statement is used from a rule, the Linux kernel will print some
2846 information on all matching packets, such as header fields, via the
2847 kernel log (where it can be read with dmesg(1) or read in the syslog).
2848 In the second form of invocation (if nflog_group is specified), the
2850 Linux kernel will pass the packet to nfnetlink_log which will multicast
2851 the packet through a netlink socket to the specified multicast group.
2852 One or more userspace processes may subscribe to the group to receive
2853 the packets, see libnetfilter_queue documentation for details.
2854 In the third form of invocation (if level audit is specified), the
2856 Linux kernel writes a message into the audit buffer suitably formatted
2857 for reading with auditd. Therefore no further formatting options (such
2858 as prefix or flags) are allowed in this mode.
2859 This is a non-terminating statement, so the rule evaluation continues
2861 after the packet is logged.
2862 Table 54. log statement options
2864 ┌────────────────┬─────────────────────┬───────────────────┐
2865 │Keyword │ Description │ Type │
2866 ├────────────────┼─────────────────────┼───────────────────┤
2867 │ │ │ │
2868 │prefix │ Log message prefix │ quoted string │
2869 ├────────────────┼─────────────────────┼───────────────────┤
2870 │ │ │ │
2871 │level │ Syslog level of │ string: emerg, │
2872 │ │ logging │ alert, crit, err, │
2873 │ │ │ warn [default], │
2874 │ │ │ notice, info, │
2875 │ │ │ debug, audit │
2876 ├────────────────┼─────────────────────┼───────────────────┤
2877 │ │ │ │
2878 │group │ NFLOG group to send │ unsigned integer │
2879 │ │ messages to │ (16 bit) │
2880 ├────────────────┼─────────────────────┼───────────────────┤
2881 │ │ │ │
2882 │snaplen │ Length of packet │ unsigned integer │
2883 │ │ payload to include │ (32 bit) │
2884 │ │ in netlink message │ │
2885 ├────────────────┼─────────────────────┼───────────────────┤
2886 │ │ │ │
2887 │queue-threshold │ Number of packets │ unsigned integer │
2888 │ │ to queue inside the │ (32 bit) │
2889 │ │ kernel before │ │
2890 │ │ sending them to │ │
2891 │ │ userspace │ │
2892 └────────────────┴─────────────────────┴───────────────────┘
2893 Table 55. log-flags
2895 ┌─────────────┬───────────────────────────┐
2896 │Flag │ Description │
2897 ├─────────────┼───────────────────────────┤
2898 │ │ │
2899 │tcp sequence │ Log TCP sequence numbers. │
2900 ├─────────────┼───────────────────────────┤
2901 │ │ │
2902 │tcp options │ Log options from the TCP │
2903 │ │ packet header. │
2904 ├─────────────┼───────────────────────────┤
2905 │ │ │
2906 │ip options │ Log options from the │
2907 │ │ IP/IPv6 packet header. │
2908 ├─────────────┼───────────────────────────┤
2909 │ │ │
2910 │skuid │ Log the userid of the │
2911 │ │ process which generated │
2912 │ │ the packet. │
2913 ├─────────────┼───────────────────────────┤
2914 │ │ │
2915 │ether │ Decode MAC addresses and │
2916 │ │ protocol. │
2917 ├─────────────┼───────────────────────────┤
2918 │ │ │
2919 │all │ Enable all log flags │
2920 │ │ listed above. │
2921 └─────────────┴───────────────────────────┘
2922 Using log statement.
2924 # log the UID which generated the packet and ip options
2926 ip filter output log flags skuid flags ip options
2927 # log the tcp sequence numbers and tcp options from the TCP packet
2929 ip filter output log flags tcp sequence,options
2930 # enable all supported log flags
2932 ip6 filter output log flags all
2933 REJECT STATEMENT
2936 reject [ with REJECT_WITH ]
2937 REJECT_WITH := icmp type icmp_code |
2939 icmpv6 type icmpv6_code |
2940 icmpx type icmpx_code |
2941 tcp reset
2942 A reject statement is used to send back an error packet in response to
2944 the matched packet otherwise it is equivalent to drop so it is a
2945 terminating statement, ending rule traversal. This statement is only
2946 valid in the input, forward and output chains, and user-defined chains
2947 which are only called from those chains.
2948 Table 56. different ICMP reject variants are meant for use in different
2950 table families
2951 ┌────────┬────────┬─────────────┐
2952 │Variant │ Family │ Type │
2953 ├────────┼────────┼─────────────┤
2954 │ │ │ │
2955 │icmp │ ip │ icmp_code │
2956 ├────────┼────────┼─────────────┤
2957 │ │ │ │
2958 │icmpv6 │ ip6 │ icmpv6_code │
2959 ├────────┼────────┼─────────────┤
2960 │ │ │ │
2961 │icmpx │ inet │ icmpx_code │
2962 └────────┴────────┴─────────────┘
2963 For a description of the different types and a list of supported
2965 keywords refer to DATA TYPES section above. The common default reject
2966 value is port-unreachable.
2967 Note that in bridge family, reject statement is only allowed in base
2969 chains which hook into input or prerouting.
2970 COUNTER STATEMENT
2972 A counter statement sets the hit count of packets along with the number
2973 of bytes.
2974 counter packets number bytes number
2976 counter { packets number | bytes number }
2977 CONNTRACK STATEMENT
2979 The conntrack statement can be used to set the conntrack mark and
2980 conntrack labels.
2981 ct {mark | event | label | zone} set value
2983 The ct statement sets meta data associated with a connection. The zone
2985 id has to be assigned before a conntrack lookup takes place, i.e. this
2986 has to be done in prerouting and possibly output (if locally generated
2987 packets need to be placed in a distinct zone), with a hook priority of
2988 -300.
2989 Table 57. Conntrack statement types
2991 ┌────────┬─────────────────────┬──────────────────┐
2992 │Keyword │ Description │ Value │
2993 ├────────┼─────────────────────┼──────────────────┤
2994 │ │ │ │
2995 │event │ conntrack event │ bitmask, integer │
2996 │ │ bits │ (32 bit) │
2997 ├────────┼─────────────────────┼──────────────────┤
2998 │ │ │ │
2999 │helper │ name of ct helper │ quoted string │
3000 │ │ object to assign to │ │
3001 │ │ the connection │ │
3002 ├────────┼─────────────────────┼──────────────────┤
3003 │ │ │ │
3004 │mark │ Connection tracking │ mark │
3005 │ │ mark │ │
3006 ├────────┼─────────────────────┼──────────────────┤
3007 │ │ │ │
3008 │label │ Connection tracking │ label │
3009 │ │ label │ │
3010 ├────────┼─────────────────────┼──────────────────┤
3011 │ │ │ │
3012 │zone │ conntrack zone │ integer (16 bit) │
3013 └────────┴─────────────────────┴──────────────────┘
3014 save packet nfmark in conntrack.
3016 ct mark set meta mark
3018 set zone mapped via interface.
3020 table inet raw {
3022 chain prerouting {
3023 type filter hook prerouting priority -300;
3024 ct zone set iif map { "eth1" : 1, "veth1" : 2 }
3025 }
3026 chain output {
3027 type filter hook output priority -300;
3028 ct zone set oif map { "eth1" : 1, "veth1" : 2 }
3029 }
3030 }
3031 restrict events reported by ctnetlink.
3033 ct event set new,related,destroy
3035 META STATEMENT
3038 A meta statement sets the value of a meta expression. The existing meta
3039 fields are: priority, mark, pkttype, nftrace.
3040 meta {mark | priority | pkttype | nftrace} set value
3042 A meta statement sets meta data associated with a packet.
3044 Table 58. Meta statement types
3046 ┌─────────┬─────────────────────┬───────────┐
3047 │Keyword │ Description │ Value │
3048 ├─────────┼─────────────────────┼───────────┤
3049 │ │ │ │
3050 │priority │ TC packet priority │ tc_handle │
3051 ├─────────┼─────────────────────┼───────────┤
3052 │ │ │ │
3053 │mark │ Packet mark │ mark │
3054 ├─────────┼─────────────────────┼───────────┤
3055 │ │ │ │
3056 │pkttype │ packet type │ pkt_type │
3057 ├─────────┼─────────────────────┼───────────┤
3058 │ │ │ │
3059 │nftrace │ ruleset packet │ 0, 1 │
3060 │ │ tracing on/off. Use │ │
3061 │ │ monitor trace │ │
3062 │ │ command to watch │ │
3063 │ │ traces │ │
3064 └─────────┴─────────────────────┴───────────┘
3065 LIMIT STATEMENT
3067 limit rate [over] packet_number / TIME_UNIT [burst packet_number packets]
3068 limit rate [over] byte_number BYTE_UNIT / TIME_UNIT [burst byte_number BYTE_UNIT]
3069 TIME_UNIT := second | minute | hour | day
3071 BYTE_UNIT := bytes | kbytes | mbytes
3072 A limit statement matches at a limited rate using a token bucket
3074 filter. A rule using this statement will match until this limit is
3075 reached. It can be used in combination with the log statement to give
3076 limited logging. The optional over keyword makes it match over the
3077 specified rate.
3078 Table 59. limit statement values
3080 ┌──────────────┬───────────────────┬──────────────────┐
3081 │Value │ Description │ Type │
3082 ├──────────────┼───────────────────┼──────────────────┤
3083 │ │ │ │
3084 │packet_number │ Number of packets │ unsigned integer │
3085 │ │ │ (32 bit) │
3086 ├──────────────┼───────────────────┼──────────────────┤
3087 │ │ │ │
3088 │byte_number │ Number of bytes │ unsigned integer │
3089 │ │ │ (32 bit) │
3090 └──────────────┴───────────────────┴──────────────────┘
3091 NAT STATEMENTS
3093 snat to address [:port] [PRF_FLAGS]
3094 snat to address - address [:port - port] [PRF_FLAGS]
3095 snat to { ip | ip6 } address - address [:port - port] [PR_FLAGS]
3096 dnat to address [:port] [PRF_FLAGS]
3097 dnat to address [:port - port] [PR_FLAGS]
3098 dnat to { ip | ip6 } address [:port - port] [PR_FLAGS]
3099 masquerade to [:port] [PRF_FLAGS]
3100 masquerade to [:port - port] [PRF_FLAGS]
3101 redirect to [:port] [PRF_FLAGS]
3102 redirect to [:port - port] [PRF_FLAGS]
3103 PRF_FLAGS := PRF_FLAG [, PRF_FLAGS]
3105 PR_FLAGS := PR_FLAG [, PR_FLAGS]
3106 PRF_FLAG := PR_FLAG | fully-random
3107 PR_FLAG := persistent | random
3108 The nat statements are only valid from nat chain types.
3110 The snat and masquerade statements specify that the source address of
3112 the packet should be modified. While snat is only valid in the
3113 postrouting and input chains, masquerade makes sense only in
3114 postrouting. The dnat and redirect statements are only valid in the
3115 prerouting and output chains, they specify that the destination address
3116 of the packet should be modified. You can use non-base chains which are
3117 called from base chains of nat chain type too. All future packets in
3118 this connection will also be mangled, and rules should cease being
3119 examined.
3120 The masquerade statement is a special form of snat which always uses
3122 the outgoing interface’s IP address to translate to. It is particularly
3123 useful on gateways with dynamic (public) IP addresses.
3124 The redirect statement is a special form of dnat which always
3126 translates the destination address to the local host’s one. It comes in
3127 handy if one only wants to alter the destination port of incoming
3128 traffic on different interfaces.
3129 When used in the inet family (available with kernel 5.2), the dnat and
3131 snat statements require the use of the ip and ip6 keyword in case an
3132 address is provided, see the examples below.
3133 Before kernel 4.18 nat statements require both prerouting and
3135 postrouting base chains to be present since otherwise packets on the
3136 return path won’t be seen by netfilter and therefore no reverse
3137 translation will take place.
3138 Table 60. NAT statement values
3140 ┌───────────┬─────────────────────┬─────────────────────┐
3141 │Expression │ Description │ Type │
3142 ├───────────┼─────────────────────┼─────────────────────┤
3143 │ │ │ │
3144 │address │ Specifies that the │ ipv4_addr, │
3145 │ │ source/destination │ ipv6_addr, e.g. │
3146 │ │ address of the │ abcd::1234, or you │
3147 │ │ packet should be │ can use a mapping, │
3148 │ │ modified. You may │ e.g. meta mark map │
3149 │ │ specify a mapping │ { 10 : 192.168.1.2, │
3150 │ │ to relate a list of │ 20 : 192.168.1.3 } │
3151 │ │ tuples composed of │ │
3152 │ │ arbitrary │ │
3153 │ │ expression key with │ │
3154 │ │ address value. │ │
3155 ├───────────┼─────────────────────┼─────────────────────┤
3156 │ │ │ │
3157 │port │ Specifies that the │ port number (16 │
3158 │ │ source/destination │ bit) │
3159 │ │ address of the │ │
3160 │ │ packet should be │ │
3161 │ │ modified. │ │
3162 └───────────┴─────────────────────┴─────────────────────┘
3163 Table 61. NAT statement flags
3165 ┌─────────────┬─────────────────────────────┐
3166 │Flag │ Description │
3167 ├─────────────┼─────────────────────────────┤
3168 │ │ │
3169 │persistent │ Gives a client the same │
3170 │ │ source-/destination-address │
3171 │ │ for each connection. │
3172 ├─────────────┼─────────────────────────────┤
3173 │ │ │
3174 │random │ In kernel 5.0 and newer │
3175 │ │ this is the same as │
3176 │ │ fully-random. In earlier │
3177 │ │ kernels the port mapping │
3178 │ │ will be randomized using a │
3179 │ │ seeded MD5 hash mix using │
3180 │ │ source and destination │
3181 │ │ address and destination │
3182 │ │ port. │
3183 ├─────────────┼─────────────────────────────┤
3184 │ │ │
3185 │fully-random │ If used then port mapping │
3186 │ │ is generated based on a │
3187 │ │ 32-bit pseudo-random │
3188 │ │ algorithm. │
3189 └─────────────┴─────────────────────────────┘
3190 Using NAT statements.
3192 # create a suitable table/chain setup for all further examples
3194 add table nat
3195 add chain nat prerouting { type nat hook prerouting priority 0; }
3196 add chain nat postrouting { type nat hook postrouting priority 100; }
3197 # translate source addresses of all packets leaving via eth0 to address 1.2.3.4
3199 add rule nat postrouting oif eth0 snat to 1.2.3.4
3200 # redirect all traffic entering via eth0 to destination address 192.168.1.120
3202 add rule nat prerouting iif eth0 dnat to 192.168.1.120
3203 # translate source addresses of all packets leaving via eth0 to whatever
3205 # locally generated packets would use as source to reach the same destination
3206 add rule nat postrouting oif eth0 masquerade
3207 # redirect incoming TCP traffic for port 22 to port 2222
3209 add rule nat prerouting tcp dport 22 redirect to :2222
3210 # inet family:
3212 # handle ip dnat:
3213 add rule inet nat prerouting dnat ip to 10.0.2.99
3214 # handle ip6 dnat:
3215 add rule inet nat prerouting dnat ip6 to fe80::dead
3216 # this masquerades both ipv4 and ipv6:
3217 add rule inet nat postrouting meta oif ppp0 masquerade
3218 TPROXY STATEMENT
3221 Tproxy redirects the packet to a local socket without changing the
3222 packet header in any way. If any of the arguments is missing the data
3223 of the incoming packet is used as parameter. Tproxy matching requires
3224 another rule that ensures the presence of transport protocol header is
3225 specified.
3226 tproxy to address:port
3228 tproxy to {address | :port}
3229 This syntax can be used in ip/ip6 tables where network layer protocol
3231 is obvious. Either IP address or port can be specified, but at least
3232 one of them is necessary.
3233 tproxy {ip | ip6} to address[:port]
3235 tproxy to :port
3236 This syntax can be used in inet tables. The ip/ip6 parameter defines
3238 the family the rule will match. The address parameter must be of this
3239 family. When only port is defined, the address family should not be
3240 specified. In this case the rule will match for both families.
3241 Table 62. tproxy attributes
3243 ┌────────┬────────────────────────────┐
3244 │Name │ Description │
3245 ├────────┼────────────────────────────┤
3246 │ │ │
3247 │address │ IP address the listening │
3248 │ │ socket with IP_TRANSPARENT │
3249 │ │ option is bound to. │
3250 ├────────┼────────────────────────────┤
3251 │ │ │
3252 │port │ Port the listening socket │
3253 │ │ with IP_TRANSPARENT option │
3254 │ │ is bound to. │
3255 └────────┴────────────────────────────┘
3256 Example ruleset for tproxy statement.
3258 table ip x {
3260 chain y {
3261 type filter hook prerouting priority -150; policy accept;
3262 tcp dport ntp tproxy to 1.1.1.1
3263 udp dport ssh tproxy to :2222
3264 }
3265 }
3266 table ip6 x {
3267 chain y {
3268 type filter hook prerouting priority -150; policy accept;
3269 tcp dport ntp tproxy to [dead::beef]
3270 udp dport ssh tproxy to :2222
3271 }
3272 }
3273 table inet x {
3274 chain y {
3275 type filter hook prerouting priority -150; policy accept;
3276 tcp dport 321 tproxy to :ssh
3277 tcp dport 99 tproxy ip to 1.1.1.1:999
3278 udp dport 155 tproxy ip6 to [dead::beef]:smux
3279 }
3280 }
3281 FLOW STATEMENT
3284 A flow statement allows us to select what flows you want to accelerate
3285 forwarding through layer 3 network stack bypass. You have to specify
3286 the flowtable name where you want to offload this flow.
3287 flow add @flowtable
3289 QUEUE STATEMENT
3291 This statement passes the packet to userspace using the nfnetlink_queue
3292 handler. The packet is put into the queue identified by its 16-bit
3293 queue number. Userspace can inspect and modify the packet if desired.
3294 Userspace must then drop or re-inject the packet into the kernel. See
3295 libnetfilter_queue documentation for details.
3296 queue [num queue_number] [bypass]
3298 queue [num queue_number_from - queue_number_to] [QUEUE_FLAGS]
3299 QUEUE_FLAGS := QUEUE_FLAG [, QUEUE_FLAGS]
3301 QUEUE_FLAG := bypass | fanout
3302 Table 63. queue statement values
3304 ┌──────────────────┬────────────────────┬──────────────────┐
3305 │Value │ Description │ Type │
3306 ├──────────────────┼────────────────────┼──────────────────┤
3307 │ │ │ │
3308 │queue_number │ Sets queue number, │ unsigned integer │
3309 │ │ default is 0. │ (16 bit) │
3310 ├──────────────────┼────────────────────┼──────────────────┤
3311 │ │ │ │
3312 │queue_number_from │ Sets initial queue │ unsigned integer │
3313 │ │ in the range, if │ (16 bit) │
3314 │ │ fanout is used. │ │
3315 ├──────────────────┼────────────────────┼──────────────────┤
3316 │ │ │ │
3317 │queue_number_to │ Sets closing queue │ unsigned integer │
3318 │ │ in the range, if │ (16 bit) │
3319 │ │ fanout is used. │ │
3320 └──────────────────┴────────────────────┴──────────────────┘
3321 Table 64. queue statement flags
3323 ┌───────┬────────────────────────────┐
3324 │Flag │ Description │
3325 ├───────┼────────────────────────────┤
3326 │ │ │
3327 │bypass │ Let packets go through if │
3328 │ │ userspace application │
3329 │ │ cannot back off. Before │
3330 │ │ using this flag, read │
3331 │ │ libnetfilter_queue │
3332 │ │ documentation for │
3333 │ │ performance tuning │
3334 │ │ recommendations. │
3335 ├───────┼────────────────────────────┤
3336 │ │ │
3337 │fanout │ Distribute packets between │
3338 │ │ several queues. │
3339 └───────┴────────────────────────────┘
3340 DUP STATEMENT
3342 The dup statement is used to duplicate a packet and send the copy to a
3343 different destination.
3344 dup to device
3346 dup to address device device
3347 Table 65. Dup statement values
3349 ┌───────────┬─────────────────────┬─────────────────────┐
3350 │Expression │ Description │ Type │
3351 ├───────────┼─────────────────────┼─────────────────────┤
3352 │ │ │ │
3353 │address │ Specifies that the │ ipv4_addr, │
3354 │ │ copy of the packet │ ipv6_addr, e.g. │
3355 │ │ should be sent to a │ abcd::1234, or you │
3356 │ │ new gateway. │ can use a mapping, │
3357 │ │ │ e.g. ip saddr map { │
3358 │ │ │ 192.168.1.2 : │
3359 │ │ │ 10.1.1.1 } │
3360 ├───────────┼─────────────────────┼─────────────────────┤
3361 │ │ │ │
3362 │device │ Specifies that the │ string │
3363 │ │ copy should be │ │
3364 │ │ transmitted via │ │
3365 │ │ device. │ │
3366 └───────────┴─────────────────────┴─────────────────────┘
3367 Using the dup statement.
3369 # send to machine with ip address 10.2.3.4 on eth0
3371 ip filter forward dup to 10.2.3.4 device "eth0"
3372 # copy raw frame to another interface
3374 netdetv ingress dup to "eth0"
3375 dup to "eth0"
3376 # combine with map dst addr to gateways
3378 dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" }
3379 FWD STATEMENT
3382 The fwd statement is used to redirect a raw packet to another
3383 interface. It is only available in the netdev family ingress hook. It
3384 is similar to the dup statement except that no copy is made.
3385 fwd to device
3387 SET STATEMENT
3389 The set statement is used to dynamically add or update elements in a
3390 set from the packet path. The set setname must already exist in the
3391 given table and must have been created with the dynamic flag.
3392 Furthermore, these sets must specify both a maximum set size (to
3393 prevent memory exhaustion) and a timeout (so that number of entries in
3394 set will not grow indefinitely). The set statement can be used to e.g.
3395 create dynamic blacklists.
3396 {add | update} @setname { expression [timeout timeout] [comment string] }
3398 Example for simple blacklist.
3400 # declare a set, bound to table "filter", in family "ip". Timeout and size are mandatory because we will add elements from packet path.
3402 nft add set ip filter blackhole "{ type ipv4_addr; flags timeout; size 65536; }"
3403 # whitelist internal interface.
3405 nft add rule ip filter input meta iifname "internal" accept
3406 # drop packets coming from blacklisted ip addresses.
3408 nft add rule ip filter input ip saddr @blackhole counter drop
3409 # add source ip addresses to the blacklist if more than 10 tcp connection requests occurred per second and ip address.
3411 # entries will timeout after one minute, after which they might be re-added if limit condition persists.
3412 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
3413 # inspect state of the rate limit meter:
3415 nft list meter ip filter flood
3416 # inspect content of blackhole:
3418 nft list set ip filter blackhole
3419 # manually add two addresses to the set:
3421 nft add element filter blackhole { 10.2.3.4, 10.23.1.42 }
3422 MAP STATEMENT
3425 The map statement is used to lookup data based on some specific input
3426 key.
3427 expression map { MAP_ELEMENTS }
3429 MAP_ELEMENTS := MAP_ELEMENT [, MAP_ELEMENTS]
3431 MAP_ELEMENT := key : value
3432 The key is a value returned by expression.
3434 Using the map statement.
3436 # select DNAT target based on TCP dport:
3438 # connections to port 80 are redirected to 192.168.1.100,
3439 # connections to port 8888 are redirected to 192.168.1.101
3440 nft add rule ip nat prerouting dnat tcp dport map { 80 : 192.168.1.100, 8888 : 192.168.1.101 }
3441 # source address based SNAT:
3443 # packets from net 192.168.1.0/24 will appear as originating from 10.0.0.1,
3444 # packets from net 192.168.2.0/24 will appear as originating from 10.0.0.2
3445 nft add rule ip nat postrouting snat to ip saddr map { 192.168.1.0/24 : 10.0.0.1, 192.168.2.0/24 : 10.0.0.2 }
3446 VMAP STATEMENT
3449 The verdict map (vmap) statement works analogous to the map statement,
3450 but contains verdicts as values.
3451 expression vmap { VMAP_ELEMENTS }
3453 VMAP_ELEMENTS := VMAP_ELEMENT [, VMAP_ELEMENTS]
3455 VMAP_ELEMENT := key : verdict
3456 Using the vmap statement.
3458 # jump to different chains depending on layer 4 protocol type:
3460 nft add rule ip filter input ip protocol vmap { tcp : jump tcp-chain, udp : jump udp-chain , icmp : jump icmp-chain }
3461
3464 These are some additional commands included in nft.
3465 MONITOR
3467 The monitor command allows you to listen to Netlink events produced by
3468 the nf_tables subsystem, related to creation and deletion of objects.
3469 When they occur, nft will print to stdout the monitored events in
3470 either JSON or native nft format.
3471 To filter events related to a concrete object, use one of the keywords
3473 tables, chains, sets, rules, elements, ruleset.
3474 To filter events related to a concrete action, use keyword new or
3476 destroy.
3477 Hit ^C to finish the monitor operation.
3479 Listen to all events, report in native nft format.
3481 % nft monitor
3483 Listen to deleted rules, report in JSON format.
3485 % nft -j monitor destroy rules
3487 Listen to both new and destroyed chains, in native nft format.
3489 % nft monitor chains
3491 Listen to ruleset events such as table, chain, rule, set, counters and
3493 quotas, in native nft format.
3494 % nft monitor ruleset
3496
3499 When an error is detected, nft shows the line(s) containing the error,
3500 the position of the erroneous parts in the input stream and marks up
3501 the erroneous parts using carets (^). If the error results from the
3502 combination of two expressions or statements, the part imposing the
3503 constraints which are violated is marked using tildes (~).
3504 For errors returned by the kernel, nft cannot detect which parts of the
3506 input caused the error and the entire command is marked.
3507 Error caused by single incorrect expression.
3509 <cmdline>:1:19-22: Error: Interface does not exist
3511 filter output oif eth0
3512 ^^^^
3513 Error caused by invalid combination of two expressions.
3515 <cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
3517 filter output tcp dport == tcp dport
3518 ~~ ^^^^^^^^^
3519 Error returned by the kernel.
3521 <cmdline>:0:0-23: Error: Could not process rule: Operation not permitted
3523 filter output oif wlan0
3524 ^^^^^^^^^^^^^^^^^^^^^^^
3525
3528 On success, nft exits with a status of 0. Unspecified errors cause it
3529 to exit with a status of 1, memory allocation errors with a status of
3530 2, unable to open Netlink socket with 3.
3531
3533 libnftables(3), libnftables-json(5), iptables(8), ip6tables(8), arptables(8), ebtables(8), ip(8), tc(8)
3534 There is an official wiki at: https://wiki.nftables.org
3536
3538 nftables was written by Patrick McHardy and Pablo Neira Ayuso, among
3539 many other contributors from the Netfilter community.
3540
3542 Copyright © 2008-2014 Patrick McHardy <kaber@trash.net> Copyright ©
3543 2013-2018 Pablo Neira Ayuso <pablo@netfilter.org>
3544 nftables is free software; you can redistribute it and/or modify it
3546 under the terms of the GNU General Public License version 2 as
3547 published by the Free Software Foundation.
3548 This documentation is licensed under the terms of the Creative Commons
3550 Attribution-ShareAlike 4.0 license, CC BY-SA 4.0
3551 http://creativecommons.org/licenses/by-sa/4.0/.
3552 07/25/2019 NFT(8)