1NFT(8) NFT(8)
2
6 nft - Administration tool of the nftables framework for packet
7 filtering and classification
8
10 nft [ -nNscaeSupyjt ] [ -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 -i, --interactive
75 Read input from an interactive readline CLI. You can use quit to
76 exit, or use the EOF marker, normally this is CTRL-D.
77 -T, --numeric-time
79 Show time, day and hour values in numeric format.
80 -t, --terse
82 Omit contents of sets from output.
83
85 LEXICAL CONVENTIONS
86 Input is parsed line-wise. When the last character of a line, just
87 before the newline character, is a non-quoted backslash (\), the next
88 line is treated as a continuation. Multiple commands on the same line
89 can be separated using a semicolon (;).
90 A hash sign (#) begins a comment. All following characters on the same
92 line are ignored.
93 Identifiers begin with an alphabetic character (a-z,A-Z), followed zero
95 or more alphanumeric characters (a-z,A-Z,0-9) and the characters slash
96 (/), backslash (\), underscore (_) and dot (.). Identifiers using
97 different characters or clashing with a keyword need to be enclosed in
98 double quotes (").
99 INCLUDE FILES
101 include filename
102 Other files can be included by using the include statement. The
104 directories to be searched for include files can be specified using the
105 -I/--includepath option. You can override this behaviour either by
106 prepending ‘./’ to your path to force inclusion of files located in the
107 current working directory (i.e. relative path) or / for file location
108 expressed as an absolute path.
109 If -I/--includepath is not specified, then nft relies on the default
111 directory that is specified at compile time. You can retrieve this
112 default directory via -h/--help option.
113 Include statements support the usual shell wildcard symbols (\*,?,[]).
115 Having no matches for an include statement is not an error, if wildcard
116 symbols are used in the include statement. This allows having
117 potentially empty include directories for statements like include
118 "/etc/firewall/rules/". The wildcard matches are loaded in alphabetical
119 order. Files beginning with dot (.) are not matched by include
120 statements.
121 SYMBOLIC VARIABLES
123 define variable = expr
124 $variable
125 Symbolic variables can be defined using the define statement. Variable
127 references are expressions and can be used initialize other variables.
128 The scope of a definition is the current block and all blocks contained
129 within.
130 Using symbolic variables.
132 define int_if1 = eth0
134 define int_if2 = eth1
135 define int_ifs = { $int_if1, $int_if2 }
136 filter input iif $int_ifs accept
138
141 Address families determine the type of packets which are processed. For
142 each address family, the kernel contains so called hooks at specific
143 stages of the packet processing paths, which invoke nftables if rules
144 for these hooks exist.
145 ip IPv4 address family.
148 ip6 IPv6 address family.
150 inet Internet (IPv4/IPv6)
152 address family.
153 arp ARP address family,
155 handling IPv4 ARP packets.
156 bridge Bridge address family,
158 handling packets which
159 traverse a bridge device.
160 netdev Netdev address family,
162 handling packets from
163 ingress.
164 All nftables objects exist in address family specific namespaces,
167 therefore all identifiers include an address family. If an identifier
168 is specified without an address family, the ip family is used by
169 default.
170 IPV4/IPV6/INET ADDRESS FAMILIES
172 The IPv4/IPv6/Inet address families handle IPv4, IPv6 or both types of
173 packets. They contain five hooks at different packet processing stages
174 in the network stack.
175 Table 1. IPv4/IPv6/Inet address family hooks
177 ┌────────────┬────────────────────────────┐
178 │Hook │ Description │
179 ├────────────┼────────────────────────────┤
180 │ │ │
181 │prerouting │ All packets entering the │
182 │ │ system are processed by │
183 │ │ the prerouting hook. It is │
184 │ │ invoked before the routing │
185 │ │ process and is used for │
186 │ │ early filtering or │
187 │ │ changing packet attributes │
188 │ │ that affect routing. │
189 ├────────────┼────────────────────────────┤
190 │ │ │
191 │input │ Packets delivered to the │
192 │ │ local system are processed │
193 │ │ by the input hook. │
194 ├────────────┼────────────────────────────┤
195 │ │ │
196 │forward │ Packets forwarded to a │
197 │ │ different host are │
198 │ │ processed by the forward │
199 │ │ hook. │
200 ├────────────┼────────────────────────────┤
201 │ │ │
202 │output │ Packets sent by local │
203 │ │ processes are processed by │
204 │ │ the output hook. │
205 ├────────────┼────────────────────────────┤
206 │ │ │
207 │postrouting │ All packets leaving the │
208 │ │ system are processed by │
209 │ │ the postrouting hook. │
210 └────────────┴────────────────────────────┘
211 ARP ADDRESS FAMILY
213 The ARP address family handles ARP packets received and sent by the
214 system. It is commonly used to mangle ARP packets for clustering.
215 Table 2. ARP address family hooks
217 ┌───────┬────────────────────────────┐
218 │Hook │ Description │
219 ├───────┼────────────────────────────┤
220 │ │ │
221 │input │ Packets delivered to the │
222 │ │ local system are processed │
223 │ │ by the input hook. │
224 ├───────┼────────────────────────────┤
225 │ │ │
226 │output │ Packets send by the local │
227 │ │ system are processed by │
228 │ │ the output hook. │
229 └───────┴────────────────────────────┘
230 BRIDGE ADDRESS FAMILY
232 The bridge address family handles Ethernet packets traversing bridge
233 devices.
234 The list of supported hooks is identical to IPv4/IPv6/Inet address
236 families above.
237 NETDEV ADDRESS FAMILY
239 The Netdev address family handles packets from ingress.
240 Table 3. Netdev address family hooks
242 ┌────────┬──────────────────────────┐
243 │Hook │ Description │
244 ├────────┼──────────────────────────┤
245 │ │ │
246 │ingress │ All packets entering the │
247 │ │ system are processed by │
248 │ │ this hook. It is invoked │
249 │ │ before layer 3 protocol │
250 │ │ handlers and it can be │
251 │ │ used for early filtering │
252 │ │ and policing. │
253 └────────┴──────────────────────────┘
254
256 {list | flush} ruleset [family]
257 The ruleset keyword is used to identify the whole set of tables,
259 chains, etc. currently in place in kernel. The following ruleset
260 commands exist:
261 list Print the ruleset in
264 human-readable format.
265 flush Clear the whole ruleset.
267 Note that, unlike
268 iptables, this will remove
269 all tables and whatever
270 they contain, effectively
271 leading to an empty
272 ruleset - no packet
273 filtering will happen
274 anymore, so the kernel
275 accepts any valid packet
276 it receives.
277 It is possible to limit list and flush to a specific address family
280 only. For a list of valid family names, see the section called “ADDRESS
281 FAMILIES” above.
282 By design, list ruleset command output may be used as input to nft -f.
284 Effectively, this is the nft-equivalent of iptables-save and
285 iptables-restore.
286
288 {add | create} table [family] table [{ flags flags ; }]
289 {delete | list | flush} table [family] table
290 list tables [family]
291 delete table [family] handle handle
292 Tables are containers for chains, sets and stateful objects. They are
294 identified by their address family and their name. The address family
295 must be one of ip, ip6, inet, arp, bridge, netdev. The inet address
296 family is a dummy family which is used to create hybrid IPv4/IPv6
297 tables. The meta expression nfproto keyword can be used to test which
298 family (ipv4 or ipv6) context the packet is being processed in. When no
299 address family is specified, ip is used by default. The only difference
300 between add and create is that the former will not return an error if
301 the specified table already exists while create will return an error.
302 Table 4. Table flags
304 ┌────────┬────────────────────────────┐
305 │Flag │ Description │
306 ├────────┼────────────────────────────┤
307 │ │ │
308 │dormant │ table is not evaluated any │
309 │ │ more (base chains are │
310 │ │ unregistered). │
311 └────────┴────────────────────────────┘
312 Add, change, delete a table.
314 # start nft in interactive mode
316 nft --interactive
317 # create a new table.
319 create table inet mytable
320 # add a new base chain: get input packets
322 add chain inet mytable myin { type filter hook input priority 0; }
323 # add a single counter to the chain
325 add rule inet mytable myin counter
326 # disable the table temporarily -- rules are not evaluated anymore
328 add table inet mytable { flags dormant; }
329 # make table active again:
331 add table inet mytable
332 add Add a new table for the
336 given family with the
337 given name.
338 delete Delete the specified
340 table.
341 list List all chains and rules
343 of the specified table.
344 flush Flush all chains and rules
346 of the specified table.
347
350 {add | create} chain [family] table chain [{ type type hook hook [device device] priority priority ; [policy policy ;] }]
351 {delete | list | flush} chain [family] table chain
352 list chains [family]
353 delete chain [family] table handle handle
354 rename chain [family] table chain newname
355 Chains are containers for rules. They exist in two kinds, base chains
357 and regular chains. A base chain is an entry point for packets from the
358 networking stack, a regular chain may be used as jump target and is
359 used for better rule organization.
360 add Add a new chain in the
363 specified table. When a
364 hook and priority value
365 are specified, the chain
366 is created as a base chain
367 and hooked up to the
368 networking stack.
369 create Similar to the add
372 command, but returns an
373 error if the chain already
374 exists.
375 delete Delete the specified
377 chain. The chain must not
378 contain any rules or be
379 used as jump target.
380 rename Rename the specified
382 chain.
383 list List all rules of the
385 specified chain.
386 flush Flush all rules of the
388 specified chain.
389 For base chains, type, hook and priority parameters are mandatory.
392 Table 5. Supported chain types
394 ┌───────┬───────────────┬────────────────┬──────────────────┐
395 │Type │ Families │ Hooks │ Description │
396 ├───────┼───────────────┼────────────────┼──────────────────┤
397 │ │ │ │ │
398 │filter │ all │ all │ Standard chain │
399 │ │ │ │ type to use in │
400 │ │ │ │ doubt. │
401 ├───────┼───────────────┼────────────────┼──────────────────┤
402 │ │ │ │ │
403 │nat │ ip, ip6, inet │ prerouting, │ Chains of this │
404 │ │ │ input, output, │ type perform │
405 │ │ │ postrouting │ Native Address │
406 │ │ │ │ Translation │
407 │ │ │ │ based on │
408 │ │ │ │ conntrack │
409 │ │ │ │ entries. Only │
410 │ │ │ │ the first packet │
411 │ │ │ │ of a connection │
412 │ │ │ │ actually │
413 │ │ │ │ traverses this │
414 │ │ │ │ chain - its │
415 │ │ │ │ rules usually │
416 │ │ │ │ define details │
417 │ │ │ │ of the created │
418 │ │ │ │ conntrack entry │
419 │ │ │ │ (NAT statements │
420 │ │ │ │ for instance). │
421 ├───────┼───────────────┼────────────────┼──────────────────┤
422 │ │ │ │ │
423 │route │ ip, ip6 │ output │ If a packet has │
424 │ │ │ │ traversed a │
425 │ │ │ │ chain of this │
426 │ │ │ │ type and is │
427 │ │ │ │ about to be │
428 │ │ │ │ accepted, a new │
429 │ │ │ │ route lookup is │
430 │ │ │ │ performed if │
431 │ │ │ │ relevant parts │
432 │ │ │ │ of the IP header │
433 │ │ │ │ have changed. │
434 │ │ │ │ This allows to │
435 │ │ │ │ e.g. implement │
436 │ │ │ │ policy routing │
437 │ │ │ │ selectors in │
438 │ │ │ │ nftables. │
439 └───────┴───────────────┴────────────────┴──────────────────┘
440 Apart from the special cases illustrated above (e.g. nat type not
442 supporting forward hook or route type only supporting output hook),
443 there are two further quirks worth noticing:
444 · The netdev family supports merely a single combination, namely
446 filter type and ingress hook. Base chains in this family also
447 require the device parameter to be present since they exist per
448 incoming interface only.
449 · The arp family supports only the input and output hooks, both in
451 chains of type filter.
452 The priority parameter accepts a signed integer value or a standard
454 priority name which specifies the order in which chains with same hook
455 value are traversed. The ordering is ascending, i.e. lower priority
456 values have precedence over higher ones.
457 Standard priority values can be replaced with easily memorizable names.
459 Not all names make sense in every family with every hook (see the
460 compatibility matrices below) but their numerical value can still be
461 used for prioritizing chains.
462 These names and values are defined and made available based on what
464 priorities are used by xtables when registering their default chains.
465 Most of the families use the same values, but bridge uses different
467 ones from the others. See the following tables that describe the values
468 and compatibility.
469 Table 6. Standard priority names, family and hook compatibility matrix
471 ┌─────────┬───────┬────────────────┬─────────────┐
472 │Name │ Value │ Families │ Hooks │
473 ├─────────┼───────┼────────────────┼─────────────┤
474 │ │ │ │ │
475 │raw │ -300 │ ip, ip6, inet │ all │
476 ├─────────┼───────┼────────────────┼─────────────┤
477 │ │ │ │ │
478 │mangle │ -150 │ ip, ip6, inet │ all │
479 ├─────────┼───────┼────────────────┼─────────────┤
480 │ │ │ │ │
481 │dstnat │ -100 │ ip, ip6, inet │ prerouting │
482 ├─────────┼───────┼────────────────┼─────────────┤
483 │ │ │ │ │
484 │filter │ 0 │ ip, ip6, inet, │ all │
485 │ │ │ arp, netdev │ │
486 ├─────────┼───────┼────────────────┼─────────────┤
487 │ │ │ │ │
488 │security │ 50 │ ip, ip6, inet │ all │
489 ├─────────┼───────┼────────────────┼─────────────┤
490 │ │ │ │ │
491 │srcnat │ 100 │ ip, ip6, inet │ postrouting │
492 └─────────┴───────┴────────────────┴─────────────┘
493 Table 7. Standard priority names and hook compatibility for the bridge
495 family
496 ┌───────┬───────┬─────────────┐
497 │ │ │ │
498 │Name │ Value │ Hooks │
499 ├───────┼───────┼─────────────┤
500 │ │ │ │
501 │dstnat │ -300 │ prerouting │
502 ├───────┼───────┼─────────────┤
503 │ │ │ │
504 │filter │ -200 │ all │
505 ├───────┼───────┼─────────────┤
506 │ │ │ │
507 │out │ 100 │ output │
508 ├───────┼───────┼─────────────┤
509 │ │ │ │
510 │srcnat │ 300 │ postrouting │
511 └───────┴───────┴─────────────┘
512 Basic arithmetic expressions (addition and subtraction) can also be
514 achieved with these standard names to ease relative prioritizing, e.g.
515 mangle - 5 stands for -155. Values will also be printed like this until
516 the value is not further than 10 form the standard value.
517 Base chains also allow to set the chain’s policy, i.e. what happens to
519 packets not explicitly accepted or refused in contained rules.
520 Supported policy values are accept (which is the default) or drop.
521
523 {add | insert} rule [family] table chain [handle handle | index index] statement ... [comment comment]
524 replace rule [family] table chain handle handle statement ... [comment comment]
525 delete rule [family] table chain handle handle
526 Rules are added to chains in the given table. If the family is not
528 specified, the ip family is used. Rules are constructed from two kinds
529 of components according to a set of grammatical rules: expressions and
530 statements.
531 The add and insert commands support an optional location specifier,
533 which is either a handle or the index (starting at zero) of an existing
534 rule. Internally, rule locations are always identified by handle and
535 the translation from index happens in userspace. This has two potential
536 implications in case a concurrent ruleset change happens after the
537 translation was done: The effective rule index might change if a rule
538 was inserted or deleted before the referred one. If the referred rule
539 was deleted, the command is rejected by the kernel just as if an
540 invalid handle was given.
541 A comment is a single word or a double-quoted (") multi-word string
543 which can be used to make notes regarding the actual rule. Note: If you
544 use bash for adding rules, you have to escape the quotation marks, e.g.
545 \"enable ssh for servers\".
546 add Add a new rule described
549 by the list of statements.
550 The rule is appended to
551 the given chain unless a
552 location is specified, in
553 which case the rule is
554 inserted after the
555 specified rule.
556 insert Same as add except the
558 rule is inserted at the
559 beginning of the chain or
560 before the specified rule.
561 replace Similar to add, but the
563 rule replaces the
564 specified rule.
565 delete Delete the specified rule.
567 add a rule to ip table input chain.
570 nft add rule filter output ip daddr 192.168.0.0/24 accept # 'ip filter' is assumed
572 # same command, slightly more verbose
573 nft add rule ip filter output ip daddr 192.168.0.0/24 accept
574 delete rule from inet table.
576 # nft -a list ruleset
578 table inet filter {
579 chain input {
580 type filter hook input priority 0; policy accept;
581 ct state established,related accept # handle 4
582 ip saddr 10.1.1.1 tcp dport ssh accept # handle 5
583 ...
584 # delete the rule with handle 5
585 # nft delete rule inet filter input handle 5
586
589 nftables offers two kinds of set concepts. Anonymous sets are sets that
590 have no specific name. The set members are enclosed in curly braces,
591 with commas to separate elements when creating the rule the set is used
592 in. Once that rule is removed, the set is removed as well. They cannot
593 be updated, i.e. once an anonymous set is declared it cannot be changed
594 anymore except by removing/altering the rule that uses the anonymous
595 set.
596 Using anonymous sets to accept particular subnets and ports.
598 nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept
600 Named sets are sets that need to be defined first before they can be
602 referenced in rules. Unlike anonymous sets, elements can be added to or
603 removed from a named set at any time. Sets are referenced from rules
604 using an @ prefixed to the sets name.
605 Using named sets to accept addresses and ports.
607 nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept
609 The sets allowed_hosts and allowed_ports need to be created first. The
611 next section describes nft set syntax in more detail.
612 add set [family] table set { type type ; [flags flags ;] [timeout timeout ;] [gc-interval gc-interval ;] [elements = { element[, ...] } ;] [size size ;] [policy policy ;] [auto-merge ;] }
614 {delete | list | flush} set [family] table set
615 list sets [family]
616 delete set [family] table handle handle
617 {add | delete} element [family] table set { element[, ...] }
618 Sets are element containers of a user-defined data type, they are
620 uniquely identified by a user-defined name and attached to tables.
621 Their behaviour can be tuned with the flags that can be specified at
622 set creation time.
623 add Add a new set in the
626 specified table. See the
627 Set specification table
628 below for more information
629 about how to specify a
630 sets properties.
631 delete Delete the specified set.
633 list Display the elements in
635 the specified set.
636 flush Remove all elements from
638 the specified set.
639 add element Comma-separated list of
641 elements to add into the
642 specified set.
643 delete element Comma-separated list of
645 elements to delete from
646 the specified set.
647 Table 8. Set specifications
650 ┌────────────┬──────────────────────┬─────────────────────┐
651 │Keyword │ Description │ Type │
652 ├────────────┼──────────────────────┼─────────────────────┤
653 │ │ │ │
654 │type │ data type of set │ string: ipv4_addr, │
655 │ │ elements │ ipv6_addr, │
656 │ │ │ ether_addr, │
657 │ │ │ inet_proto, │
658 │ │ │ inet_service, mark │
659 ├────────────┼──────────────────────┼─────────────────────┤
660 │ │ │ │
661 │flags │ set flags │ string: constant, │
662 │ │ │ dynamic, interval, │
663 │ │ │ timeout │
664 ├────────────┼──────────────────────┼─────────────────────┤
665 │ │ │ │
666 │timeout │ time an element │ string, decimal │
667 │ │ stays in the set, │ followed by unit. │
668 │ │ mandatory if set is │ Units are: d, h, m, │
669 │ │ added to from the │ s │
670 │ │ packet path │ │
671 │ │ (ruleset). │ │
672 ├────────────┼──────────────────────┼─────────────────────┤
673 │ │ │ │
674 │gc-interval │ garbage collection │ string, decimal │
675 │ │ interval, only │ followed by unit. │
676 │ │ available when │ Units are: d, h, m, │
677 │ │ timeout or flag │ s │
678 │ │ timeout are active │ │
679 ├────────────┼──────────────────────┼─────────────────────┤
680 │ │ │ │
681 │elements │ elements contained │ set data type │
682 │ │ by the set │ │
683 ├────────────┼──────────────────────┼─────────────────────┤
684 │ │ │ │
685 │size │ maximum number of │ unsigned integer │
686 │ │ elements in the │ (64 bit) │
687 │ │ set, mandatory if │ │
688 │ │ set is added to │ │
689 │ │ from the packet │ │
690 │ │ path (ruleset). │ │
691 ├────────────┼──────────────────────┼─────────────────────┤
692 │ │ │ │
693 │policy │ set policy │ string: performance │
694 │ │ │ [default], memory │
695 ├────────────┼──────────────────────┼─────────────────────┤
696 │ │ │ │
697 │auto-merge │ automatic merge of │ │
698 │ │ adjacent/overlapping │ │
699 │ │ set elements (only │ │
700 │ │ for interval sets) │ │
701 └────────────┴──────────────────────┴─────────────────────┘
702
704 add map [family] table map { type type [flags flags ;] [elements = { element[, ...] } ;] [size size ;] [policy policy ;] }
705 {delete | list | flush} map [family] table map
706 list maps [family]
707 {add | delete} element [family] table map { elements = { element[, ...] } ; }
708 Maps store data based on some specific key used as input. They are
710 uniquely identified by a user-defined name and attached to tables.
711 add Add a new map in the
714 specified table.
715 delete Delete the specified map.
717 list Display the elements in
719 the specified map.
720 flush Remove all elements from
722 the specified map.
723 add element Comma-separated list of
725 elements to add into the
726 specified map.
727 delete element Comma-separated list of
729 element keys to delete
730 from the specified map.
731 Table 9. Map specifications
734 ┌─────────┬─────────────────────┬─────────────────────┐
735 │Keyword │ Description │ Type │
736 ├─────────┼─────────────────────┼─────────────────────┤
737 │ │ │ │
738 │type │ data type of map │ string ‘:’ string: │
739 │ │ elements │ ipv4_addr, │
740 │ │ │ ipv6_addr, │
741 │ │ │ ether_addr, │
742 │ │ │ inet_proto, │
743 │ │ │ inet_service, mark, │
744 │ │ │ counter, quota. │
745 │ │ │ Counter and quota │
746 │ │ │ can’t be used as │
747 │ │ │ keys │
748 ├─────────┼─────────────────────┼─────────────────────┤
749 │ │ │ │
750 │flags │ map flags │ string: constant, │
751 │ │ │ interval │
752 ├─────────┼─────────────────────┼─────────────────────┤
753 │ │ │ │
754 │elements │ elements contained │ map data type │
755 │ │ by the map │ │
756 ├─────────┼─────────────────────┼─────────────────────┤
757 │ │ │ │
758 │size │ maximum number of │ unsigned integer │
759 │ │ elements in the map │ (64 bit) │
760 ├─────────┼─────────────────────┼─────────────────────┤
761 │ │ │ │
762 │policy │ map policy │ string: performance │
763 │ │ │ [default], memory │
764 └─────────┴─────────────────────┴─────────────────────┘
765
767 {add | create} flowtable [family] table flowtable { hook hook priority priority ; devices = { device[, ...] } ; }
768 list flowtables [family]
769 {delete | list} flowtable [family] table flowtable
770 delete flowtable [family] table handle handle
771 Flowtables allow you to accelerate packet forwarding in software.
773 Flowtables entries are represented through a tuple that is composed of
774 the input interface, source and destination address, source and
775 destination port; and layer 3/4 protocols. Each entry also caches the
776 destination interface and the gateway address - to update the
777 destination link-layer address - to forward packets. The ttl and
778 hoplimit fields are also decremented. Hence, flowtables provides an
779 alternative path that allow packets to bypass the classic forwarding
780 path. Flowtables reside in the ingress hook that is located before the
781 prerouting hook. You can select which flows you want to offload through
782 the flow expression from the forward chain. Flowtables are identified
783 by their address family and their name. The address family must be one
784 of ip, ip6, or inet. The inet address family is a dummy family which is
785 used to create hybrid IPv4/IPv6 tables. When no address family is
786 specified, ip is used by default.
787 The priority can be a signed integer or filter which stands for 0.
789 Addition and subtraction can be used to set relative priority, e.g.
790 filter + 5 equals to 5.
791 add Add a new flowtable for
794 the given family with the
795 given name.
796 delete Delete the specified
801 flowtable.
802 list List all flowtables.
804
807 {add | delete | list | reset} type [family] table object
808 delete type [family] table handle handle
809 list counters [family]
810 list quotas [family]
811 Stateful objects are attached to tables and are identified by an unique
813 name. They group stateful information from rules, to reference them in
814 rules the keywords "type name" are used e.g. "counter name".
815 add Add a new stateful object
818 in the specified table.
819 delete Delete the specified
821 object.
822 list Display stateful
824 information the object
825 holds.
826 reset List-and-reset stateful
828 object.
829 CT HELPER
832 ct helper helper { type type protocol protocol ; [l3proto family ;] }
833 Ct helper is used to define connection tracking helpers that can then
835 be used in combination with the ct helper set statement. type and
836 protocol are mandatory, l3proto is derived from the table family by
837 default, i.e. in the inet table the kernel will try to load both the
838 ipv4 and ipv6 helper backends, if they are supported by the kernel.
839 Table 10. conntrack helper specifications
841 ┌─────────┬─────────────────────┬─────────────────────┐
842 │Keyword │ Description │ Type │
843 ├─────────┼─────────────────────┼─────────────────────┤
844 │ │ │ │
845 │type │ name of helper type │ quoted string (e.g. │
846 │ │ │ "ftp") │
847 ├─────────┼─────────────────────┼─────────────────────┤
848 │ │ │ │
849 │protocol │ layer 4 protocol of │ string (e.g. ip) │
850 │ │ the helper │ │
851 ├─────────┼─────────────────────┼─────────────────────┤
852 │ │ │ │
853 │l3proto │ layer 3 protocol of │ address family │
854 │ │ the helper │ (e.g. ip) │
855 └─────────┴─────────────────────┴─────────────────────┘
856 defining and assigning ftp helper.
858 Unlike iptables, helper assignment needs to be performed after the conntrack
860 lookup has completed, for example with the default 0 hook priority.
861 table inet myhelpers {
863 ct helper ftp-standard {
864 type "ftp" protocol tcp
865 }
866 chain prerouting {
867 type filter hook prerouting priority 0;
868 tcp dport 21 ct helper set "ftp-standard"
869 }
870 }
871 CT TIMEOUT
874 ct timeout name { protocol protocol ; policy = { state: value [, ...] } ; [l3proto family ;] }
875 Ct timeout is used to update connection tracking timeout values.Timeout
877 policies are assigned with the ct timeout set statement. protocol and
878 policy are mandatory, l3proto is derived from the table family by
879 default.
880 Table 11. conntrack timeout specifications
882 ┌─────────┬─────────────────────┬──────────────────┐
883 │Keyword │ Description │ Type │
884 ├─────────┼─────────────────────┼──────────────────┤
885 │ │ │ │
886 │protocol │ layer 4 protocol of │ string (e.g. ip) │
887 │ │ the timeout object │ │
888 ├─────────┼─────────────────────┼──────────────────┤
889 │ │ │ │
890 │state │ connection state │ string (e.g. │
891 │ │ name │ "established") │
892 ├─────────┼─────────────────────┼──────────────────┤
893 │ │ │ │
894 │value │ timeout value for │ unsigned integer │
895 │ │ connection state │ │
896 ├─────────┼─────────────────────┼──────────────────┤
897 │ │ │ │
898 │l3proto │ layer 3 protocol of │ address family │
899 │ │ the timeout object │ (e.g. ip) │
900 └─────────┴─────────────────────┴──────────────────┘
901 defining and assigning ct timeout policy.
903 table ip filter {
905 ct timeout customtimeout {
906 protocol tcp;
907 l3proto ip
908 policy = { established: 120, close: 20 }
909 }
910 chain output {
912 type filter hook output priority filter; policy accept;
913 ct timeout set "customtimeout"
914 }
915 }
916 testing the updated timeout policy.
918 % conntrack -E
920 It should display:
922 [UPDATE] tcp 6 120 ESTABLISHED src=172.16.19.128 dst=172.16.19.1
924 sport=22 dport=41360 [UNREPLIED] src=172.16.19.1 dst=172.16.19.128
925 sport=41360 dport=22
926 CT EXPECTATION
929 ct expectation name { protocol protocol ; dport dport ; timeout timeout ; size size ; [*l3proto family ;] }
930 Ct expectation is used to create connection expectations. Expectations
932 are assigned with the ct expectation set statement. protocol, dport,
933 timeout and size are mandatory, l3proto is derived from the table
934 family by default.
935 Table 12. conntrack expectation specifications
937 ┌─────────┬─────────────────────┬──────────────────┐
938 │Keyword │ Description │ Type │
939 ├─────────┼─────────────────────┼──────────────────┤
940 │ │ │ │
941 │protocol │ layer 4 protocol of │ string (e.g. ip) │
942 │ │ the expectation │ │
943 │ │ object │ │
944 ├─────────┼─────────────────────┼──────────────────┤
945 │ │ │ │
946 │dport │ destination port of │ unsigned integer │
947 │ │ expected connection │ │
948 ├─────────┼─────────────────────┼──────────────────┤
949 │ │ │ │
950 │timeout │ timeout value for │ unsigned integer │
951 │ │ expectation │ │
952 ├─────────┼─────────────────────┼──────────────────┤
953 │ │ │ │
954 │size │ size value for │ unsigned integer │
955 │ │ expectation │ │
956 ├─────────┼─────────────────────┼──────────────────┤
957 │ │ │ │
958 │l3proto │ layer 3 protocol of │ address family │
959 │ │ the expectation │ (e.g. ip) │
960 │ │ object │ │
961 └─────────┴─────────────────────┴──────────────────┘
962 defining and assigning ct expectation policy.
964 table ip filter {
966 ct expectation expect {
967 protocol udp
968 dport 9876
969 timeout 2m
970 size 8
971 l3proto ip
972 }
973 chain input {
975 type filter hook input priority filter; policy accept;
976 ct expectation set "expect"
977 }
978 }
979 COUNTER
982 counter [packets bytes]
983 Table 13. Counter specifications
985 ┌────────┬──────────────────┬──────────────────┐
986 │Keyword │ Description │ Type │
987 ├────────┼──────────────────┼──────────────────┤
988 │ │ │ │
989 │packets │ initial count of │ unsigned integer │
990 │ │ packets │ (64 bit) │
991 ├────────┼──────────────────┼──────────────────┤
992 │ │ │ │
993 │bytes │ initial count of │ unsigned integer │
994 │ │ bytes │ (64 bit) │
995 └────────┴──────────────────┴──────────────────┘
996 QUOTA
998 quota [over | until] [used]
999 Table 14. Quota specifications
1001 ┌────────┬───────────────────┬────────────────────┐
1002 │Keyword │ Description │ Type │
1003 ├────────┼───────────────────┼────────────────────┤
1004 │ │ │ │
1005 │quota │ quota limit, used │ Two arguments, │
1006 │ │ as the quota name │ unsigned integer │
1007 │ │ │ (64 bit) and │
1008 │ │ │ string: bytes, │
1009 │ │ │ kbytes, mbytes. │
1010 │ │ │ "over" and "until" │
1011 │ │ │ go before these │
1012 │ │ │ arguments │
1013 ├────────┼───────────────────┼────────────────────┤
1014 │ │ │ │
1015 │used │ initial value of │ Two arguments, │
1016 │ │ used quota │ unsigned integer │
1017 │ │ │ (64 bit) and │
1018 │ │ │ string: bytes, │
1019 │ │ │ kbytes, mbytes │
1020 └────────┴───────────────────┴────────────────────┘
1021
1023 Expressions represent values, either constants like network addresses,
1024 port numbers, etc., or data gathered from the packet during ruleset
1025 evaluation. Expressions can be combined using binary, logical,
1026 relational and other types of expressions to form complex or relational
1027 (match) expressions. They are also used as arguments to certain types
1028 of operations, like NAT, packet marking etc.
1029 Each expression has a data type, which determines the size, parsing and
1031 representation of symbolic values and type compatibility with other
1032 expressions.
1033 DESCRIBE COMMAND
1035 describe expression | data type
1036 The describe command shows information about the type of an expression
1038 and its data type. A data type may also be given, in which nft will
1039 display more information about the type.
1040 The describe command.
1042 $ nft describe tcp flags
1044 payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits
1045 predefined symbolic constants:
1047 fin 0x01
1048 syn 0x02
1049 rst 0x04
1050 psh 0x08
1051 ack 0x10
1052 urg 0x20
1053 ecn 0x40
1054 cwr 0x80
1055
1058 Data types determine the size, parsing and representation of symbolic
1059 values and type compatibility of expressions. A number of global data
1060 types exist, in addition some expression types define further data
1061 types specific to the expression type. Most data types have a fixed
1062 size, some however may have a dynamic size, f.i. the string type. Some
1063 types also have predefined symbolic constants. Those can be listed
1064 using the nft describe command:
1065 $ nft describe ct_state
1067 datatype ct_state (conntrack state) (basetype bitmask, integer), 32 bits
1068 pre-defined symbolic constants (in hexadecimal):
1070 invalid 0x00000001
1071 new ...
1072 Types may be derived from lower order types, f.i. the IPv4 address type
1074 is derived from the integer type, meaning an IPv4 address can also be
1075 specified as an integer value.
1076 In certain contexts (set and map definitions), it is necessary to
1078 explicitly specify a data type. Each type has a name which is used for
1079 this.
1080 INTEGER TYPE
1082 ┌────────┬─────────┬──────────┬───────────┐
1083 │Name │ Keyword │ Size │ Base type │
1084 ├────────┼─────────┼──────────┼───────────┤
1085 │ │ │ │ │
1086 │Integer │ integer │ variable │ - │
1087 └────────┴─────────┴──────────┴───────────┘
1088 The integer type is used for numeric values. It may be specified as a
1090 decimal, hexadecimal or octal number. The integer type does not have a
1091 fixed size, its size is determined by the expression for which it is
1092 used.
1093 BITMASK TYPE
1095 ┌────────┬─────────┬──────────┬───────────┐
1096 │Name │ Keyword │ Size │ Base type │
1097 ├────────┼─────────┼──────────┼───────────┤
1098 │ │ │ │ │
1099 │Bitmask │ bitmask │ variable │ integer │
1100 └────────┴─────────┴──────────┴───────────┘
1101 The bitmask type (bitmask) is used for bitmasks.
1103 STRING TYPE
1105 ┌───────┬─────────┬──────────┬───────────┐
1106 │Name │ Keyword │ Size │ Base type │
1107 ├───────┼─────────┼──────────┼───────────┤
1108 │ │ │ │ │
1109 │String │ string │ variable │ - │
1110 └───────┴─────────┴──────────┴───────────┘
1111 The string type is used for character strings. A string begins with an
1113 alphabetic character (a-zA-Z) followed by zero or more alphanumeric
1114 characters or the characters /, -, _ and .. In addition, anything
1115 enclosed in double quotes (") is recognized as a string.
1116 String specification.
1118 # Interface name
1120 filter input iifname eth0
1121 # Weird interface name
1123 filter input iifname "(eth0)"
1124 LINK LAYER ADDRESS TYPE
1127 ┌───────────┬─────────┬──────────┬───────────┐
1128 │Name │ Keyword │ Size │ Base type │
1129 ├───────────┼─────────┼──────────┼───────────┤
1130 │ │ │ │ │
1131 │Link layer │ lladdr │ variable │ integer │
1132 │address │ │ │ │
1133 └───────────┴─────────┴──────────┴───────────┘
1134 The link layer address type is used for link layer addresses. Link
1136 layer addresses are specified as a variable amount of groups of two
1137 hexadecimal digits separated using colons (:).
1138 Link layer address specification.
1140 # Ethernet destination MAC address
1142 filter input ether daddr 20:c9:d0:43:12:d9
1143 IPV4 ADDRESS TYPE
1146 ┌─────────────┬───────────┬────────┬───────────┐
1147 │Name │ Keyword │ Size │ Base type │
1148 ├─────────────┼───────────┼────────┼───────────┤
1149 │ │ │ │ │
1150 │IPV4 address │ ipv4_addr │ 32 bit │ integer │
1151 └─────────────┴───────────┴────────┴───────────┘
1152 The IPv4 address type is used for IPv4 addresses. Addresses are
1154 specified in either dotted decimal, dotted hexadecimal, dotted octal,
1155 decimal, hexadecimal, octal notation or as a host name. A host name
1156 will be resolved using the standard system resolver.
1157 IPv4 address specification.
1159 # dotted decimal notation
1161 filter output ip daddr 127.0.0.1
1162 # host name
1164 filter output ip daddr localhost
1165 IPV6 ADDRESS TYPE
1168 ┌─────────────┬───────────┬─────────┬───────────┐
1169 │Name │ Keyword │ Size │ Base type │
1170 ├─────────────┼───────────┼─────────┼───────────┤
1171 │ │ │ │ │
1172 │IPv6 address │ ipv6_addr │ 128 bit │ integer │
1173 └─────────────┴───────────┴─────────┴───────────┘
1174 The IPv6 address type is used for IPv6 addresses. Addresses are
1176 specified as a host name or as hexadecimal halfwords separated by
1177 colons. Addresses might be enclosed in square brackets ("[]") to
1178 differentiate them from port numbers.
1179 IPv6 address specification.
1181 # abbreviated loopback address
1183 filter output ip6 daddr ::1
1184 IPv6 address specification with bracket notation.
1186 # without [] the port number (22) would be parsed as part of the
1188 # ipv6 address
1189 ip6 nat prerouting tcp dport 2222 dnat to [1ce::d0]:22
1190 BOOLEAN TYPE
1193 ┌────────┬─────────┬───────┬───────────┐
1194 │Name │ Keyword │ Size │ Base type │
1195 ├────────┼─────────┼───────┼───────────┤
1196 │ │ │ │ │
1197 │Boolean │ boolean │ 1 bit │ integer │
1198 └────────┴─────────┴───────┴───────────┘
1199 The boolean type is a syntactical helper type in userspace. Its use is
1201 in the right-hand side of a (typically implicit) relational expression
1202 to change the expression on the left-hand side into a boolean check
1203 (usually for existence).
1204 Table 15. The following keywords will automatically resolve into a
1206 boolean type with given value
1207 ┌────────┬───────┐
1208 │Keyword │ Value │
1209 ├────────┼───────┤
1210 │ │ │
1211 │exists │ 1 │
1212 ├────────┼───────┤
1213 │ │ │
1214 │missing │ 0 │
1215 └────────┴───────┘
1216 Table 16. expressions support a boolean comparison
1218 ┌───────────┬─────────────────────────┐
1219 │Expression │ Behaviour │
1220 ├───────────┼─────────────────────────┤
1221 │ │ │
1222 │fib │ Check route existence. │
1223 ├───────────┼─────────────────────────┤
1224 │ │ │
1225 │exthdr │ Check IPv6 extension │
1226 │ │ header existence. │
1227 ├───────────┼─────────────────────────┤
1228 │ │ │
1229 │tcp option │ Check TCP option header │
1230 │ │ existence. │
1231 └───────────┴─────────────────────────┘
1232 Boolean specification.
1234 # match if route exists
1236 filter input fib daddr . iif oif exists
1237 # match only non-fragmented packets in IPv6 traffic
1239 filter input exthdr frag missing
1240 # match if TCP timestamp option is present
1242 filter input tcp option timestamp exists
1243 ICMP TYPE TYPE
1246 ┌──────────┬───────────┬───────┬───────────┐
1247 │Name │ Keyword │ Size │ Base type │
1248 ├──────────┼───────────┼───────┼───────────┤
1249 │ │ │ │ │
1250 │ICMP Type │ icmp_type │ 8 bit │ integer │
1251 └──────────┴───────────┴───────┴───────────┘
1252 The ICMP Type type is used to conveniently specify the ICMP header’s
1254 type field.
1255 Table 17. Keywords may be used when specifying the ICMP type
1257 ┌────────────────────────┬───────┐
1258 │Keyword │ Value │
1259 ├────────────────────────┼───────┤
1260 │ │ │
1261 │echo-reply │ 0 │
1262 ├────────────────────────┼───────┤
1263 │ │ │
1264 │destination-unreachable │ 3 │
1265 ├────────────────────────┼───────┤
1266 │ │ │
1267 │source-quench │ 4 │
1268 ├────────────────────────┼───────┤
1269 │ │ │
1270 │redirect │ 5 │
1271 ├────────────────────────┼───────┤
1272 │ │ │
1273 │echo-request │ 8 │
1274 ├────────────────────────┼───────┤
1275 │ │ │
1276 │router-advertisement │ 9 │
1277 ├────────────────────────┼───────┤
1278 │ │ │
1279 │router-solicitation │ 10 │
1280 ├────────────────────────┼───────┤
1281 │ │ │
1282 │time-exceeded │ 11 │
1283 ├────────────────────────┼───────┤
1284 │ │ │
1285 │parameter-problem │ 12 │
1286 ├────────────────────────┼───────┤
1287 │ │ │
1288 │timestamp-request │ 13 │
1289 ├────────────────────────┼───────┤
1290 │ │ │
1291 │timestamp-reply │ 14 │
1292 ├────────────────────────┼───────┤
1293 │ │ │
1294 │info-request │ 15 │
1295 ├────────────────────────┼───────┤
1296 │ │ │
1297 │info-reply │ 16 │
1298 ├────────────────────────┼───────┤
1299 │ │ │
1300 │address-mask-request │ 17 │
1301 ├────────────────────────┼───────┤
1302 │ │ │
1303 │address-mask-reply │ 18 │
1304 └────────────────────────┴───────┘
1305 ICMP Type specification.
1307 # match ping packets
1309 filter output icmp type { echo-request, echo-reply }
1310 ICMP CODE TYPE
1313 ┌──────────┬───────────┬───────┬───────────┐
1314 │Name │ Keyword │ Size │ Base type │
1315 ├──────────┼───────────┼───────┼───────────┤
1316 │ │ │ │ │
1317 │ICMP Code │ icmp_code │ 8 bit │ integer │
1318 └──────────┴───────────┴───────┴───────────┘
1319 The ICMP Code type is used to conveniently specify the ICMP header’s
1321 code field.
1322 Table 18. Keywords may be used when specifying the ICMP code
1324 ┌─────────────────┬───────┐
1325 │Keyword │ Value │
1326 ├─────────────────┼───────┤
1327 │ │ │
1328 │net-unreachable │ 0 │
1329 ├─────────────────┼───────┤
1330 │ │ │
1331 │host-unreachable │ 1 │
1332 ├─────────────────┼───────┤
1333 │ │ │
1334 │prot-unreachable │ 2 │
1335 ├─────────────────┼───────┤
1336 │ │ │
1337 │port-unreachable │ 3 │
1338 ├─────────────────┼───────┤
1339 │ │ │
1340 │net-prohibited │ 9 │
1341 ├─────────────────┼───────┤
1342 │ │ │
1343 │host-prohibited │ 10 │
1344 ├─────────────────┼───────┤
1345 │ │ │
1346 │admin-prohibited │ 13 │
1347 └─────────────────┴───────┘
1348 ICMPV6 TYPE TYPE
1350 ┌────────────┬────────────┬───────┬───────────┐
1351 │Name │ Keyword │ Size │ Base type │
1352 ├────────────┼────────────┼───────┼───────────┤
1353 │ │ │ │ │
1354 │ICMPv6 Type │ icmpx_code │ 8 bit │ integer │
1355 └────────────┴────────────┴───────┴───────────┘
1356 The ICMPv6 Type type is used to conveniently specify the ICMPv6
1358 header’s type field.
1359 Table 19. keywords may be used when specifying the ICMPv6 type:
1361 ┌────────────────────────┬───────┐
1362 │Keyword │ Value │
1363 ├────────────────────────┼───────┤
1364 │ │ │
1365 │destination-unreachable │ 1 │
1366 ├────────────────────────┼───────┤
1367 │ │ │
1368 │packet-too-big │ 2 │
1369 ├────────────────────────┼───────┤
1370 │ │ │
1371 │time-exceeded │ 3 │
1372 ├────────────────────────┼───────┤
1373 │ │ │
1374 │parameter-problem │ 4 │
1375 ├────────────────────────┼───────┤
1376 │ │ │
1377 │echo-request │ 128 │
1378 ├────────────────────────┼───────┤
1379 │ │ │
1380 │echo-reply │ 129 │
1381 ├────────────────────────┼───────┤
1382 │ │ │
1383 │mld-listener-query │ 130 │
1384 ├────────────────────────┼───────┤
1385 │ │ │
1386 │mld-listener-report │ 131 │
1387 ├────────────────────────┼───────┤
1388 │ │ │
1389 │mld-listener-done │ 132 │
1390 ├────────────────────────┼───────┤
1391 │ │ │
1392 │mld-listener-reduction │ 132 │
1393 ├────────────────────────┼───────┤
1394 │ │ │
1395 │nd-router-solicit │ 133 │
1396 ├────────────────────────┼───────┤
1397 │ │ │
1398 │nd-router-advert │ 134 │
1399 ├────────────────────────┼───────┤
1400 │ │ │
1401 │nd-neighbor-solicit │ 135 │
1402 ├────────────────────────┼───────┤
1403 │ │ │
1404 │nd-neighbor-advert │ 136 │
1405 ├────────────────────────┼───────┤
1406 │ │ │
1407 │nd-redirect │ 137 │
1408 ├────────────────────────┼───────┤
1409 │ │ │
1410 │router-renumbering │ 138 │
1411 ├────────────────────────┼───────┤
1412 │ │ │
1413 │ind-neighbor-solicit │ 141 │
1414 ├────────────────────────┼───────┤
1415 │ │ │
1416 │ind-neighbor-advert │ 142 │
1417 ├────────────────────────┼───────┤
1418 │ │ │
1419 │mld2-listener-report │ 143 │
1420 └────────────────────────┴───────┘
1421 ICMPv6 Type specification.
1423 # match ICMPv6 ping packets
1425 filter output icmpv6 type { echo-request, echo-reply }
1426 ICMPV6 CODE TYPE
1429 ┌────────────┬─────────────┬───────┬───────────┐
1430 │Name │ Keyword │ Size │ Base type │
1431 ├────────────┼─────────────┼───────┼───────────┤
1432 │ │ │ │ │
1433 │ICMPv6 Code │ icmpv6_code │ 8 bit │ integer │
1434 └────────────┴─────────────┴───────┴───────────┘
1435 The ICMPv6 Code type is used to conveniently specify the ICMPv6
1437 header’s code field.
1438 Table 20. keywords may be used when specifying the ICMPv6 code
1440 ┌─────────────────┬───────┐
1441 │Keyword │ Value │
1442 ├─────────────────┼───────┤
1443 │ │ │
1444 │no-route │ 0 │
1445 ├─────────────────┼───────┤
1446 │ │ │
1447 │admin-prohibited │ 1 │
1448 ├─────────────────┼───────┤
1449 │ │ │
1450 │addr-unreachable │ 3 │
1451 ├─────────────────┼───────┤
1452 │ │ │
1453 │port-unreachable │ 4 │
1454 ├─────────────────┼───────┤
1455 │ │ │
1456 │policy-fail │ 5 │
1457 ├─────────────────┼───────┤
1458 │ │ │
1459 │reject-route │ 6 │
1460 └─────────────────┴───────┘
1461 ICMPVX CODE TYPE
1463 ┌────────────┬─────────────┬───────┬───────────┐
1464 │Name │ Keyword │ Size │ Base type │
1465 ├────────────┼─────────────┼───────┼───────────┤
1466 │ │ │ │ │
1467 │ICMPvX Code │ icmpv6_type │ 8 bit │ integer │
1468 └────────────┴─────────────┴───────┴───────────┘
1469 The ICMPvX Code type abstraction is a set of values which overlap
1471 between ICMP and ICMPv6 Code types to be used from the inet family.
1472 Table 21. keywords may be used when specifying the ICMPvX code
1474 ┌─────────────────┬───────┐
1475 │Keyword │ Value │
1476 ├─────────────────┼───────┤
1477 │ │ │
1478 │no-route │ 0 │
1479 ├─────────────────┼───────┤
1480 │ │ │
1481 │port-unreachable │ 1 │
1482 ├─────────────────┼───────┤
1483 │ │ │
1484 │host-unreachable │ 2 │
1485 ├─────────────────┼───────┤
1486 │ │ │
1487 │admin-prohibited │ 3 │
1488 └─────────────────┴───────┘
1489 CONNTRACK TYPES
1491 Table 22. overview of types used in ct expression and statement
1492 ┌─────────────────┬───────────┬─────────┬───────────┐
1493 │Name │ Keyword │ Size │ Base type │
1494 ├─────────────────┼───────────┼─────────┼───────────┤
1495 │ │ │ │ │
1496 │conntrack state │ ct_state │ 4 byte │ bitmask │
1497 ├─────────────────┼───────────┼─────────┼───────────┤
1498 │ │ │ │ │
1499 │conntrack │ ct_dir │ 8 bit │ integer │
1500 │direction │ │ │ │
1501 ├─────────────────┼───────────┼─────────┼───────────┤
1502 │ │ │ │ │
1503 │conntrack status │ ct_status │ 4 byte │ bitmask │
1504 ├─────────────────┼───────────┼─────────┼───────────┤
1505 │ │ │ │ │
1506 │conntrack event │ ct_event │ 4 byte │ bitmask │
1507 │bits │ │ │ │
1508 ├─────────────────┼───────────┼─────────┼───────────┤
1509 │ │ │ │ │
1510 │conntrack label │ ct_label │ 128 bit │ bitmask │
1511 └─────────────────┴───────────┴─────────┴───────────┘
1512 For each of the types above, keywords are available for convenience:
1514 Table 23. conntrack state (ct_state)
1516 ┌────────────┬───────┐
1517 │Keyword │ Value │
1518 ├────────────┼───────┤
1519 │ │ │
1520 │invalid │ 1 │
1521 ├────────────┼───────┤
1522 │ │ │
1523 │established │ 2 │
1524 ├────────────┼───────┤
1525 │ │ │
1526 │related │ 4 │
1527 ├────────────┼───────┤
1528 │ │ │
1529 │new │ 8 │
1530 ├────────────┼───────┤
1531 │ │ │
1532 │untracked │ 64 │
1533 └────────────┴───────┘
1534 Table 24. conntrack direction (ct_dir)
1536 ┌─────────┬───────┐
1537 │Keyword │ Value │
1538 ├─────────┼───────┤
1539 │ │ │
1540 │original │ 0 │
1541 ├─────────┼───────┤
1542 │ │ │
1543 │reply │ 1 │
1544 └─────────┴───────┘
1545 Table 25. conntrack status (ct_status)
1547 ┌───────────┬───────┐
1548 │Keyword │ Value │
1549 ├───────────┼───────┤
1550 │ │ │
1551 │expected │ 1 │
1552 ├───────────┼───────┤
1553 │ │ │
1554 │seen-reply │ 2 │
1555 ├───────────┼───────┤
1556 │ │ │
1557 │assured │ 4 │
1558 ├───────────┼───────┤
1559 │ │ │
1560 │confirmed │ 8 │
1561 ├───────────┼───────┤
1562 │ │ │
1563 │snat │ 16 │
1564 ├───────────┼───────┤
1565 │ │ │
1566 │dnat │ 32 │
1567 ├───────────┼───────┤
1568 │ │ │
1569 │dying │ 512 │
1570 └───────────┴───────┘
1571 Table 26. conntrack event bits (ct_event)
1573 ┌──────────┬───────┐
1574 │Keyword │ Value │
1575 ├──────────┼───────┤
1576 │ │ │
1577 │new │ 1 │
1578 ├──────────┼───────┤
1579 │ │ │
1580 │related │ 2 │
1581 ├──────────┼───────┤
1582 │ │ │
1583 │destroy │ 4 │
1584 ├──────────┼───────┤
1585 │ │ │
1586 │reply │ 8 │
1587 ├──────────┼───────┤
1588 │ │ │
1589 │assured │ 16 │
1590 ├──────────┼───────┤
1591 │ │ │
1592 │protoinfo │ 32 │
1593 ├──────────┼───────┤
1594 │ │ │
1595 │helper │ 64 │
1596 ├──────────┼───────┤
1597 │ │ │
1598 │mark │ 128 │
1599 ├──────────┼───────┤
1600 │ │ │
1601 │seqadj │ 256 │
1602 ├──────────┼───────┤
1603 │ │ │
1604 │secmark │ 512 │
1605 ├──────────┼───────┤
1606 │ │ │
1607 │label │ 1024 │
1608 └──────────┴───────┘
1609 Possible keywords for conntrack label type (ct_label) are read at
1611 runtime from /etc/connlabel.conf.
1612
1614 The lowest order expression is a primary expression, representing
1615 either a constant or a single datum from a packet’s payload, meta data
1616 or a stateful module.
1617 META EXPRESSIONS
1619 meta {length | nfproto | l4proto | protocol | priority}
1620 [meta] {mark | iif | iifname | iiftype | oif | oifname | oiftype | skuid | skgid | nftrace | rtclassid | ibrname | obrname | pkttype | cpu | iifgroup | oifgroup | cgroup | random | ipsec | iifkind | oifkind | time | hour | day }
1621 A meta expression refers to meta data associated with a packet.
1623 There are two types of meta expressions: unqualified and qualified meta
1625 expressions. Qualified meta expressions require the meta keyword before
1626 the meta key, unqualified meta expressions can be specified by using
1627 the meta key directly or as qualified meta expressions. Meta l4proto is
1628 useful to match a particular transport protocol that is part of either
1629 an IPv4 or IPv6 packet. It will also skip any IPv6 extension headers
1630 present in an IPv6 packet.
1631 meta iif, oif, iifname and oifname are used to match the interface a
1633 packet arrived on or is about to be sent out on.
1634 iif and oif are used to match on the interface index, whereas iifname
1636 and oifname are used to match on the interface name. This is not the
1637 same — assuming the rule
1638 filter input meta iif "foo"
1640 Then this rule can only be added if the interface "foo" exists. Also,
1642 the rule will continue to match even if the interface "foo" is renamed
1643 to "bar".
1644 This is because internally the interface index is used. In case of
1646 dynamically created interfaces, such as tun/tap or dialup interfaces
1647 (ppp for example), it might be better to use iifname or oifname
1648 instead.
1649 In these cases, the name is used so the interface doesn’t have to exist
1651 to add such a rule, it will stop matching if the interface gets renamed
1652 and it will match again in case interface gets deleted and later a new
1653 interface with the same name is created.
1654 Table 27. Meta expression types
1656 ┌──────────┬─────────────────────┬─────────────────────┐
1657 │Keyword │ Description │ Type │
1658 ├──────────┼─────────────────────┼─────────────────────┤
1659 │ │ │ │
1660 │length │ Length of the │ integer (32-bit) │
1661 │ │ packet in bytes │ │
1662 ├──────────┼─────────────────────┼─────────────────────┤
1663 │ │ │ │
1664 │nfproto │ real hook protocol │ integer (32 bit) │
1665 │ │ family, useful only │ │
1666 │ │ in inet table │ │
1667 ├──────────┼─────────────────────┼─────────────────────┤
1668 │ │ │ │
1669 │l4proto │ layer 4 protocol, │ integer (8 bit) │
1670 │ │ skips ipv6 │ │
1671 │ │ extension headers │ │
1672 ├──────────┼─────────────────────┼─────────────────────┤
1673 │ │ │ │
1674 │protocol │ EtherType protocol │ ether_type │
1675 │ │ value │ │
1676 ├──────────┼─────────────────────┼─────────────────────┤
1677 │ │ │ │
1678 │priority │ TC packet priority │ tc_handle │
1679 ├──────────┼─────────────────────┼─────────────────────┤
1680 │ │ │ │
1681 │mark │ Packet mark │ mark │
1682 ├──────────┼─────────────────────┼─────────────────────┤
1683 │ │ │ │
1684 │iif │ Input interface │ iface_index │
1685 │ │ index │ │
1686 ├──────────┼─────────────────────┼─────────────────────┤
1687 │ │ │ │
1688 │iifname │ Input interface │ ifname │
1689 │ │ name │ │
1690 ├──────────┼─────────────────────┼─────────────────────┤
1691 │ │ │ │
1692 │iiftype │ Input interface │ iface_type │
1693 │ │ type │ │
1694 ├──────────┼─────────────────────┼─────────────────────┤
1695 │ │ │ │
1696 │oif │ Output interface │ iface_index │
1697 │ │ index │ │
1698 ├──────────┼─────────────────────┼─────────────────────┤
1699 │ │ │ │
1700 │oifname │ Output interface │ ifname │
1701 │ │ name │ │
1702 ├──────────┼─────────────────────┼─────────────────────┤
1703 │ │ │ │
1704 │oiftype │ Output interface │ iface_type │
1705 │ │ hardware type │ │
1706 ├──────────┼─────────────────────┼─────────────────────┤
1707 │ │ │ │
1708 │skuid │ UID associated with │ uid │
1709 │ │ originating socket │ │
1710 ├──────────┼─────────────────────┼─────────────────────┤
1711 │ │ │ │
1712 │skgid │ GID associated with │ gid │
1713 │ │ originating socket │ │
1714 ├──────────┼─────────────────────┼─────────────────────┤
1715 │ │ │ │
1716 │rtclassid │ Routing realm │ realm │
1717 ├──────────┼─────────────────────┼─────────────────────┤
1718 │ │ │ │
1719 │ibrname │ Input bridge │ ifname │
1720 │ │ interface name │ │
1721 ├──────────┼─────────────────────┼─────────────────────┤
1722 │ │ │ │
1723 │obrname │ Output bridge │ ifname │
1724 │ │ interface name │ │
1725 ├──────────┼─────────────────────┼─────────────────────┤
1726 │ │ │ │
1727 │pkttype │ packet type │ pkt_type │
1728 ├──────────┼─────────────────────┼─────────────────────┤
1729 │ │ │ │
1730 │cpu │ cpu number │ integer (32 bit) │
1731 │ │ processing the │ │
1732 │ │ packet │ │
1733 ├──────────┼─────────────────────┼─────────────────────┤
1734 │ │ │ │
1735 │iifgroup │ incoming device │ devgroup │
1736 │ │ group │ │
1737 ├──────────┼─────────────────────┼─────────────────────┤
1738 │ │ │ │
1739 │oifgroup │ outgoing device │ devgroup │
1740 │ │ group │ │
1741 ├──────────┼─────────────────────┼─────────────────────┤
1742 │ │ │ │
1743 │cgroup │ control group id │ integer (32 bit) │
1744 ├──────────┼─────────────────────┼─────────────────────┤
1745 │ │ │ │
1746 │random │ pseudo-random │ integer (32 bit) │
1747 │ │ number │ │
1748 ├──────────┼─────────────────────┼─────────────────────┤
1749 │ │ │ │
1750 │ipsec │ boolean │ boolean (1 bit) │
1751 ├──────────┼─────────────────────┼─────────────────────┤
1752 │ │ │ │
1753 │iifkind │ Input interface │ │
1754 │ │ kind │ │
1755 ├──────────┼─────────────────────┼─────────────────────┤
1756 │ │ │ │
1757 │oifkind │ Output interface │ │
1758 │ │ kind │ │
1759 ├──────────┼─────────────────────┼─────────────────────┤
1760 │ │ │ │
1761 │time │ Absolute time of │ Integer (32 bit) or │
1762 │ │ packet reception │ string │
1763 ├──────────┼─────────────────────┼─────────────────────┤
1764 │ │ │ │
1765 │day │ Day of week │ Integer (8 bit) or │
1766 │ │ │ string │
1767 ├──────────┼─────────────────────┼─────────────────────┤
1768 │ │ │ │
1769 │hour │ Hour of day │ String │
1770 └──────────┴─────────────────────┴─────────────────────┘
1771 Table 28. Meta expression specific types
1773 ┌──────────────┬────────────────────────────┐
1774 │Type │ Description │
1775 ├──────────────┼────────────────────────────┤
1776 │ │ │
1777 │iface_index │ Interface index (32 bit │
1778 │ │ number). Can be specified │
1779 │ │ numerically or as name of │
1780 │ │ an existing interface. │
1781 ├──────────────┼────────────────────────────┤
1782 │ │ │
1783 │ifname │ Interface name (16 byte │
1784 │ │ string). Does not have to │
1785 │ │ exist. │
1786 ├──────────────┼────────────────────────────┤
1787 │ │ │
1788 │iface_type │ Interface type (16 bit │
1789 │ │ number). │
1790 ├──────────────┼────────────────────────────┤
1791 │ │ │
1792 │uid │ User ID (32 bit number). │
1793 │ │ Can be specified │
1794 │ │ numerically or as user │
1795 │ │ name. │
1796 ├──────────────┼────────────────────────────┤
1797 │ │ │
1798 │gid │ Group ID (32 bit number). │
1799 │ │ Can be specified │
1800 │ │ numerically or as group │
1801 │ │ name. │
1802 ├──────────────┼────────────────────────────┤
1803 │ │ │
1804 │realm │ Routing Realm (32 bit │
1805 │ │ number). Can be specified │
1806 │ │ numerically or as symbolic │
1807 │ │ name defined in │
1808 │ │ /etc/iproute2/rt_realms. │
1809 ├──────────────┼────────────────────────────┤
1810 │ │ │
1811 │devgroup_type │ Device group (32 bit │
1812 │ │ number). Can be specified │
1813 │ │ numerically or as symbolic │
1814 │ │ name defined in │
1815 │ │ /etc/iproute2/group. │
1816 ├──────────────┼────────────────────────────┤
1817 │ │ │
1818 │pkt_type │ Packet type: host │
1819 │ │ (addressed to local host), │
1820 │ │ broadcast (to all), │
1821 │ │ multicast (to group), │
1822 │ │ other (addressed to │
1823 │ │ another host). │
1824 ├──────────────┼────────────────────────────┤
1825 │ │ │
1826 │ifkind │ Interface kind (16 byte │
1827 │ │ string). Does not have to │
1828 │ │ exist. │
1829 ├──────────────┼────────────────────────────┤
1830 │ │ │
1831 │time │ Either an integer or a │
1832 │ │ date in ISO format. For │
1833 │ │ example: "2019-06-06 │
1834 │ │ 17:00". Hour and seconds │
1835 │ │ are optional and can be │
1836 │ │ omitted if desired. If │
1837 │ │ omitted, midnight will be │
1838 │ │ assumed. The following │
1839 │ │ three would be equivalent: │
1840 │ │ "2019-06-06", "2019-06-06 │
1841 │ │ 00:00" and "2019-06-06 │
1842 │ │ 00:00:00". When an integer │
1843 │ │ is given, it is assumed to │
1844 │ │ be a UNIX timestamp. │
1845 ├──────────────┼────────────────────────────┤
1846 │ │ │
1847 │day │ Either a day of week │
1848 │ │ ("Monday", "Tuesday", │
1849 │ │ etc.), or an integer │
1850 │ │ between 0 and 6. Strings │
1851 │ │ are matched │
1852 │ │ case-insensitively, and a │
1853 │ │ full match is not expected │
1854 │ │ (e.g. "Mon" would match │
1855 │ │ "Monday"). When an integer │
1856 │ │ is given, 0 is Sunday and │
1857 │ │ 6 is Saturday. │
1858 ├──────────────┼────────────────────────────┤
1859 │ │ │
1860 │hour │ A string representing an │
1861 │ │ hour in 24-hour format. │
1862 │ │ Seconds can optionally be │
1863 │ │ specified. For example, │
1864 │ │ 17:00 and 17:00:00 would │
1865 │ │ be equivalent. │
1866 └──────────────┴────────────────────────────┘
1867 Using meta expressions.
1869 # qualified meta expression
1871 filter output meta oif eth0
1872 # unqualified meta expression
1874 filter output oif eth0
1875 # packet was subject to ipsec processing
1877 raw prerouting meta ipsec exists accept
1878 SOCKET EXPRESSION
1881 socket {transparent | mark}
1882 Socket expression can be used to search for an existing open TCP/UDP
1884 socket and its attributes that can be associated with a packet. It
1885 looks for an established or non-zero bound listening socket (possibly
1886 with a non-local address).
1887 Table 29. Available socket attributes
1889 ┌────────────┬─────────────────────┬─────────────────┐
1890 │Name │ Description │ Type │
1891 ├────────────┼─────────────────────┼─────────────────┤
1892 │ │ │ │
1893 │transparent │ Value of the │ boolean (1 bit) │
1894 │ │ IP_TRANSPARENT │ │
1895 │ │ socket option in │ │
1896 │ │ the found socket. │ │
1897 │ │ It can be 0 or 1. │ │
1898 ├────────────┼─────────────────────┼─────────────────┤
1899 │ │ │ │
1900 │mark │ Value of the socket │ mark │
1901 │ │ mark (SOL_SOCKET, │ │
1902 │ │ SO_MARK). │ │
1903 └────────────┴─────────────────────┴─────────────────┘
1904 Using socket expression.
1906 # Mark packets that correspond to a transparent socket
1908 table inet x {
1909 chain y {
1910 type filter hook prerouting priority -150; policy accept;
1911 socket transparent 1 mark set 0x00000001 accept
1912 }
1913 }
1914 # Trace packets that corresponds to a socket with a mark value of 15
1916 table inet x {
1917 chain y {
1918 type filter hook prerouting priority -150; policy accept;
1919 socket mark 0x0000000f nftrace set 1
1920 }
1921 }
1922 # Set packet mark to socket mark
1924 table inet x {
1925 chain y {
1926 type filter hook prerouting priority -150; policy accept;
1927 tcp dport 8080 mark set socket mark
1928 }
1929 }
1930 OSF EXPRESSION
1933 osf [ttl {loose | skip}] {name | version}
1934 The osf expression does passive operating system fingerprinting. This
1936 expression compares some data (Window Size, MSS, options and their
1937 order, DF, and others) from packets with the SYN bit set.
1938 Table 30. Available osf attributes
1940 ┌────────┬─────────────────────┬────────┐
1941 │Name │ Description │ Type │
1942 ├────────┼─────────────────────┼────────┤
1943 │ │ │ │
1944 │ttl │ Do TTL checks on │ string │
1945 │ │ the packet to │ │
1946 │ │ determine the │ │
1947 │ │ operating system. │ │
1948 ├────────┼─────────────────────┼────────┤
1949 │ │ │ │
1950 │version │ Do OS version │ │
1951 │ │ checks on the │ │
1952 │ │ packet. │ │
1953 ├────────┼─────────────────────┼────────┤
1954 │ │ │ │
1955 │name │ Name of the OS │ string │
1956 │ │ signature to match. │ │
1957 │ │ All signatures can │ │
1958 │ │ be found at pf.os │ │
1959 │ │ file. Use "unknown" │ │
1960 │ │ for OS signatures │ │
1961 │ │ that the expression │ │
1962 │ │ could not detect. │ │
1963 └────────┴─────────────────────┴────────┘
1964 Available ttl values.
1966 If no TTL attribute is passed, make a true IP header and fingerprint TTL true comparison. This generally works for LANs.
1968 * loose: Check if the IP header's TTL is less than the fingerprint one. Works for globally-routable addresses.
1970 * skip: Do not compare the TTL at all.
1971 Using osf expression.
1973 # Accept packets that match the "Linux" OS genre signature without comparing TTL.
1975 table inet x {
1976 chain y {
1977 type filter hook input priority 0; policy accept;
1978 osf ttl skip name "Linux"
1979 }
1980 }
1981 FIB EXPRESSIONS
1984 fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}
1985 A fib expression queries the fib (forwarding information base) to
1987 obtain information such as the output interface index a particular
1988 address would use. The input is a tuple of elements that is used as
1989 input to the fib lookup functions.
1990 Table 31. fib expression specific types
1992 ┌────────┬──────────────────┬──────────────────┐
1993 │Keyword │ Description │ Type │
1994 ├────────┼──────────────────┼──────────────────┤
1995 │ │ │ │
1996 │oif │ Output interface │ integer (32 bit) │
1997 │ │ index │ │
1998 ├────────┼──────────────────┼──────────────────┤
1999 │ │ │ │
2000 │oifname │ Output interface │ string │
2001 │ │ name │ │
2002 ├────────┼──────────────────┼──────────────────┤
2003 │ │ │ │
2004 │type │ Address type │ fib_addrtype │
2005 └────────┴──────────────────┴──────────────────┘
2006 Use nft describe fib_addrtype to get a list of all address types.
2008 Using fib expressions.
2010 # drop packets without a reverse path
2012 filter prerouting fib saddr . iif oif missing drop
2013 In this example, 'saddr . iif' looks up routing information based on the source address and the input interface.
2015 oif picks the output interface index from the routing information.
2016 If no route was found for the source address/input interface combination, the output interface index is zero.
2017 In case the input interface is specified as part of the input key, the output interface index is always the same as the input interface index or zero.
2018 If only 'saddr oif' is given, then oif can be any interface index or zero.
2019 In this example, 'saddr . iif' lookups up routing information based on the source address and the input interface.
2021 oif picks the output interface index from the routing information.
2022 If no route was found for the source address/input interface combination, the output interface index is zero.
2023 In case the input interface is specified as part of the input key, the output interface index is always the same as the input interface index or zero.
2024 If only 'saddr oif' is given, then oif can be any interface index or zero.
2025 # drop packets to address not configured on ininterface
2027 filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
2028 # perform lookup in a specific 'blackhole' table (0xdead, needs ip appropriate ip rule)
2030 filter prerouting meta mark set 0xdead fib daddr . mark type vmap { blackhole : drop, prohibit : jump prohibited, unreachable : drop }
2031 ROUTING EXPRESSIONS
2034 rt [ip | ip6] {classid | nexthop | mtu | ipsec}
2035 A routing expression refers to routing data associated with a packet.
2037 Table 32. Routing expression types
2039 ┌────────┬─────────────────────┬─────────────────────┐
2040 │Keyword │ Description │ Type │
2041 ├────────┼─────────────────────┼─────────────────────┤
2042 │ │ │ │
2043 │classid │ Routing realm │ realm │
2044 ├────────┼─────────────────────┼─────────────────────┤
2045 │ │ │ │
2046 │nexthop │ Routing nexthop │ ipv4_addr/ipv6_addr │
2047 ├────────┼─────────────────────┼─────────────────────┤
2048 │ │ │ │
2049 │mtu │ TCP maximum segment │ integer (16 bit) │
2050 │ │ size of route │ │
2051 ├────────┼─────────────────────┼─────────────────────┤
2052 │ │ │ │
2053 │ipsec │ route via ipsec │ boolean │
2054 │ │ tunnel or transport │ │
2055 └────────┴─────────────────────┴─────────────────────┘
2056 Table 33. Routing expression specific types
2058 ┌──────┬────────────────────────────┐
2059 │Type │ Description │
2060 ├──────┼────────────────────────────┤
2061 │ │ │
2062 │realm │ Routing Realm (32 bit │
2063 │ │ number). Can be specified │
2064 │ │ numerically or as symbolic │
2065 │ │ name defined in │
2066 │ │ /etc/iproute2/rt_realms. │
2067 └──────┴────────────────────────────┘
2068 Using routing expressions.
2070 # IP family independent rt expression
2072 filter output rt classid 10
2073 filter output rt ipsec missing
2074 # IP family dependent rt expressions
2076 ip filter output rt nexthop 192.168.0.1
2077 ip6 filter output rt nexthop fd00::1
2078 inet filter output rt ip nexthop 192.168.0.1
2079 inet filter output rt ip6 nexthop fd00::1
2080 IPSEC EXPRESSIONS
2083 ipsec {in | out} [ spnum NUM ] {reqid | spi}
2084 ipsec {in | out} [ spnum NUM ] {ip | ip6} {saddr | daddr}
2085 An ipsec expression refers to ipsec data associated with a packet.
2087 The in or out keyword needs to be used to specify if the expression
2089 should examine inbound or outbound policies. The in keyword can be used
2090 in the prerouting, input and forward hooks. The out keyword applies to
2091 forward, output and postrouting hooks. The optional keyword spnum can
2092 be used to match a specific state in a chain, it defaults to 0.
2093 Table 34. Ipsec expression types
2095 ┌────────┬─────────────────────┬─────────────────────┐
2096 │Keyword │ Description │ Type │
2097 ├────────┼─────────────────────┼─────────────────────┤
2098 │ │ │ │
2099 │reqid │ Request ID │ integer (32 bit) │
2100 ├────────┼─────────────────────┼─────────────────────┤
2101 │ │ │ │
2102 │spi │ Security Parameter │ integer (32 bit) │
2103 │ │ Index │ │
2104 ├────────┼─────────────────────┼─────────────────────┤
2105 │ │ │ │
2106 │saddr │ Source address of │ ipv4_addr/ipv6_addr │
2107 │ │ the tunnel │ │
2108 ├────────┼─────────────────────┼─────────────────────┤
2109 │ │ │ │
2110 │daddr │ Destination address │ ipv4_addr/ipv6_addr │
2111 │ │ of the tunnel │ │
2112 └────────┴─────────────────────┴─────────────────────┘
2113 NUMGEN EXPRESSION
2115 numgen {inc | random} mod NUM [ offset NUM ]
2116 Create a number generator. The inc or random keywords control its
2118 operation mode: In inc mode, the last returned value is simply
2119 incremented. In random mode, a new random number is returned. The value
2120 after mod keyword specifies an upper boundary (read: modulus) which is
2121 not reached by returned numbers. The optional offset allows to
2122 increment the returned value by a fixed offset.
2123 A typical use-case for numgen is load-balancing:
2125 Using numgen expression.
2127 # round-robin between 192.168.10.100 and 192.168.20.200:
2129 add rule nat prerouting dnat to numgen inc mod 2 map \
2130 { 0 : 192.168.10.100, 1 : 192.168.20.200 }
2131 # probability-based with odd bias using intervals:
2133 add rule nat prerouting dnat to numgen random mod 10 map \
2134 { 0-2 : 192.168.10.100, 3-9 : 192.168.20.200 }
2135
2138 Payload expressions refer to data from the packet’s payload.
2139 ETHERNET HEADER EXPRESSION
2141 ether {daddr | saddr | type}
2142 Table 35. Ethernet header expression types
2144 ┌────────┬────────────────────┬────────────┐
2145 │Keyword │ Description │ Type │
2146 ├────────┼────────────────────┼────────────┤
2147 │ │ │ │
2148 │daddr │ Destination MAC │ ether_addr │
2149 │ │ address │ │
2150 ├────────┼────────────────────┼────────────┤
2151 │ │ │ │
2152 │saddr │ Source MAC address │ ether_addr │
2153 ├────────┼────────────────────┼────────────┤
2154 │ │ │ │
2155 │type │ EtherType │ ether_type │
2156 └────────┴────────────────────┴────────────┘
2157 VLAN HEADER EXPRESSION
2159 vlan {id | cfi | pcp | type}
2160 Table 36. VLAN header expression
2162 ┌────────┬─────────────────────┬──────────────────┐
2163 │Keyword │ Description │ Type │
2164 ├────────┼─────────────────────┼──────────────────┤
2165 │ │ │ │
2166 │id │ VLAN ID (VID) │ integer (12 bit) │
2167 ├────────┼─────────────────────┼──────────────────┤
2168 │ │ │ │
2169 │cfi │ Canonical Format │ integer (1 bit) │
2170 │ │ Indicator │ │
2171 ├────────┼─────────────────────┼──────────────────┤
2172 │ │ │ │
2173 │pcp │ Priority code point │ integer (3 bit) │
2174 ├────────┼─────────────────────┼──────────────────┤
2175 │ │ │ │
2176 │type │ EtherType │ ether_type │
2177 └────────┴─────────────────────┴──────────────────┘
2178 ARP HEADER EXPRESSION
2180 arp {htype | ptype | hlen | plen | operation | saddr { ip | ether } | daddr { ip | ether }
2181 Table 37. ARP header expression
2183 ┌────────────┬─────────────────────┬──────────────────┐
2184 │Keyword │ Description │ Type │
2185 ├────────────┼─────────────────────┼──────────────────┤
2186 │ │ │ │
2187 │htype │ ARP hardware type │ integer (16 bit) │
2188 ├────────────┼─────────────────────┼──────────────────┤
2189 │ │ │ │
2190 │ptype │ EtherType │ ether_type │
2191 ├────────────┼─────────────────────┼──────────────────┤
2192 │ │ │ │
2193 │hlen │ Hardware address │ integer (8 bit) │
2194 │ │ len │ │
2195 ├────────────┼─────────────────────┼──────────────────┤
2196 │ │ │ │
2197 │plen │ Protocol address │ integer (8 bit) │
2198 │ │ len │ │
2199 ├────────────┼─────────────────────┼──────────────────┤
2200 │ │ │ │
2201 │operation │ Operation │ arp_op │
2202 ├────────────┼─────────────────────┼──────────────────┤
2203 │ │ │ │
2204 │saddr ether │ Ethernet sender │ ether_addr │
2205 │ │ address │ │
2206 ├────────────┼─────────────────────┼──────────────────┤
2207 │ │ │ │
2208 │daddr ether │ Ethernet target │ ether_addr │
2209 │ │ address │ │
2210 ├────────────┼─────────────────────┼──────────────────┤
2211 │ │ │ │
2212 │saddr ip │ IPv4 sender address │ ipv4_addr │
2213 ├────────────┼─────────────────────┼──────────────────┤
2214 │ │ │ │
2215 │daddr ip │ IPv4 target address │ ipv4_addr │
2216 └────────────┴─────────────────────┴──────────────────┘
2217 IPV4 HEADER EXPRESSION
2219 ip {version | hdrlength | dscp | ecn | length | id | frag-off | ttl | protocol | checksum | saddr | daddr }
2220 Table 38. IPv4 header expression
2222 ┌──────────┬─────────────────────┬──────────────────┐
2223 │Keyword │ Description │ Type │
2224 ├──────────┼─────────────────────┼──────────────────┤
2225 │ │ │ │
2226 │version │ IP header version │ integer (4 bit) │
2227 │ │ (4) │ │
2228 ├──────────┼─────────────────────┼──────────────────┤
2229 │ │ │ │
2230 │hdrlength │ IP header length │ integer (4 bit) │
2231 │ │ including options │ FIXME scaling │
2232 ├──────────┼─────────────────────┼──────────────────┤
2233 │ │ │ │
2234 │dscp │ Differentiated │ dscp │
2235 │ │ Services Code Point │ │
2236 ├──────────┼─────────────────────┼──────────────────┤
2237 │ │ │ │
2238 │ecn │ Explicit Congestion │ ecn │
2239 │ │ Notification │ │
2240 ├──────────┼─────────────────────┼──────────────────┤
2241 │ │ │ │
2242 │length │ Total packet length │ integer (16 bit) │
2243 ├──────────┼─────────────────────┼──────────────────┤
2244 │ │ │ │
2245 │id │ IP ID │ integer (16 bit) │
2246 ├──────────┼─────────────────────┼──────────────────┤
2247 │ │ │ │
2248 │frag-off │ Fragment offset │ integer (16 bit) │
2249 ├──────────┼─────────────────────┼──────────────────┤
2250 │ │ │ │
2251 │ttl │ Time to live │ integer (8 bit) │
2252 ├──────────┼─────────────────────┼──────────────────┤
2253 │ │ │ │
2254 │protocol │ Upper layer │ inet_proto │
2255 │ │ protocol │ │
2256 ├──────────┼─────────────────────┼──────────────────┤
2257 │ │ │ │
2258 │checksum │ IP header checksum │ integer (16 bit) │
2259 ├──────────┼─────────────────────┼──────────────────┤
2260 │ │ │ │
2261 │saddr │ Source address │ ipv4_addr │
2262 ├──────────┼─────────────────────┼──────────────────┤
2263 │ │ │ │
2264 │daddr │ Destination address │ ipv4_addr │
2265 └──────────┴─────────────────────┴──────────────────┘
2266 ICMP HEADER EXPRESSION
2268 icmp {type | code | checksum | id | sequence | gateway | mtu}
2269 This expression refers to ICMP header fields. When using it in inet,
2271 bridge or netdev families, it will cause an implicit dependency on IPv4
2272 to be created. To match on unusual cases like ICMP over IPv6, one has
2273 to add an explicit meta protocol ip6 match to the rule.
2274 Table 39. ICMP header expression
2276 ┌─────────┬─────────────────────┬──────────────────┐
2277 │Keyword │ Description │ Type │
2278 ├─────────┼─────────────────────┼──────────────────┤
2279 │ │ │ │
2280 │type │ ICMP type field │ icmp_type │
2281 ├─────────┼─────────────────────┼──────────────────┤
2282 │ │ │ │
2283 │code │ ICMP code field │ integer (8 bit) │
2284 ├─────────┼─────────────────────┼──────────────────┤
2285 │ │ │ │
2286 │checksum │ ICMP checksum field │ integer (16 bit) │
2287 ├─────────┼─────────────────────┼──────────────────┤
2288 │ │ │ │
2289 │id │ ID of echo │ integer (16 bit) │
2290 │ │ request/response │ │
2291 ├─────────┼─────────────────────┼──────────────────┤
2292 │ │ │ │
2293 │sequence │ sequence number of │ integer (16 bit) │
2294 │ │ echo │ │
2295 │ │ request/response │ │
2296 ├─────────┼─────────────────────┼──────────────────┤
2297 │ │ │ │
2298 │gateway │ gateway of │ integer (32 bit) │
2299 │ │ redirects │ │
2300 ├─────────┼─────────────────────┼──────────────────┤
2301 │ │ │ │
2302 │mtu │ MTU of path MTU │ integer (16 bit) │
2303 │ │ discovery │ │
2304 └─────────┴─────────────────────┴──────────────────┘
2305 IGMP HEADER EXPRESSION
2307 igmp {type | mrt | checksum | group}
2308 This expression refers to IGMP header fields. When using it in inet,
2310 bridge or netdev families, it will cause an implicit dependency on IPv4
2311 to be created. To match on unusual cases like IGMP over IPv6, one has
2312 to add an explicit meta protocol ip6 match to the rule.
2313 Table 40. IGMP header expression
2315 ┌─────────┬─────────────────────┬──────────────────┐
2316 │Keyword │ Description │ Type │
2317 ├─────────┼─────────────────────┼──────────────────┤
2318 │ │ │ │
2319 │type │ IGMP type field │ igmp_type │
2320 ├─────────┼─────────────────────┼──────────────────┤
2321 │ │ │ │
2322 │mrt │ IGMP maximum │ integer (8 bit) │
2323 │ │ response time field │ │
2324 ├─────────┼─────────────────────┼──────────────────┤
2325 │ │ │ │
2326 │checksum │ ICMP checksum field │ integer (16 bit) │
2327 ├─────────┼─────────────────────┼──────────────────┤
2328 │ │ │ │
2329 │group │ Group address │ integer (32 bit) │
2330 └─────────┴─────────────────────┴──────────────────┘
2331 IPV6 HEADER EXPRESSION
2333 ip6 {version | dscp | ecn | flowlabel | length | nexthdr | hoplimit | saddr | daddr}
2334 This expression refers to the ipv6 header fields. Caution when using
2336 ip6 nexthdr, the value only refers to the next header, i.e. ip6 nexthdr
2337 tcp will only match if the ipv6 packet does not contain any extension
2338 headers. Packets that are fragmented or e.g. contain a routing
2339 extension headers will not be matched. Please use meta l4proto if you
2340 wish to match the real transport header and ignore any additional
2341 extension headers instead.
2342 Table 41. IPv6 header expression
2344 ┌──────────┬─────────────────────┬──────────────────┐
2345 │Keyword │ Description │ Type │
2346 ├──────────┼─────────────────────┼──────────────────┤
2347 │ │ │ │
2348 │version │ IP header version │ integer (4 bit) │
2349 │ │ (6) │ │
2350 ├──────────┼─────────────────────┼──────────────────┤
2351 │ │ │ │
2352 │dscp │ Differentiated │ dscp │
2353 │ │ Services Code Point │ │
2354 ├──────────┼─────────────────────┼──────────────────┤
2355 │ │ │ │
2356 │ecn │ Explicit Congestion │ ecn │
2357 │ │ Notification │ │
2358 ├──────────┼─────────────────────┼──────────────────┤
2359 │ │ │ │
2360 │flowlabel │ Flow label │ integer (20 bit) │
2361 ├──────────┼─────────────────────┼──────────────────┤
2362 │ │ │ │
2363 │length │ Payload length │ integer (16 bit) │
2364 ├──────────┼─────────────────────┼──────────────────┤
2365 │ │ │ │
2366 │nexthdr │ Nexthdr protocol │ inet_proto │
2367 ├──────────┼─────────────────────┼──────────────────┤
2368 │ │ │ │
2369 │hoplimit │ Hop limit │ integer (8 bit) │
2370 ├──────────┼─────────────────────┼──────────────────┤
2371 │ │ │ │
2372 │saddr │ Source address │ ipv6_addr │
2373 ├──────────┼─────────────────────┼──────────────────┤
2374 │ │ │ │
2375 │daddr │ Destination address │ ipv6_addr │
2376 └──────────┴─────────────────────┴──────────────────┘
2377 Using ip6 header expressions.
2379 # matching if first extension header indicates a fragment
2381 ip6 nexthdr ipv6-frag
2382 ICMPV6 HEADER EXPRESSION
2385 icmpv6 {type | code | checksum | parameter-problem | packet-too-big | id | sequence | max-delay}
2386 This expression refers to ICMPv6 header fields. When using it in inet,
2388 bridge or netdev families, it will cause an implicit dependency on IPv6
2389 to be created. To match on unusual cases like ICMPv6 over IPv4, one has
2390 to add an explicit meta protocol ip match to the rule.
2391 Table 42. ICMPv6 header expression
2393 ┌──────────────────┬────────────────────┬──────────────────┐
2394 │Keyword │ Description │ Type │
2395 ├──────────────────┼────────────────────┼──────────────────┤
2396 │ │ │ │
2397 │type │ ICMPv6 type field │ icmpv6_type │
2398 ├──────────────────┼────────────────────┼──────────────────┤
2399 │ │ │ │
2400 │code │ ICMPv6 code field │ integer (8 bit) │
2401 ├──────────────────┼────────────────────┼──────────────────┤
2402 │ │ │ │
2403 │checksum │ ICMPv6 checksum │ integer (16 bit) │
2404 │ │ field │ │
2405 ├──────────────────┼────────────────────┼──────────────────┤
2406 │ │ │ │
2407 │parameter-problem │ pointer to problem │ integer (32 bit) │
2408 ├──────────────────┼────────────────────┼──────────────────┤
2409 │ │ │ │
2410 │packet-too-big │ oversized MTU │ integer (32 bit) │
2411 ├──────────────────┼────────────────────┼──────────────────┤
2412 │ │ │ │
2413 │id │ ID of echo │ integer (16 bit) │
2414 │ │ request/response │ │
2415 ├──────────────────┼────────────────────┼──────────────────┤
2416 │ │ │ │
2417 │sequence │ sequence number of │ integer (16 bit) │
2418 │ │ echo │ │
2419 │ │ request/response │ │
2420 ├──────────────────┼────────────────────┼──────────────────┤
2421 │ │ │ │
2422 │max-delay │ maximum response │ integer (16 bit) │
2423 │ │ delay of MLD │ │
2424 │ │ queries │ │
2425 └──────────────────┴────────────────────┴──────────────────┘
2426 TCP HEADER EXPRESSION
2428 tcp {sport | dport | sequence | ackseq | doff | reserved | flags | window | checksum | urgptr}
2429 Table 43. TCP header expression
2431 ┌─────────┬──────────────────┬──────────────────┐
2432 │Keyword │ Description │ Type │
2433 ├─────────┼──────────────────┼──────────────────┤
2434 │ │ │ │
2435 │sport │ Source port │ inet_service │
2436 ├─────────┼──────────────────┼──────────────────┤
2437 │ │ │ │
2438 │dport │ Destination port │ inet_service │
2439 ├─────────┼──────────────────┼──────────────────┤
2440 │ │ │ │
2441 │sequence │ Sequence number │ integer (32 bit) │
2442 ├─────────┼──────────────────┼──────────────────┤
2443 │ │ │ │
2444 │ackseq │ Acknowledgement │ integer (32 bit) │
2445 │ │ number │ │
2446 ├─────────┼──────────────────┼──────────────────┤
2447 │ │ │ │
2448 │doff │ Data offset │ integer (4 bit) │
2449 │ │ │ FIXME scaling │
2450 ├─────────┼──────────────────┼──────────────────┤
2451 │ │ │ │
2452 │reserved │ Reserved area │ integer (4 bit) │
2453 ├─────────┼──────────────────┼──────────────────┤
2454 │ │ │ │
2455 │flags │ TCP flags │ tcp_flag │
2456 ├─────────┼──────────────────┼──────────────────┤
2457 │ │ │ │
2458 │window │ Window │ integer (16 bit) │
2459 ├─────────┼──────────────────┼──────────────────┤
2460 │ │ │ │
2461 │checksum │ Checksum │ integer (16 bit) │
2462 ├─────────┼──────────────────┼──────────────────┤
2463 │ │ │ │
2464 │urgptr │ Urgent pointer │ integer (16 bit) │
2465 └─────────┴──────────────────┴──────────────────┘
2466 UDP HEADER EXPRESSION
2468 udp {sport | dport | length | checksum}
2469 Table 44. UDP header expression
2471 ┌─────────┬─────────────────────┬──────────────────┐
2472 │Keyword │ Description │ Type │
2473 ├─────────┼─────────────────────┼──────────────────┤
2474 │ │ │ │
2475 │sport │ Source port │ inet_service │
2476 ├─────────┼─────────────────────┼──────────────────┤
2477 │ │ │ │
2478 │dport │ Destination port │ inet_service │
2479 ├─────────┼─────────────────────┼──────────────────┤
2480 │ │ │ │
2481 │length │ Total packet length │ integer (16 bit) │
2482 ├─────────┼─────────────────────┼──────────────────┤
2483 │ │ │ │
2484 │checksum │ Checksum │ integer (16 bit) │
2485 └─────────┴─────────────────────┴──────────────────┘
2486 UDP-LITE HEADER EXPRESSION
2488 udplite {sport | dport | checksum}
2489 Table 45. UDP-Lite header expression
2491 ┌─────────┬──────────────────┬──────────────────┐
2492 │Keyword │ Description │ Type │
2493 ├─────────┼──────────────────┼──────────────────┤
2494 │ │ │ │
2495 │sport │ Source port │ inet_service │
2496 ├─────────┼──────────────────┼──────────────────┤
2497 │ │ │ │
2498 │dport │ Destination port │ inet_service │
2499 ├─────────┼──────────────────┼──────────────────┤
2500 │ │ │ │
2501 │checksum │ Checksum │ integer (16 bit) │
2502 └─────────┴──────────────────┴──────────────────┘
2503 SCTP HEADER EXPRESSION
2505 sctp {sport | dport | vtag | checksum}
2506 Table 46. SCTP header expression
2508 ┌─────────┬──────────────────┬──────────────────┐
2509 │Keyword │ Description │ Type │
2510 ├─────────┼──────────────────┼──────────────────┤
2511 │ │ │ │
2512 │sport │ Source port │ inet_service │
2513 ├─────────┼──────────────────┼──────────────────┤
2514 │ │ │ │
2515 │dport │ Destination port │ inet_service │
2516 ├─────────┼──────────────────┼──────────────────┤
2517 │ │ │ │
2518 │vtag │ Verification Tag │ integer (32 bit) │
2519 ├─────────┼──────────────────┼──────────────────┤
2520 │ │ │ │
2521 │checksum │ Checksum │ integer (32 bit) │
2522 └─────────┴──────────────────┴──────────────────┘
2523 DCCP HEADER EXPRESSION
2525 dccp {sport | dport}
2526 Table 47. DCCP header expression
2528 ┌────────┬──────────────────┬──────────────┐
2529 │Keyword │ Description │ Type │
2530 ├────────┼──────────────────┼──────────────┤
2531 │ │ │ │
2532 │sport │ Source port │ inet_service │
2533 ├────────┼──────────────────┼──────────────┤
2534 │ │ │ │
2535 │dport │ Destination port │ inet_service │
2536 └────────┴──────────────────┴──────────────┘
2537 AUTHENTICATION HEADER EXPRESSION
2539 ah {nexthdr | hdrlength | reserved | spi | sequence}
2540 Table 48. AH header expression
2542 ┌──────────┬────────────────────┬──────────────────┐
2543 │Keyword │ Description │ Type │
2544 ├──────────┼────────────────────┼──────────────────┤
2545 │ │ │ │
2546 │nexthdr │ Next header │ inet_proto │
2547 │ │ protocol │ │
2548 ├──────────┼────────────────────┼──────────────────┤
2549 │ │ │ │
2550 │hdrlength │ AH Header length │ integer (8 bit) │
2551 ├──────────┼────────────────────┼──────────────────┤
2552 │ │ │ │
2553 │reserved │ Reserved area │ integer (16 bit) │
2554 ├──────────┼────────────────────┼──────────────────┤
2555 │ │ │ │
2556 │spi │ Security Parameter │ integer (32 bit) │
2557 │ │ Index │ │
2558 ├──────────┼────────────────────┼──────────────────┤
2559 │ │ │ │
2560 │sequence │ Sequence number │ integer (32 bit) │
2561 └──────────┴────────────────────┴──────────────────┘
2562 ENCRYPTED SECURITY PAYLOAD HEADER EXPRESSION
2564 esp {spi | sequence}
2565 Table 49. ESP header expression
2567 ┌─────────┬────────────────────┬──────────────────┐
2568 │Keyword │ Description │ Type │
2569 ├─────────┼────────────────────┼──────────────────┤
2570 │ │ │ │
2571 │spi │ Security Parameter │ integer (32 bit) │
2572 │ │ Index │ │
2573 ├─────────┼────────────────────┼──────────────────┤
2574 │ │ │ │
2575 │sequence │ Sequence number │ integer (32 bit) │
2576 └─────────┴────────────────────┴──────────────────┘
2577 IPCOMP HEADER EXPRESSION
2579 comp {nexthdr | flags | cpi}
2580 Table 50. IPComp header expression
2582 ┌────────┬─────────────────┬──────────────────┐
2583 │Keyword │ Description │ Type │
2584 ├────────┼─────────────────┼──────────────────┤
2585 │ │ │ │
2586 │nexthdr │ Next header │ inet_proto │
2587 │ │ protocol │ │
2588 ├────────┼─────────────────┼──────────────────┤
2589 │ │ │ │
2590 │flags │ Flags │ bitmask │
2591 ├────────┼─────────────────┼──────────────────┤
2592 │ │ │ │
2593 │cpi │ compression │ integer (16 bit) │
2594 │ │ Parameter Index │ │
2595 └────────┴─────────────────┴──────────────────┘
2596 RAW PAYLOAD EXPRESSION
2598 @base,offset,length
2599 The raw payload expression instructs to load length bits starting at
2601 offset bits. Bit 0 refers to the very first bit — in the C programming
2602 language, this corresponds to the topmost bit, i.e. 0x80 in case of an
2603 octet. They are useful to match headers that do not have a
2604 human-readable template expression yet. Note that nft will not add
2605 dependencies for Raw payload expressions. If you e.g. want to match
2606 protocol fields of a transport header with protocol number 5, you need
2607 to manually exclude packets that have a different transport header, for
2608 instance by using meta l4proto 5 before the raw expression.
2609 Table 51. Supported payload protocol bases
2611 ┌─────┬─────────────────────────┐
2612 │Base │ Description │
2613 ├─────┼─────────────────────────┤
2614 │ │ │
2615 │ll │ Link layer, for example │
2616 │ │ the Ethernet header │
2617 ├─────┼─────────────────────────┤
2618 │ │ │
2619 │nh │ Network header, for │
2620 │ │ example IPv4 or IPv6 │
2621 ├─────┼─────────────────────────┤
2622 │ │ │
2623 │th │ Transport Header, for │
2624 │ │ example TCP │
2625 └─────┴─────────────────────────┘
2626 Matching destination port of both UDP and TCP.
2628 inet filter input meta l4proto {tcp, udp} @th,16,16 { 53, 80 }
2630 The above can also be written as
2632 inet filter input meta l4proto {tcp, udp} th dport { 53, 80 }
2634 it is more convenient, but like the raw expression notation no
2636 dependencies are created or checked. It is the users responsibility to
2637 restrict matching to those header types that have a notion of ports.
2638 Otherwise, rules using raw expressions will errnously match unrelated
2639 packets, e.g. mis-interpreting ESP packets SPI field as a port.
2640 Rewrite arp packet target hardware address if target protocol address
2642 matches a given address.
2643 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
2645 EXTENSION HEADER EXPRESSIONS
2648 Extension header expressions refer to data from variable-sized protocol
2649 headers, such as IPv6 extension headers, TCP options and IPv4 options.
2650 nftables currently supports matching (finding) a given ipv6 extension
2652 header, TCP option or IPv4 option.
2653 hbh {nexthdr | hdrlength}
2655 frag {nexthdr | frag-off | more-fragments | id}
2656 rt {nexthdr | hdrlength | type | seg-left}
2657 dst {nexthdr | hdrlength}
2658 mh {nexthdr | hdrlength | checksum | type}
2659 srh {flags | tag | sid | seg-left}
2660 tcp option {eol | noop | maxseg | window | sack-permitted | sack | sack0 | sack1 | sack2 | sack3 | timestamp} tcp_option_field
2661 ip option { lsrr | ra | rr | ssrr } ip_option_field
2662 The following syntaxes are valid only in a relational expression with
2664 boolean type on right-hand side for checking header existence only:
2665 exthdr {hbh | frag | rt | dst | mh}
2667 tcp option {eol | noop | maxseg | window | sack-permitted | sack | sack0 | sack1 | sack2 | sack3 | timestamp}
2668 ip option { lsrr | ra | rr | ssrr }
2669 Table 52. IPv6 extension headers
2671 ┌────────┬────────────────────────┐
2672 │Keyword │ Description │
2673 ├────────┼────────────────────────┤
2674 │ │ │
2675 │hbh │ Hop by Hop │
2676 ├────────┼────────────────────────┤
2677 │ │ │
2678 │rt │ Routing Header │
2679 ├────────┼────────────────────────┤
2680 │ │ │
2681 │frag │ Fragmentation header │
2682 ├────────┼────────────────────────┤
2683 │ │ │
2684 │dst │ dst options │
2685 ├────────┼────────────────────────┤
2686 │ │ │
2687 │mh │ Mobility Header │
2688 ├────────┼────────────────────────┤
2689 │ │ │
2690 │srh │ Segment Routing Header │
2691 └────────┴────────────────────────┘
2692 Table 53. TCP Options
2694 ┌───────────────┬─────────────────────┬─────────────────────┐
2695 │Keyword │ Description │ TCP option fields │
2696 ├───────────────┼─────────────────────┼─────────────────────┤
2697 │ │ │ │
2698 │eol │ End if option list │ kind │
2699 ├───────────────┼─────────────────────┼─────────────────────┤
2700 │ │ │ │
2701 │noop │ 1 Byte TCP No-op │ kind │
2702 │ │ options │ │
2703 ├───────────────┼─────────────────────┼─────────────────────┤
2704 │ │ │ │
2705 │maxseg │ TCP Maximum Segment │ kind, length, size │
2706 │ │ Size │ │
2707 ├───────────────┼─────────────────────┼─────────────────────┤
2708 │ │ │ │
2709 │window │ TCP Window Scaling │ kind, length, count │
2710 ├───────────────┼─────────────────────┼─────────────────────┤
2711 │ │ │ │
2712 │sack-permitted │ TCP SACK permitted │ kind, length │
2713 ├───────────────┼─────────────────────┼─────────────────────┤
2714 │ │ │ │
2715 │sack │ TCP Selective │ kind, length, left, │
2716 │ │ Acknowledgement │ right │
2717 │ │ (alias of block 0) │ │
2718 ├───────────────┼─────────────────────┼─────────────────────┤
2719 │ │ │ │
2720 │sack0 │ TCP Selective │ kind, length, left, │
2721 │ │ Acknowledgement │ right │
2722 │ │ (block 0) │ │
2723 ├───────────────┼─────────────────────┼─────────────────────┤
2724 │ │ │ │
2725 │sack1 │ TCP Selective │ kind, length, left, │
2726 │ │ Acknowledgement │ right │
2727 │ │ (block 1) │ │
2728 ├───────────────┼─────────────────────┼─────────────────────┤
2729 │ │ │ │
2730 │sack2 │ TCP Selective │ kind, length, left, │
2731 │ │ Acknowledgement │ right │
2732 │ │ (block 2) │ │
2733 ├───────────────┼─────────────────────┼─────────────────────┤
2734 │ │ │ │
2735 │sack3 │ TCP Selective │ kind, length, left, │
2736 │ │ Acknowledgement │ right │
2737 │ │ (block 3) │ │
2738 ├───────────────┼─────────────────────┼─────────────────────┤
2739 │ │ │ │
2740 │timestamp │ TCP Timestamps │ kind, length, │
2741 │ │ │ tsval, tsecr │
2742 └───────────────┴─────────────────────┴─────────────────────┘
2743 Table 54. IP Options
2745 ┌────────┬─────────────────────┬─────────────────────┐
2746 │Keyword │ Description │ IP option fields │
2747 ├────────┼─────────────────────┼─────────────────────┤
2748 │ │ │ │
2749 │lsrr │ Loose Source Route │ type, length, ptr, │
2750 │ │ │ addr │
2751 ├────────┼─────────────────────┼─────────────────────┤
2752 │ │ │ │
2753 │ra │ Router Alert │ type, length, value │
2754 ├────────┼─────────────────────┼─────────────────────┤
2755 │ │ │ │
2756 │rr │ Record Route │ type, length, ptr, │
2757 │ │ │ addr │
2758 ├────────┼─────────────────────┼─────────────────────┤
2759 │ │ │ │
2760 │ssrr │ Strict Source Route │ type, length, ptr, │
2761 │ │ │ addr │
2762 └────────┴─────────────────────┴─────────────────────┘
2763 finding TCP options.
2765 filter input tcp option sack-permitted kind 1 counter
2767 matching IPv6 exthdr.
2769 ip6 filter input frag more-fragments 1 counter
2771 finding IP option.
2773 filter input ip option lsrr exists counter
2775 CONNTRACK EXPRESSIONS
2778 Conntrack expressions refer to meta data of the connection tracking
2779 entry associated with a packet.
2780 There are three types of conntrack expressions. Some conntrack
2782 expressions require the flow direction before the conntrack key, others
2783 must be used directly because they are direction agnostic. The packets,
2784 bytes and avgpkt keywords can be used with or without a direction. If
2785 the direction is omitted, the sum of the original and the reply
2786 direction is returned. The same is true for the zone, if a direction is
2787 given, the zone is only matched if the zone id is tied to the given
2788 direction.
2789 ct {state | direction | status | mark | expiration | helper | label}
2791 ct [original | reply] {l3proto | protocol | bytes | packets | avgpkt | zone}
2792 ct {original | reply} {proto-src | proto-dst}
2793 ct {original | reply} {ip | ip6} {saddr | daddr}
2794 Table 55. Conntrack expressions
2796 ┌───────────┬─────────────────────┬─────────────────────┐
2797 │Keyword │ Description │ Type │
2798 ├───────────┼─────────────────────┼─────────────────────┤
2799 │ │ │ │
2800 │state │ State of the │ ct_state │
2801 │ │ connection │ │
2802 ├───────────┼─────────────────────┼─────────────────────┤
2803 │ │ │ │
2804 │direction │ Direction of the │ ct_dir │
2805 │ │ packet relative to │ │
2806 │ │ the connection │ │
2807 ├───────────┼─────────────────────┼─────────────────────┤
2808 │ │ │ │
2809 │status │ Status of the │ ct_status │
2810 │ │ connection │ │
2811 ├───────────┼─────────────────────┼─────────────────────┤
2812 │ │ │ │
2813 │mark │ Connection mark │ mark │
2814 ├───────────┼─────────────────────┼─────────────────────┤
2815 │ │ │ │
2816 │expiration │ Connection │ time │
2817 │ │ expiration time │ │
2818 ├───────────┼─────────────────────┼─────────────────────┤
2819 │ │ │ │
2820 │helper │ Helper associated │ string │
2821 │ │ with the connection │ │
2822 ├───────────┼─────────────────────┼─────────────────────┤
2823 │ │ │ │
2824 │label │ Connection tracking │ ct_label │
2825 │ │ label bit or │ │
2826 │ │ symbolic name │ │
2827 │ │ defined in │ │
2828 │ │ connlabel.conf in │ │
2829 │ │ the nftables │ │
2830 │ │ include path │ │
2831 ├───────────┼─────────────────────┼─────────────────────┤
2832 │ │ │ │
2833 │l3proto │ Layer 3 protocol of │ nf_proto │
2834 │ │ the connection │ │
2835 ├───────────┼─────────────────────┼─────────────────────┤
2836 │ │ │ │
2837 │saddr │ Source address of │ ipv4_addr/ipv6_addr │
2838 │ │ the connection for │ │
2839 │ │ the given direction │ │
2840 ├───────────┼─────────────────────┼─────────────────────┤
2841 │ │ │ │
2842 │daddr │ Destination address │ ipv4_addr/ipv6_addr │
2843 │ │ of the connection │ │
2844 │ │ for the given │ │
2845 │ │ direction │ │
2846 ├───────────┼─────────────────────┼─────────────────────┤
2847 │ │ │ │
2848 │protocol │ Layer 4 protocol of │ inet_proto │
2849 │ │ the connection for │ │
2850 │ │ the given direction │ │
2851 ├───────────┼─────────────────────┼─────────────────────┤
2852 │ │ │ │
2853 │proto-src │ Layer 4 protocol │ integer (16 bit) │
2854 │ │ source for the │ │
2855 │ │ given direction │ │
2856 ├───────────┼─────────────────────┼─────────────────────┤
2857 │ │ │ │
2858 │proto-dst │ Layer 4 protocol │ integer (16 bit) │
2859 │ │ destination for the │ │
2860 │ │ given direction │ │
2861 ├───────────┼─────────────────────┼─────────────────────┤
2862 │ │ │ │
2863 │packets │ packet count seen │ integer (64 bit) │
2864 │ │ in the given │ │
2865 │ │ direction or sum of │ │
2866 │ │ original and reply │ │
2867 ├───────────┼─────────────────────┼─────────────────────┤
2868 │ │ │ │
2869 │bytes │ byte count seen, │ integer (64 bit) │
2870 │ │ see description for │ │
2871 │ │ packets keyword │ │
2872 ├───────────┼─────────────────────┼─────────────────────┤
2873 │ │ │ │
2874 │avgpkt │ average bytes per │ integer (64 bit) │
2875 │ │ packet, see │ │
2876 │ │ description for │ │
2877 │ │ packets keyword │ │
2878 ├───────────┼─────────────────────┼─────────────────────┤
2879 │ │ │ │
2880 │zone │ conntrack zone │ integer (16 bit) │
2881 └───────────┴─────────────────────┴─────────────────────┘
2882 A description of conntrack-specific types listed above can be found
2884 sub-section CONNTRACK TYPES above.
2885 restrict the number of parallel connections to a server.
2887 filter input tcp dport 22 meter test { ip saddr ct count over 2 } reject
2889
2892 Statements represent actions to be performed. They can alter control
2893 flow (return, jump to a different chain, accept or drop the packet) or
2894 can perform actions, such as logging, rejecting a packet, etc.
2895 Statements exist in two kinds. Terminal statements unconditionally
2897 terminate evaluation of the current rule, non-terminal statements
2898 either only conditionally or never terminate evaluation of the current
2899 rule, in other words, they are passive from the ruleset evaluation
2900 perspective. There can be an arbitrary amount of non-terminal
2901 statements in a rule, but only a single terminal statement as the final
2902 statement.
2903 VERDICT STATEMENT
2905 The verdict statement alters control flow in the ruleset and issues
2906 policy decisions for packets.
2907 {accept | drop | queue | continue | return}
2909 {jump | goto} chain
2910 accept and drop are absolute verdicts — they terminate ruleset
2912 evaluation immediately.
2913 accept Terminate ruleset
2916 evaluation and accept the
2917 packet. The packet can
2918 still be dropped later by
2919 another hook, for instance
2920 accept in the forward hook
2921 still allows to drop the
2922 packet later in the
2923 postrouting hook, or
2924 another forward base chain
2925 that has a higher priority
2926 number and is evaluated
2927 afterwards in the
2928 processing pipeline.
2929 drop Terminate ruleset
2931 evaluation and drop the
2932 packet. The drop occurs
2933 instantly, no further
2934 chains or hooks are
2935 evaluated. It is not
2936 possible to accept the
2937 packet in a later chain
2938 again, as those are not
2939 evaluated anymore for the
2940 packet.
2941 queue Terminate ruleset
2943 evaluation and queue the
2944 packet to userspace.
2945 Userspace must provide a
2946 drop or accept verdict. In
2947 case of accept, processing
2948 resumes with the next base
2949 chain hook, not the rule
2950 following the queue
2951 verdict.
2952 continue Continue ruleset
2954 evaluation with the next
2955 rule. This is the default
2956 behaviour in case a rule
2957 issues no verdict.
2958 return Return from the current
2960 chain and continue
2961 evaluation at the next
2962 rule in the last chain. If
2963 issued in a base chain, it
2964 is equivalent to the base
2965 chain policy.
2966 jump chain Continue evaluation at the
2968 first rule in chain. The
2969 current position in the
2970 ruleset is pushed to a
2971 call stack and evaluation
2972 will continue there when
2973 the new chain is entirely
2974 evaluated or a return
2975 verdict is issued. In case
2976 an absolute verdict is
2977 issued by a rule in the
2978 chain, ruleset evaluation
2979 terminates immediately and
2980 the specific action is
2981 taken.
2982 goto chain Similar to jump, but the
2984 current position is not
2985 pushed to the call stack,
2986 meaning that after the new
2987 chain evaluation will
2988 continue at the last chain
2989 instead of the one
2990 containing the goto
2991 statement.
2992 Using verdict statements.
2995 # process packets from eth0 and the internal network in from_lan
2997 # chain, drop all packets from eth0 with different source addresses.
2998 filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan
3000 filter input iif eth0 drop
3001 PAYLOAD STATEMENT
3004 payload_expression set value
3005 The payload statement alters packet content. It can be used for example
3007 to set ip DSCP (diffserv) header field or ipv6 flow labels.
3008 route some packets instead of bridging.
3010 # redirect tcp:http from 192.160.0.0/16 to local machine for routing instead of bridging
3012 # assumes 00:11:22:33:44:55 is local MAC address.
3013 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
3014 Set IPv4 DSCP header field.
3016 ip forward ip dscp set 42
3018 EXTENSION HEADER STATEMENT
3021 extension_header_expression set value
3022 The extension header statement alters packet content in variable-sized
3024 headers. This can currently be used to alter the TCP Maximum segment
3025 size of packets, similar to TCPMSS.
3026 change tcp mss.
3028 tcp flags syn tcp option maxseg size set 1360
3030 # set a size based on route information:
3031 tcp flags syn tcp option maxseg size set rt mtu
3032 LOG STATEMENT
3035 log [prefix quoted_string] [level syslog-level] [flags log-flags]
3036 log group nflog_group [prefix quoted_string] [queue-threshold value] [snaplen size]
3037 log level audit
3038 The log statement enables logging of matching packets. When this
3040 statement is used from a rule, the Linux kernel will print some
3041 information on all matching packets, such as header fields, via the
3042 kernel log (where it can be read with dmesg(1) or read in the syslog).
3043 In the second form of invocation (if nflog_group is specified), the
3045 Linux kernel will pass the packet to nfnetlink_log which will multicast
3046 the packet through a netlink socket to the specified multicast group.
3047 One or more userspace processes may subscribe to the group to receive
3048 the packets, see libnetfilter_queue documentation for details.
3049 In the third form of invocation (if level audit is specified), the
3051 Linux kernel writes a message into the audit buffer suitably formatted
3052 for reading with auditd. Therefore no further formatting options (such
3053 as prefix or flags) are allowed in this mode.
3054 This is a non-terminating statement, so the rule evaluation continues
3056 after the packet is logged.
3057 Table 56. log statement options
3059 ┌────────────────┬─────────────────────┬───────────────────┐
3060 │Keyword │ Description │ Type │
3061 ├────────────────┼─────────────────────┼───────────────────┤
3062 │ │ │ │
3063 │prefix │ Log message prefix │ quoted string │
3064 ├────────────────┼─────────────────────┼───────────────────┤
3065 │ │ │ │
3066 │level │ Syslog level of │ string: emerg, │
3067 │ │ logging │ alert, crit, err, │
3068 │ │ │ warn [default], │
3069 │ │ │ notice, info, │
3070 │ │ │ debug, audit │
3071 ├────────────────┼─────────────────────┼───────────────────┤
3072 │ │ │ │
3073 │group │ NFLOG group to send │ unsigned integer │
3074 │ │ messages to │ (16 bit) │
3075 ├────────────────┼─────────────────────┼───────────────────┤
3076 │ │ │ │
3077 │snaplen │ Length of packet │ unsigned integer │
3078 │ │ payload to include │ (32 bit) │
3079 │ │ in netlink message │ │
3080 ├────────────────┼─────────────────────┼───────────────────┤
3081 │ │ │ │
3082 │queue-threshold │ Number of packets │ unsigned integer │
3083 │ │ to queue inside the │ (32 bit) │
3084 │ │ kernel before │ │
3085 │ │ sending them to │ │
3086 │ │ userspace │ │
3087 └────────────────┴─────────────────────┴───────────────────┘
3088 Table 57. log-flags
3090 ┌─────────────┬───────────────────────────┐
3091 │Flag │ Description │
3092 ├─────────────┼───────────────────────────┤
3093 │ │ │
3094 │tcp sequence │ Log TCP sequence numbers. │
3095 ├─────────────┼───────────────────────────┤
3096 │ │ │
3097 │tcp options │ Log options from the TCP │
3098 │ │ packet header. │
3099 ├─────────────┼───────────────────────────┤
3100 │ │ │
3101 │ip options │ Log options from the │
3102 │ │ IP/IPv6 packet header. │
3103 ├─────────────┼───────────────────────────┤
3104 │ │ │
3105 │skuid │ Log the userid of the │
3106 │ │ process which generated │
3107 │ │ the packet. │
3108 ├─────────────┼───────────────────────────┤
3109 │ │ │
3110 │ether │ Decode MAC addresses and │
3111 │ │ protocol. │
3112 ├─────────────┼───────────────────────────┤
3113 │ │ │
3114 │all │ Enable all log flags │
3115 │ │ listed above. │
3116 └─────────────┴───────────────────────────┘
3117 Using log statement.
3119 # log the UID which generated the packet and ip options
3121 ip filter output log flags skuid flags ip options
3122 # log the tcp sequence numbers and tcp options from the TCP packet
3124 ip filter output log flags tcp sequence,options
3125 # enable all supported log flags
3127 ip6 filter output log flags all
3128 REJECT STATEMENT
3131 reject [ with REJECT_WITH ]
3132 REJECT_WITH := icmp type icmp_code |
3134 icmpv6 type icmpv6_code |
3135 icmpx type icmpx_code |
3136 tcp reset
3137 A reject statement is used to send back an error packet in response to
3139 the matched packet otherwise it is equivalent to drop so it is a
3140 terminating statement, ending rule traversal. This statement is only
3141 valid in the input, forward and output chains, and user-defined chains
3142 which are only called from those chains.
3143 Table 58. different ICMP reject variants are meant for use in different
3145 table families
3146 ┌────────┬────────┬─────────────┐
3147 │Variant │ Family │ Type │
3148 ├────────┼────────┼─────────────┤
3149 │ │ │ │
3150 │icmp │ ip │ icmp_code │
3151 ├────────┼────────┼─────────────┤
3152 │ │ │ │
3153 │icmpv6 │ ip6 │ icmpv6_code │
3154 ├────────┼────────┼─────────────┤
3155 │ │ │ │
3156 │icmpx │ inet │ icmpx_code │
3157 └────────┴────────┴─────────────┘
3158 For a description of the different types and a list of supported
3160 keywords refer to DATA TYPES section above. The common default reject
3161 value is port-unreachable.
3162 Note that in bridge family, reject statement is only allowed in base
3164 chains which hook into input or prerouting.
3165 COUNTER STATEMENT
3167 A counter statement sets the hit count of packets along with the number
3168 of bytes.
3169 counter packets number bytes number
3171 counter { packets number | bytes number }
3172 CONNTRACK STATEMENT
3174 The conntrack statement can be used to set the conntrack mark and
3175 conntrack labels.
3176 ct {mark | event | label | zone} set value
3178 The ct statement sets meta data associated with a connection. The zone
3180 id has to be assigned before a conntrack lookup takes place, i.e. this
3181 has to be done in prerouting and possibly output (if locally generated
3182 packets need to be placed in a distinct zone), with a hook priority of
3183 -300.
3184 Table 59. Conntrack statement types
3186 ┌────────┬─────────────────────┬──────────────────┐
3187 │Keyword │ Description │ Value │
3188 ├────────┼─────────────────────┼──────────────────┤
3189 │ │ │ │
3190 │event │ conntrack event │ bitmask, integer │
3191 │ │ bits │ (32 bit) │
3192 ├────────┼─────────────────────┼──────────────────┤
3193 │ │ │ │
3194 │helper │ name of ct helper │ quoted string │
3195 │ │ object to assign to │ │
3196 │ │ the connection │ │
3197 ├────────┼─────────────────────┼──────────────────┤
3198 │ │ │ │
3199 │mark │ Connection tracking │ mark │
3200 │ │ mark │ │
3201 ├────────┼─────────────────────┼──────────────────┤
3202 │ │ │ │
3203 │label │ Connection tracking │ label │
3204 │ │ label │ │
3205 ├────────┼─────────────────────┼──────────────────┤
3206 │ │ │ │
3207 │zone │ conntrack zone │ integer (16 bit) │
3208 └────────┴─────────────────────┴──────────────────┘
3209 save packet nfmark in conntrack.
3211 ct mark set meta mark
3213 set zone mapped via interface.
3215 table inet raw {
3217 chain prerouting {
3218 type filter hook prerouting priority -300;
3219 ct zone set iif map { "eth1" : 1, "veth1" : 2 }
3220 }
3221 chain output {
3222 type filter hook output priority -300;
3223 ct zone set oif map { "eth1" : 1, "veth1" : 2 }
3224 }
3225 }
3226 restrict events reported by ctnetlink.
3228 ct event set new,related,destroy
3230 META STATEMENT
3233 A meta statement sets the value of a meta expression. The existing meta
3234 fields are: priority, mark, pkttype, nftrace.
3235 meta {mark | priority | pkttype | nftrace} set value
3237 A meta statement sets meta data associated with a packet.
3239 Table 60. Meta statement types
3241 ┌─────────┬─────────────────────┬───────────┐
3242 │Keyword │ Description │ Value │
3243 ├─────────┼─────────────────────┼───────────┤
3244 │ │ │ │
3245 │priority │ TC packet priority │ tc_handle │
3246 ├─────────┼─────────────────────┼───────────┤
3247 │ │ │ │
3248 │mark │ Packet mark │ mark │
3249 ├─────────┼─────────────────────┼───────────┤
3250 │ │ │ │
3251 │pkttype │ packet type │ pkt_type │
3252 ├─────────┼─────────────────────┼───────────┤
3253 │ │ │ │
3254 │nftrace │ ruleset packet │ 0, 1 │
3255 │ │ tracing on/off. Use │ │
3256 │ │ monitor trace │ │
3257 │ │ command to watch │ │
3258 │ │ traces │ │
3259 └─────────┴─────────────────────┴───────────┘
3260 LIMIT STATEMENT
3262 limit rate [over] packet_number / TIME_UNIT [burst packet_number packets]
3263 limit rate [over] byte_number BYTE_UNIT / TIME_UNIT [burst byte_number BYTE_UNIT]
3264 TIME_UNIT := second | minute | hour | day
3266 BYTE_UNIT := bytes | kbytes | mbytes
3267 A limit statement matches at a limited rate using a token bucket
3269 filter. A rule using this statement will match until this limit is
3270 reached. It can be used in combination with the log statement to give
3271 limited logging. The optional over keyword makes it match over the
3272 specified rate.
3273 Table 61. limit statement values
3275 ┌──────────────┬───────────────────┬──────────────────┐
3276 │Value │ Description │ Type │
3277 ├──────────────┼───────────────────┼──────────────────┤
3278 │ │ │ │
3279 │packet_number │ Number of packets │ unsigned integer │
3280 │ │ │ (32 bit) │
3281 ├──────────────┼───────────────────┼──────────────────┤
3282 │ │ │ │
3283 │byte_number │ Number of bytes │ unsigned integer │
3284 │ │ │ (32 bit) │
3285 └──────────────┴───────────────────┴──────────────────┘
3286 NAT STATEMENTS
3288 snat to address [:port] [PRF_FLAGS]
3289 snat to address - address [:port - port] [PRF_FLAGS]
3290 snat { ip | ip6 } to address - address [:port - port] [PR_FLAGS]
3291 dnat to address [:port] [PRF_FLAGS]
3292 dnat to address [:port - port] [PR_FLAGS]
3293 dnat { ip | ip6 } to address [:port - port] [PR_FLAGS]
3294 masquerade to [:port] [PRF_FLAGS]
3295 masquerade to [:port - port] [PRF_FLAGS]
3296 redirect to [:port] [PRF_FLAGS]
3297 redirect to [:port - port] [PRF_FLAGS]
3298 PRF_FLAGS := PRF_FLAG [, PRF_FLAGS]
3300 PR_FLAGS := PR_FLAG [, PR_FLAGS]
3301 PRF_FLAG := PR_FLAG | fully-random
3302 PR_FLAG := persistent | random
3303 The nat statements are only valid from nat chain types.
3305 The snat and masquerade statements specify that the source address of
3307 the packet should be modified. While snat is only valid in the
3308 postrouting and input chains, masquerade makes sense only in
3309 postrouting. The dnat and redirect statements are only valid in the
3310 prerouting and output chains, they specify that the destination address
3311 of the packet should be modified. You can use non-base chains which are
3312 called from base chains of nat chain type too. All future packets in
3313 this connection will also be mangled, and rules should cease being
3314 examined.
3315 The masquerade statement is a special form of snat which always uses
3317 the outgoing interface’s IP address to translate to. It is particularly
3318 useful on gateways with dynamic (public) IP addresses.
3319 The redirect statement is a special form of dnat which always
3321 translates the destination address to the local host’s one. It comes in
3322 handy if one only wants to alter the destination port of incoming
3323 traffic on different interfaces.
3324 When used in the inet family (available with kernel 5.2), the dnat and
3326 snat statements require the use of the ip and ip6 keyword in case an
3327 address is provided, see the examples below.
3328 Before kernel 4.18 nat statements require both prerouting and
3330 postrouting base chains to be present since otherwise packets on the
3331 return path won’t be seen by netfilter and therefore no reverse
3332 translation will take place.
3333 Table 62. NAT statement values
3335 ┌───────────┬─────────────────────┬─────────────────────┐
3336 │Expression │ Description │ Type │
3337 ├───────────┼─────────────────────┼─────────────────────┤
3338 │ │ │ │
3339 │address │ Specifies that the │ ipv4_addr, │
3340 │ │ source/destination │ ipv6_addr, e.g. │
3341 │ │ address of the │ abcd::1234, or you │
3342 │ │ packet should be │ can use a mapping, │
3343 │ │ modified. You may │ e.g. meta mark map │
3344 │ │ specify a mapping │ { 10 : 192.168.1.2, │
3345 │ │ to relate a list of │ 20 : 192.168.1.3 } │
3346 │ │ tuples composed of │ │
3347 │ │ arbitrary │ │
3348 │ │ expression key with │ │
3349 │ │ address value. │ │
3350 ├───────────┼─────────────────────┼─────────────────────┤
3351 │ │ │ │
3352 │port │ Specifies that the │ port number (16 │
3353 │ │ source/destination │ bit) │
3354 │ │ address of the │ │
3355 │ │ packet should be │ │
3356 │ │ modified. │ │
3357 └───────────┴─────────────────────┴─────────────────────┘
3358 Table 63. NAT statement flags
3360 ┌─────────────┬─────────────────────────────┐
3361 │Flag │ Description │
3362 ├─────────────┼─────────────────────────────┤
3363 │ │ │
3364 │persistent │ Gives a client the same │
3365 │ │ source-/destination-address │
3366 │ │ for each connection. │
3367 ├─────────────┼─────────────────────────────┤
3368 │ │ │
3369 │random │ In kernel 5.0 and newer │
3370 │ │ this is the same as │
3371 │ │ fully-random. In earlier │
3372 │ │ kernels the port mapping │
3373 │ │ will be randomized using a │
3374 │ │ seeded MD5 hash mix using │
3375 │ │ source and destination │
3376 │ │ address and destination │
3377 │ │ port. │
3378 ├─────────────┼─────────────────────────────┤
3379 │ │ │
3380 │fully-random │ If used then port mapping │
3381 │ │ is generated based on a │
3382 │ │ 32-bit pseudo-random │
3383 │ │ algorithm. │
3384 └─────────────┴─────────────────────────────┘
3385 Using NAT statements.
3387 # create a suitable table/chain setup for all further examples
3389 add table nat
3390 add chain nat prerouting { type nat hook prerouting priority 0; }
3391 add chain nat postrouting { type nat hook postrouting priority 100; }
3392 # translate source addresses of all packets leaving via eth0 to address 1.2.3.4
3394 add rule nat postrouting oif eth0 snat to 1.2.3.4
3395 # redirect all traffic entering via eth0 to destination address 192.168.1.120
3397 add rule nat prerouting iif eth0 dnat to 192.168.1.120
3398 # translate source addresses of all packets leaving via eth0 to whatever
3400 # locally generated packets would use as source to reach the same destination
3401 add rule nat postrouting oif eth0 masquerade
3402 # redirect incoming TCP traffic for port 22 to port 2222
3404 add rule nat prerouting tcp dport 22 redirect to :2222
3405 # inet family:
3407 # handle ip dnat:
3408 add rule inet nat prerouting dnat ip to 10.0.2.99
3409 # handle ip6 dnat:
3410 add rule inet nat prerouting dnat ip6 to fe80::dead
3411 # this masquerades both ipv4 and ipv6:
3412 add rule inet nat postrouting meta oif ppp0 masquerade
3413 TPROXY STATEMENT
3416 Tproxy redirects the packet to a local socket without changing the
3417 packet header in any way. If any of the arguments is missing the data
3418 of the incoming packet is used as parameter. Tproxy matching requires
3419 another rule that ensures the presence of transport protocol header is
3420 specified.
3421 tproxy to address:port
3423 tproxy to {address | :port}
3424 This syntax can be used in ip/ip6 tables where network layer protocol
3426 is obvious. Either IP address or port can be specified, but at least
3427 one of them is necessary.
3428 tproxy {ip | ip6} to address[:port]
3430 tproxy to :port
3431 This syntax can be used in inet tables. The ip/ip6 parameter defines
3433 the family the rule will match. The address parameter must be of this
3434 family. When only port is defined, the address family should not be
3435 specified. In this case the rule will match for both families.
3436 Table 64. tproxy attributes
3438 ┌────────┬────────────────────────────┐
3439 │Name │ Description │
3440 ├────────┼────────────────────────────┤
3441 │ │ │
3442 │address │ IP address the listening │
3443 │ │ socket with IP_TRANSPARENT │
3444 │ │ option is bound to. │
3445 ├────────┼────────────────────────────┤
3446 │ │ │
3447 │port │ Port the listening socket │
3448 │ │ with IP_TRANSPARENT option │
3449 │ │ is bound to. │
3450 └────────┴────────────────────────────┘
3451 Example ruleset for tproxy statement.
3453 table ip x {
3455 chain y {
3456 type filter hook prerouting priority -150; policy accept;
3457 tcp dport ntp tproxy to 1.1.1.1
3458 udp dport ssh tproxy to :2222
3459 }
3460 }
3461 table ip6 x {
3462 chain y {
3463 type filter hook prerouting priority -150; policy accept;
3464 tcp dport ntp tproxy to [dead::beef]
3465 udp dport ssh tproxy to :2222
3466 }
3467 }
3468 table inet x {
3469 chain y {
3470 type filter hook prerouting priority -150; policy accept;
3471 tcp dport 321 tproxy to :ssh
3472 tcp dport 99 tproxy ip to 1.1.1.1:999
3473 udp dport 155 tproxy ip6 to [dead::beef]:smux
3474 }
3475 }
3476 SYNPROXY STATEMENT
3479 This statement will process TCP three-way-handshake parallel in
3480 netfilter context to protect either local or backend system. This
3481 statement requires connection tracking because sequence numbers need to
3482 be translated.
3483 synproxy [mss mss_value] [wscale wscale_value] [SYNPROXY_FLAGS]
3485 Table 65. synproxy statement attributes
3487 ┌───────┬────────────────────────────┐
3488 │Name │ Description │
3489 ├───────┼────────────────────────────┤
3490 │ │ │
3491 │mss │ Maximum segment size │
3492 │ │ announced to clients. This │
3493 │ │ must match the backend. │
3494 ├───────┼────────────────────────────┤
3495 │ │ │
3496 │wscale │ Window scale announced to │
3497 │ │ clients. This must match │
3498 │ │ the backend. │
3499 └───────┴────────────────────────────┘
3500 Table 66. synproxy statement flags
3502 ┌──────────┬────────────────────────────┐
3503 │Flag │ Description │
3504 ├──────────┼────────────────────────────┤
3505 │ │ │
3506 │sack-perm │ Pass client selective │
3507 │ │ acknowledgement option to │
3508 │ │ backend (will be disabled │
3509 │ │ if not present). │
3510 ├──────────┼────────────────────────────┤
3511 │ │ │
3512 │timestamp │ Pass client timestamp │
3513 │ │ option to backend (will be │
3514 │ │ disabled if not present, │
3515 │ │ also needed for selective │
3516 │ │ acknowledgement and window │
3517 │ │ scaling). │
3518 └──────────┴────────────────────────────┘
3519 Example ruleset for synproxy statement.
3521 Determine tcp options used by backend, from an external system
3523 tcpdump -pni eth0 -c 1 'tcp[tcpflags] == (tcp-syn|tcp-ack)'
3525 port 80 &
3526 telnet 192.0.2.42 80
3527 18:57:24.693307 IP 192.0.2.42.80 > 192.0.2.43.48757:
3528 Flags [S.], seq 360414582, ack 788841994, win 14480,
3529 options [mss 1460,sackOK,
3530 TS val 1409056151 ecr 9690221,
3531 nop,wscale 9],
3532 length 0
3533 Switch tcp_loose mode off, so conntrack will mark out-of-flow packets as state INVALID.
3535 echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
3537 Make SYN packets untracked.
3539 table ip x {
3541 chain y {
3542 type filter hook prerouting priority raw; policy accept;
3543 tcp flags syn notrack
3544 }
3545 }
3546 Catch UNTRACKED (SYN packets) and INVALID (3WHS ACK packets) states and send
3548 them to SYNPROXY. This rule will respond to SYN packets with SYN+ACK
3549 syncookies, create ESTABLISHED for valid client response (3WHS ACK packets) and
3550 drop incorrect cookies. Flags combinations not expected during 3WHS will not
3551 match and continue (e.g. SYN+FIN, SYN+ACK). Finally, drop invalid packets, this
3552 will be out-of-flow packets that were not matched by SYNPROXY.
3553 table ip foo {
3555 chain z {
3556 type filter hook input priority filter; policy accept;
3557 ct state { invalid, untracked } synproxy mss 1460 wscale 9 timestamp sack-perm
3558 ct state invalid drop
3559 }
3560 }
3561 The outcome ruleset of the steps above should be similar to the one below.
3563 table ip x {
3565 chain y {
3566 type filter hook prerouting priority raw; policy accept;
3567 tcp flags syn notrack
3568 }
3569 chain z {
3571 type filter hook input priority filter; policy accept;
3572 ct state { invalid, untracked } synproxy mss 1460 wscale 9 timestamp sack-perm
3573 ct state invalid drop
3574 }
3575 }
3576 FLOW STATEMENT
3579 A flow statement allows us to select what flows you want to accelerate
3580 forwarding through layer 3 network stack bypass. You have to specify
3581 the flowtable name where you want to offload this flow.
3582 flow add @flowtable
3584 QUEUE STATEMENT
3586 This statement passes the packet to userspace using the nfnetlink_queue
3587 handler. The packet is put into the queue identified by its 16-bit
3588 queue number. Userspace can inspect and modify the packet if desired.
3589 Userspace must then drop or re-inject the packet into the kernel. See
3590 libnetfilter_queue documentation for details.
3591 queue [num queue_number] [bypass]
3593 queue [num queue_number_from - queue_number_to] [QUEUE_FLAGS]
3594 QUEUE_FLAGS := QUEUE_FLAG [, QUEUE_FLAGS]
3596 QUEUE_FLAG := bypass | fanout
3597 Table 67. queue statement values
3599 ┌──────────────────┬────────────────────┬──────────────────┐
3600 │Value │ Description │ Type │
3601 ├──────────────────┼────────────────────┼──────────────────┤
3602 │ │ │ │
3603 │queue_number │ Sets queue number, │ unsigned integer │
3604 │ │ default is 0. │ (16 bit) │
3605 ├──────────────────┼────────────────────┼──────────────────┤
3606 │ │ │ │
3607 │queue_number_from │ Sets initial queue │ unsigned integer │
3608 │ │ in the range, if │ (16 bit) │
3609 │ │ fanout is used. │ │
3610 ├──────────────────┼────────────────────┼──────────────────┤
3611 │ │ │ │
3612 │queue_number_to │ Sets closing queue │ unsigned integer │
3613 │ │ in the range, if │ (16 bit) │
3614 │ │ fanout is used. │ │
3615 └──────────────────┴────────────────────┴──────────────────┘
3616 Table 68. queue statement flags
3618 ┌───────┬────────────────────────────┐
3619 │Flag │ Description │
3620 ├───────┼────────────────────────────┤
3621 │ │ │
3622 │bypass │ Let packets go through if │
3623 │ │ userspace application │
3624 │ │ cannot back off. Before │
3625 │ │ using this flag, read │
3626 │ │ libnetfilter_queue │
3627 │ │ documentation for │
3628 │ │ performance tuning │
3629 │ │ recommendations. │
3630 ├───────┼────────────────────────────┤
3631 │ │ │
3632 │fanout │ Distribute packets between │
3633 │ │ several queues. │
3634 └───────┴────────────────────────────┘
3635 DUP STATEMENT
3637 The dup statement is used to duplicate a packet and send the copy to a
3638 different destination.
3639 dup to device
3641 dup to address device device
3642 Table 69. Dup statement values
3644 ┌───────────┬─────────────────────┬─────────────────────┐
3645 │Expression │ Description │ Type │
3646 ├───────────┼─────────────────────┼─────────────────────┤
3647 │ │ │ │
3648 │address │ Specifies that the │ ipv4_addr, │
3649 │ │ copy of the packet │ ipv6_addr, e.g. │
3650 │ │ should be sent to a │ abcd::1234, or you │
3651 │ │ new gateway. │ can use a mapping, │
3652 │ │ │ e.g. ip saddr map { │
3653 │ │ │ 192.168.1.2 : │
3654 │ │ │ 10.1.1.1 } │
3655 ├───────────┼─────────────────────┼─────────────────────┤
3656 │ │ │ │
3657 │device │ Specifies that the │ string │
3658 │ │ copy should be │ │
3659 │ │ transmitted via │ │
3660 │ │ device. │ │
3661 └───────────┴─────────────────────┴─────────────────────┘
3662 Using the dup statement.
3664 # send to machine with ip address 10.2.3.4 on eth0
3666 ip filter forward dup to 10.2.3.4 device "eth0"
3667 # copy raw frame to another interface
3669 netdetv ingress dup to "eth0"
3670 dup to "eth0"
3671 # combine with map dst addr to gateways
3673 dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" }
3674 FWD STATEMENT
3677 The fwd statement is used to redirect a raw packet to another
3678 interface. It is only available in the netdev family ingress hook. It
3679 is similar to the dup statement except that no copy is made.
3680 fwd to device
3682 SET STATEMENT
3684 The set statement is used to dynamically add or update elements in a
3685 set from the packet path. The set setname must already exist in the
3686 given table and must have been created with one or both of the dynamic
3687 and the timeout flags. The dynamic flag is required if the set
3688 statement expression includes a stateful object. The timeout flag is
3689 implied if the set is created with a timeout, and is required if the
3690 set statement updates elements, rather than adding them. Furthermore,
3691 these sets should specify both a maximum set size (to prevent memory
3692 exhaustion), and their elements should have a timeout (so their number
3693 will not grow indefinitely) either from the set definition or from the
3694 statement that adds or updates them. The set statement can be used to
3695 e.g. create dynamic blacklists.
3696 {add | update} @setname { expression [timeout timeout] [comment string] }
3698 Example for simple blacklist.
3700 # declare a set, bound to table "filter", in family "ip". Timeout and size are mandatory because we will add elements from packet path.
3702 nft add set ip filter blackhole "{ type ipv4_addr; flags timeout; size 65536; }"
3703 # whitelist internal interface.
3705 nft add rule ip filter input meta iifname "internal" accept
3706 # drop packets coming from blacklisted ip addresses.
3708 nft add rule ip filter input ip saddr @blackhole counter drop
3709 # add source ip addresses to the blacklist if more than 10 tcp connection requests occurred per second and ip address.
3711 # entries will timeout after one minute, after which they might be re-added if limit condition persists.
3712 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
3713 # inspect state of the rate limit meter:
3715 nft list meter ip filter flood
3716 # inspect content of blackhole:
3718 nft list set ip filter blackhole
3719 # manually add two addresses to the set:
3721 nft add element filter blackhole { 10.2.3.4, 10.23.1.42 }
3722 MAP STATEMENT
3725 The map statement is used to lookup data based on some specific input
3726 key.
3727 expression map { MAP_ELEMENTS }
3729 MAP_ELEMENTS := MAP_ELEMENT [, MAP_ELEMENTS]
3731 MAP_ELEMENT := key : value
3732 The key is a value returned by expression.
3734 Using the map statement.
3736 # select DNAT target based on TCP dport:
3738 # connections to port 80 are redirected to 192.168.1.100,
3739 # connections to port 8888 are redirected to 192.168.1.101
3740 nft add rule ip nat prerouting dnat tcp dport map { 80 : 192.168.1.100, 8888 : 192.168.1.101 }
3741 # source address based SNAT:
3743 # packets from net 192.168.1.0/24 will appear as originating from 10.0.0.1,
3744 # packets from net 192.168.2.0/24 will appear as originating from 10.0.0.2
3745 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 }
3746 VMAP STATEMENT
3749 The verdict map (vmap) statement works analogous to the map statement,
3750 but contains verdicts as values.
3751 expression vmap { VMAP_ELEMENTS }
3753 VMAP_ELEMENTS := VMAP_ELEMENT [, VMAP_ELEMENTS]
3755 VMAP_ELEMENT := key : verdict
3756 Using the vmap statement.
3758 # jump to different chains depending on layer 4 protocol type:
3760 nft add rule ip filter input ip protocol vmap { tcp : jump tcp-chain, udp : jump udp-chain , icmp : jump icmp-chain }
3761
3764 These are some additional commands included in nft.
3765 MONITOR
3767 The monitor command allows you to listen to Netlink events produced by
3768 the nf_tables subsystem, related to creation and deletion of objects.
3769 When they occur, nft will print to stdout the monitored events in
3770 either JSON or native nft format.
3771 To filter events related to a concrete object, use one of the keywords
3773 tables, chains, sets, rules, elements, ruleset.
3774 To filter events related to a concrete action, use keyword new or
3776 destroy.
3777 Hit ^C to finish the monitor operation.
3779 Listen to all events, report in native nft format.
3781 % nft monitor
3783 Listen to deleted rules, report in JSON format.
3785 % nft -j monitor destroy rules
3787 Listen to both new and destroyed chains, in native nft format.
3789 % nft monitor chains
3791 Listen to ruleset events such as table, chain, rule, set, counters and
3793 quotas, in native nft format.
3794 % nft monitor ruleset
3796
3799 When an error is detected, nft shows the line(s) containing the error,
3800 the position of the erroneous parts in the input stream and marks up
3801 the erroneous parts using carets (^). If the error results from the
3802 combination of two expressions or statements, the part imposing the
3803 constraints which are violated is marked using tildes (~).
3804 For errors returned by the kernel, nft cannot detect which parts of the
3806 input caused the error and the entire command is marked.
3807 Error caused by single incorrect expression.
3809 <cmdline>:1:19-22: Error: Interface does not exist
3811 filter output oif eth0
3812 ^^^^
3813 Error caused by invalid combination of two expressions.
3815 <cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
3817 filter output tcp dport == tcp dport
3818 ~~ ^^^^^^^^^
3819 Error returned by the kernel.
3821 <cmdline>:0:0-23: Error: Could not process rule: Operation not permitted
3823 filter output oif wlan0
3824 ^^^^^^^^^^^^^^^^^^^^^^^
3825
3828 On success, nft exits with a status of 0. Unspecified errors cause it
3829 to exit with a status of 1, memory allocation errors with a status of
3830 2, unable to open Netlink socket with 3.
3831
3833 libnftables(3), libnftables-json(5), iptables(8), ip6tables(8), arptables(8), ebtables(8), ip(8), tc(8)
3834 There is an official wiki at: https://wiki.nftables.org
3836
3838 nftables was written by Patrick McHardy and Pablo Neira Ayuso, among
3839 many other contributors from the Netfilter community.
3840
3842 Copyright © 2008-2014 Patrick McHardy <kaber@trash.net> Copyright ©
3843 2013-2018 Pablo Neira Ayuso <pablo@netfilter.org>
3844 nftables is free software; you can redistribute it and/or modify it
3846 under the terms of the GNU General Public License version 2 as
3847 published by the Free Software Foundation.
3848 This documentation is licensed under the terms of the Creative Commons
3850 Attribution-ShareAlike 4.0 license, CC BY-SA 4.0
3851 http://creativecommons.org/licenses/by-sa/4.0/.
3852 01/29/2020 NFT(8)