1nft(8) nft(8)
2
6 nft - Administration tool for packet filtering and classification
7
9 nft [-n | --numeric] [-N | --reversedns] [-s | --stateless] [-c |
10 --check] [-a | --handle] [-e | --echo] [ {-I | --includepath}
11 directory ] [ {-f | --file} filename | {-i | --interactive} | cmd
12 ...]
13 nft [-h | --help] [-v | --version]
14
16 nft is used to set up, maintain and inspect packet filtering and clas‐
17 sification rules in the Linux kernel.
18
20 For a full summary of options, run nft --help.
21 -h, --help
23 Show help message and all options.
24 -v, --version
26 Show version.
27 -n, --numeric
29 Show data numerically. When used once (the default behaviour),
30 skip lookup of addresses to symbolic names. Use twice to also
31 show Internet services (port numbers) numerically. Use three
32 times to also show protocols and UIDs/GIDs numerically.
33 -s, --stateless
35 Omit stateful information of rules and stateful objects.
36 -c, --check
38 Check commands validity without actually applying the changes.
39 -N, --reversedns
41 Translate IP addresses to names. Usually requires network traf‐
42 fic for DNS lookup.
43 -a, --handle
45 Show rule handles in output.
46 -e, --echo
48 When inserting items into the ruleset using add, insert or re‐
49 place commands, print notifications just like nft monitor.
50 -I, --includepath directory
52 Add the directory directory to the list of directories to be
53 searched for included files. This option may be specified multi‐
54 ple times.
55 -f, --file filename
57 Read input from filename.
58 -i, --interactive
60 Read input from an interactive readline CLI.
61
63 LEXICAL CONVENTIONS
64 Input is parsed line-wise. When the last character of a line, just be‐
65 fore the newline character, is a non-quoted backslash (\), the next
66 line is treated as a continuation. Multiple commands on the same line
67 can be separated using a semicolon (;).
68 A hash sign (#) begins a comment. All following characters on the same
70 line are ignored.
71 Identifiers begin with an alphabetic character (a-z,A-Z), followed zero
73 or more alphanumeric characters (a-z,A-Z,0-9) and the characters slash
74 (/), backslash (\), underscore (_) and dot (.). Identifiers using dif‐
75 ferent characters or clashing with a keyword need to be enclosed in
76 double quotes (").
77 INCLUDE FILES
79 include filename
80 Other files can be included by using the include statement. The direc‐
82 tories to be searched for include files can be specified using the
83 -I/--includepath option. You can override this behaviour either by
84 prepending ./ to your path to force inclusion of files located in the
85 current working directory (ie. relative path) or / for file location
86 expressed as an absolute path.
87 If -I/--includepath is not specified, then nft relies on the default
89 directory that is specified at compile time. You can retrieve this de‐
90 fault directory via -h/--help option.
91 Include statements support the usual shell wildcard symbols (*,?,[]).
93 Having no matches for an include statement is not an error, if wildcard
94 symbols are used in the include statement. This allows having poten‐
95 tially empty include directories for statements like include
96 "/etc/firewall/rules/*". The wildcard matches are loaded in alphabeti‐
97 cal order. Files beginning with dot (.) are not matched by include
98 statements.
99 SYMBOLIC VARIABLES
101 define variable expr
102 $variable
103 Symbolic variables can be defined using the define statement. Variable
105 references are expressions and can be used initialize other variables.
106 The scope of a definition is the current block and all blocks contained
107 within.
108 Using symbolic variables
110 define int_if1 = eth0
112 define int_if2 = eth1
113 define int_ifs = { $int_if1, $int_if2 }
114 filter input iif $int_ifs accept
116
119 Address families determine the type of packets which are processed. For
120 each address family the kernel contains so called hooks at specific
121 stages of the packet processing paths, which invoke nftables if rules
122 for these hooks exist.
123 ip IPv4 address family.
125 ip6 IPv6 address family.
127 inet Internet (IPv4/IPv6) address family.
129 arp ARP address family, handling IPv4 ARP packets.
131 bridge Bridge address family, handling packets which traverse a bridge
133 device.
134 netdev Netdev address family, handling packets from ingress.
136 All nftables objects exist in address family specific namespaces,
138 therefore all identifiers include an address family. If an identifier
139 is specified without an address family, the ip family is used by de‐
140 fault.
141 IPV4/IPV6/INET ADDRESS FAMILIES
143 The IPv4/IPv6/Inet address families handle IPv4, IPv6 or both types of
144 packets. They contain five hooks at different packet processing stages
145 in the network stack.
146 IPv4/IPv6/Inet address family hooks
148 ┌────────────┬────────────────────────────┐
150 │Hook │ Description │
151 ├────────────┼────────────────────────────┤
152 │prerouting │ All packets entering the │
153 │ │ system are processed by │
154 │ │ the prerouting hook. It is │
155 │ │ invoked before the routing │
156 │ │ process and is used for │
157 │ │ early filtering or chang‐ │
158 │ │ ing packet attributes that │
159 │ │ affect routing. │
160 ├────────────┼────────────────────────────┤
161 │input │ Packets delivered to the │
162 │ │ local system are processed │
163 │ │ by the input hook. │
164 ├────────────┼────────────────────────────┤
165 │forward │ Packets forwarded to a │
166 │ │ different host are pro‐ │
167 │ │ cessed by the forward │
168 │ │ hook. │
169 ├────────────┼────────────────────────────┤
170 │output │ Packets sent by local pro‐ │
171 │ │ cesses are processed by │
172 │ │ the output hook. │
173 ├────────────┼────────────────────────────┤
174 │postrouting │ All packets leaving the │
175 │ │ system are processed by │
176 │ │ the postrouting hook. │
177 └────────────┴────────────────────────────┘
178 ARP ADDRESS FAMILY
179 The ARP address family handles ARP packets received and sent by the
180 system. It is commonly used to mangle ARP packets for clustering.
181 ARP address family hooks
183 ┌───────┬────────────────────────────┐
185 │Hook │ Description │
186 ├───────┼────────────────────────────┤
187 │input │ Packets delivered to the │
188 │ │ local system are processed │
189 │ │ by the input hook. │
190 ├───────┼────────────────────────────┤
191 │output │ Packets send by the local │
192 │ │ system are processed by │
193 │ │ the output hook. │
194 └───────┴────────────────────────────┘
195 BRIDGE ADDRESS FAMILY
196 The bridge address family handles ethernet packets traversing bridge
197 devices.
198 The list of supported hooks is identical to IPv4/IPv6/Inet address fam‐
200 ilies above.
201 NETDEV ADDRESS FAMILY
203 The Netdev address family handles packets from ingress.
204 Netdev address family hooks
206 ┌────────┬────────────────────────────┐
208 │Hook │ Description │
209 ├────────┼────────────────────────────┤
210 │ingress │ All packets entering the │
211 │ │ system are processed by │
212 │ │ this hook. It is invoked │
213 │ │ before layer 3 protocol │
214 │ │ handlers and it can be │
215 │ │ used for early filtering │
216 │ │ and policing. │
217 └────────┴────────────────────────────┘
219 {list | flush} ruleset [family]
220 {export} [ruleset] {format}
221 The ruleset keyword is used to identify the whole set of tables,
223 chains, etc. currently in place in kernel. The following ruleset com‐
224 mands exist:
225 list Print the ruleset in human-readable format.
227 flush Clear the whole ruleset. Note that unlike iptables, this will
229 remove all tables and whatever they contain, effectively leading
230 to an empty ruleset - no packet filtering will happen anymore,
231 so the kernel accepts any valid packet it receives.
232 export Print the ruleset in machine readable format. The mandatory for‐
234 mat parameter may be either xml or json.
235 It is possible to limit list and flush to a specific address family on‐
237 ly. For a list of valid family names, see ADDRESS FAMILIES above.
238 Note that contrary to what one might assume, the output generated by
240 export is not parseable by nft -f. Instead, the output of list command
241 serves well for that purpose.
242
244 {add | delete | list | flush} table [family] {table}
245 Tables are containers for chains, sets and stateful objects. They are
247 identified by their address family and their name. The address family
248 must be one of ip, ip6, inet, arp, bridge, netdev. The inet address
249 family is a dummy family which is used to create hybrid IPv4/IPv6 ta‐
250 bles. The meta expression nfproto keyword can be used to test which
251 family (ipv4 or ipv6) context the packet is being processed in. When
252 no address family is specified, ip is used by default.
253 add Add a new table for the given family with the given name.
255 delete Delete the specified table.
257 list List all chains and rules of the specified table.
259 flush Flush all chains and rules of the specified table.
261
263 {add | create} chain [family] table chain [ { {type} {hook} [device]
264 {priority ;} [policy ;] } ]
265 {delete | list | flush} chain [family] {table} {chain}
266 {rename} chain [family] {table} {chain} {newname}
267 Chains are containers for rules. They exist in two kinds, base chains
269 and regular chains. A base chain is an entry point for packets from the
270 networking stack, a regular chain may be used as jump target and is
271 used for better rule organization.
272 add Add a new chain in the specified table. When a hook and priority
274 value are specified, the chain is created as a base chain and
275 hooked up to the networking stack.
276 create Similar to the add command, but returns an error if the chain
278 already exists.
279 delete Delete the specified chain. The chain must not contain any rules
281 or be used as jump target.
282 rename Rename the specified chain.
284 list List all rules of the specified chain.
286 flush Flush all rules of the specified chain.
288 For base chains, type, hook and priority parameters are mandatory.
290 Supported chain types
292 ┌───────┬──────────┬──────────────────┬──────────────────┐
294 │Type │ Families │ Hooks │ Description │
295 ├───────┼──────────┼──────────────────┼──────────────────┤
296 │filter │ all │ all │ Standard chain │
297 │ │ │ │ type to use in │
298 │ │ │ │ doubt. │
299 ├───────┼──────────┼──────────────────┼──────────────────┤
300 │nat │ ip, ip6 │ prerouting, in‐ │ Chains of this │
301 │ │ │ put, output, │ type perform Na‐ │
302 │ │ │ postrouting │ tive Address │
303 │ │ │ │ Translation │
304 │ │ │ │ based on con‐ │
305 │ │ │ │ ntrack entries. │
306 │ │ │ │ Only the first │
307 │ │ │ │ packet of a con‐ │
308 │ │ │ │ nection actually │
309 │ │ │ │ traverses this │
310 │ │ │ │ chain - its │
311 │ │ │ │ rules usually │
312 │ │ │ │ define details │
313 │ │ │ │ of the created │
314 │ │ │ │ conntrack entry │
315 │ │ │ │ (NAT statements │
316 │ │ │ │ for instance). │
317 ├───────┼──────────┼──────────────────┼──────────────────┤
318 │route │ ip, ip6 │ output │ If a packet has │
319 │ │ │ │ traversed a │
320 │ │ │ │ chain of this │
321 │ │ │ │ type and is │
322 │ │ │ │ about to be ac‐ │
323 │ │ │ │ cepted, a new │
324 │ │ │ │ route lookup is │
325 │ │ │ │ performed if │
326 │ │ │ │ relevant parts │
327 │ │ │ │ of the IP header │
328 │ │ │ │ have changed. │
329 │ │ │ │ This allows to │
330 │ │ │ │ e.g. implement │
331 │ │ │ │ policy routing │
332 │ │ │ │ selectors in │
333 │ │ │ │ nftables. │
334 └───────┴──────────┴──────────────────┴──────────────────┘
335 Apart from the special cases illustrated above (e.g. nat type not sup‐
336 porting forward hook or route type only supporting output hook), there
337 are two further quirks worth noticing:
338 · netdev family supports merely a single combination, namely filter
340 type and ingress hook. Base chains in this family also require the
341 device parameter to be present since they exist per incoming inter‐
342 face only.
343 · arp family supports only input and output hooks, both in chains of
345 type filter.
346 The priority parameter accepts a signed integer value which specifies
348 the order in which chains with same hook value are traversed. The or‐
349 dering is ascending, i.e. lower priority values have precedence over
350 higher ones.
351 Base chains also allow to set the chain's policy, i.e. what happens to
353 packets not explicitly accepted or refused in contained rules. Support‐
354 ed policy values are accept (which is the default) or drop.
355
357 [add | insert] rule [family] {table} {chain} [ {handle | position}
358 handle ] {statement}...
359 {replace} rule [family] {table} {chain} {handle handle} {statement}...
360 {delete} rule [family] {table} {chain} {handle handle}
361 Rules are constructed from two kinds of components according to a set
363 of grammatical rules: expressions and statements.
364 add Add a new rule described by the list of statements. The rule is
366 appended to the given chain unless a handle is specified, in
367 which case the rule is appended to the rule given by the handle.
368 The alternative name position is deprecated and should not be
369 used anymore.
370 insert Similar to the add command, but the rule is prepended to the be‐
372 ginning of the chain or before the rule with the given handle.
373 replace
375 Similar to the add command, but the rule replaces the specified
376 rule.
377 delete Delete the specified rule.
379
381 {add} set [family] {table} {set} { {type} [flags] [timeout] [gc-
382 interval] [elements] [size] [policy] }
383 {delete | list | flush} set [family] {table} {set}
384 {add | delete} element [family] {table} {set} { {elements} }
385 Sets are elements containers of an user-defined data type, they are
387 uniquely identified by an user-defined name and attached to tables.
388 add Add a new set in the specified table.
390 delete Delete the specified set.
392 list Display the elements in the specified set.
394 flush Remove all elements from the specified set.
396 add element
398 Comma-separated list of elements to add into the specified set.
399 delete element
401 Comma-separated list of elements to delete from the specified
402 set.
403 Set specifications
405 ┌────────────┬─────────────────────┬─────────────────────┐
407 │Keyword │ Description │ Type │
408 ├────────────┼─────────────────────┼─────────────────────┤
409 │type │ data type of set │ string: ipv4_addr, │
410 │ │ elements │ ipv6_addr, │
411 │ │ │ ether_addr, in‐ │
412 │ │ │ et_proto, inet_ser‐ │
413 │ │ │ vice, mark │
414 ├────────────┼─────────────────────┼─────────────────────┤
415 │flags │ set flags │ string: constant, │
416 │ │ │ interval, timeout │
417 ├────────────┼─────────────────────┼─────────────────────┤
418 │timeout │ time an element │ string, decimal │
419 │ │ stays in the set │ followed by unit. │
420 │ │ │ Units are: d, h, m, │
421 │ │ │ s │
422 ├────────────┼─────────────────────┼─────────────────────┤
423 │gc-interval │ garbage collection │ string, decimal │
424 │ │ interval, only │ followed by unit. │
425 │ │ available when │ Units are: d, h, m, │
426 │ │ timeout or flag │ s │
427 │ │ timeout are active │ │
428 ├────────────┼─────────────────────┼─────────────────────┤
429 │elements │ elements contained │ set data type │
430 │ │ by the set │ │
431 ├────────────┼─────────────────────┼─────────────────────┤
432 │size │ maximun number of │ unsigned integer │
433 │ │ elements in the set │ (64 bit) │
434 ├────────────┼─────────────────────┼─────────────────────┤
435 │policy │ set policy │ string: performance │
436 │ │ │ [default], memory │
437 └────────────┴─────────────────────┴─────────────────────┘
439 {add} map [family] {table} {map} { {type} [flags] [elements] [size]
440 [policy] }
441 {delete | list | flush} map [family] {table} {map}
442 {add | delete} element [family] {table} {map} { {elements} }
443 Maps store data based on some specific key used as input, they are
445 uniquely identified by an user-defined name and attached to tables.
446 add Add a new map in the specified table.
448 delete Delete the specified map.
450 list Display the elements in the specified map.
452 flush Remove all elements from the specified map.
454 add element
456 Comma-separated list of elements to add into the specified map.
457 delete element
459 Comma-separated list of element keys to delete from the speci‐
460 fied map.
461 Map specifications
463 ┌─────────┬─────────────────────┬─────────────────────┐
465 │Keyword │ Description │ Type │
466 ├─────────┼─────────────────────┼─────────────────────┤
467 │type │ data type of map │ string ':' string: │
468 │ │ elements │ ipv4_addr, ipv6_ad‐ │
469 │ │ │ dr, ether_addr, in‐ │
470 │ │ │ et_proto, inet_ser‐ │
471 │ │ │ vice, mark, │
472 │ │ │ counter, quota. │
473 │ │ │ Counter and quota │
474 │ │ │ can't be used as │
475 │ │ │ keys │
476 ├─────────┼─────────────────────┼─────────────────────┤
477 │flags │ map flags │ string: constant, │
478 │ │ │ interval │
479 ├─────────┼─────────────────────┼─────────────────────┤
480 │elements │ elements contained │ map data type │
481 │ │ by the map │ │
482 ├─────────┼─────────────────────┼─────────────────────┤
483 │size │ maximun number of │ unsigned integer │
484 │ │ elements in the map │ (64 bit) │
485 ├─────────┼─────────────────────┼─────────────────────┤
486 │policy │ map policy │ string: performance │
487 │ │ │ [default], memory │
488 └─────────┴─────────────────────┴─────────────────────┘
490 {add | delete | list | reset} type [family] {table} {object}
491 Stateful objects are attached to tables and are identified by an unique
493 name. They group stateful information from rules, to reference them in
494 rules the keywords "type name" are used e.g. "counter name".
495 add Add a new stateful object in the specified table.
497 delete Delete the specified object.
499 list Display stateful information the object holds.
501 reset List-and-reset stateful object.
503 CT
505 ct {helper} {type} {type} {protocol} {protocol} [l3proto] [family]
506 Ct helper is used to define connection tracking helpers that can then
508 be used in combination with the "ct helper set" statement. type and
509 protocol are mandatory, l3proto is derived from the table family by de‐
510 fault, i.e. in the inet table the kernel will try to load both the ipv4
511 and ipv6 helper backends, if they are supported by the kernel.
512 conntrack helper specifications
514 ┌─────────┬─────────────────────┬─────────────────────┐
516 │Keyword │ Description │ Type │
517 ├─────────┼─────────────────────┼─────────────────────┤
518 │type │ name of helper type │ quoted string (e.g. │
519 │ │ │ "ftp") │
520 ├─────────┼─────────────────────┼─────────────────────┤
521 │protocol │ layer 4 protocol of │ string (e.g. tcp) │
522 │ │ the helper │ │
523 ├─────────┼─────────────────────┼─────────────────────┤
524 │l3proto │ layer 3 protocol of │ address family │
525 │ │ the helper │ (e.g. ip) │
526 └─────────┴─────────────────────┴─────────────────────┘
527 defining and assigning ftp helper
528 Unlike iptables, helper assignment needs to be performed after the con‐
530 ntrack lookup has completed, for example with the default 0 hook prior‐
531 ity.
532 table inet myhelpers {
534 ct helper ftp-standard {
535 type "ftp" protocol tcp
536 }
537 chain prerouting {
538 type filter hook prerouting priority 0;
539 tcp dport 21 ct helper set "ftp-standard"
540 }
541 }
542 COUNTER
545 counter [packets bytes]
546 Counter specifications
548 ┌────────┬─────────────────────┬─────────────────────┐
550 │Keyword │ Description │ Type │
551 ├────────┼─────────────────────┼─────────────────────┤
552 │packets │ initial count of │ unsigned integer │
553 │ │ packets │ (64 bit) │
554 ├────────┼─────────────────────┼─────────────────────┤
555 │bytes │ initial count of │ unsigned integer │
556 │ │ bytes │ (64 bit) │
557 └────────┴─────────────────────┴─────────────────────┘
558 QUOTA
559 quota [over | until] [used]
560 Quota specifications
562 ┌────────┬─────────────────────┬─────────────────────┐
564 │Keyword │ Description │ Type │
565 ├────────┼─────────────────────┼─────────────────────┤
566 │quota │ quota limit, used │ Two arguments, un‐ │
567 │ │ as the quota name │ signed interger (64 │
568 │ │ │ bit) and string: │
569 │ │ │ bytes, kbytes, │
570 │ │ │ mbytes. "over" and │
571 │ │ │ "until" go before │
572 │ │ │ these arguments │
573 ├────────┼─────────────────────┼─────────────────────┤
574 │used │ initial value of │ Two arguments, un‐ │
575 │ │ used quota │ signed interger (64 │
576 │ │ │ bit) and string: │
577 │ │ │ bytes, kbytes, │
578 │ │ │ mbytes │
579 └────────┴─────────────────────┴─────────────────────┘
581 Expressions represent values, either constants like network addresses,
582 port numbers etc. or data gathered from the packet during ruleset eval‐
583 uation. Expressions can be combined using binary, logical, relational
584 and other types of expressions to form complex or relational (match)
585 expressions. They are also used as arguments to certain types of oper‐
586 ations, like NAT, packet marking etc.
587 Each expression has a data type, which determines the size, parsing and
589 representation of symbolic values and type compatibility with other ex‐
590 pressions.
591 DESCRIBE COMMAND
593 describe {expression}
594 The describe command shows information about the type of an expression
596 and its data type.
597 The describe command
599 $ nft describe tcp flags
601 payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits
602 pre-defined symbolic constants:
604 fin 0x01
605 syn 0x02
606 rst 0x04
607 psh 0x08
608 ack 0x10
609 urg 0x20
610 ecn 0x40
611 cwr 0x80
612
615 Data types determine the size, parsing and representation of symbolic
616 values and type compatibility of expressions. A number of global data
617 types exist, in addition some expression types define further data
618 types specific to the expression type. Most data types have a fixed
619 size, some however may have a dynamic size, f.i. the string type.
620 Types may be derived from lower order types, f.i. the IPv4 address type
622 is derived from the integer type, meaning an IPv4 address can also be
623 specified as an integer value.
624 In certain contexts (set and map definitions) it is necessary to ex‐
626 plicitly specify a data type. Each type has a name which is used for
627 this.
628 INTEGER TYPE
630 ┌────────┬─────────┬──────────┬───────────┐
631 │Name │ Keyword │ Size │ Base type │
632 ├────────┼─────────┼──────────┼───────────┤
633 │Integer │ integer │ variable │ - │
634 └────────┴─────────┴──────────┴───────────┘
635 The integer type is used for numeric values. It may be specified as
636 decimal, hexadecimal or octal number. The integer type doesn't have a
637 fixed size, its size is determined by the expression for which it is
638 used.
639 BITMASK TYPE
641 ┌────────┬─────────┬──────────┬───────────┐
642 │Name │ Keyword │ Size │ Base type │
643 ├────────┼─────────┼──────────┼───────────┤
644 │Bitmask │ bitmask │ variable │ integer │
645 └────────┴─────────┴──────────┴───────────┘
646 The bitmask type (bitmask) is used for bitmasks.
647 STRING TYPE
649 ┌───────┬─────────┬──────────┬───────────┐
650 │Name │ Keyword │ Size │ Base type │
651 ├───────┼─────────┼──────────┼───────────┤
652 │String │ string │ variable │ - │
653 └───────┴─────────┴──────────┴───────────┘
654 The string type is used to for character strings. A string begins with
655 an alphabetic character (a-zA-Z) followed by zero or more alphanumeric
656 characters or the characters /, -, _ and .. In addition anything en‐
657 closed in double quotes (") is recognized as a string.
658 String specification
660 # Interface name
662 filter input iifname eth0
663 # Weird interface name
665 filter input iifname "(eth0)"
666 LINK LAYER ADDRESS TYPE
669 ┌─────────────────┬─────────┬──────────┬───────────┐
670 │Name │ Keyword │ Size │ Base type │
671 ├─────────────────┼─────────┼──────────┼───────────┤
672 │Link layer ad‐ │ lladdr │ variable │ integer │
673 │dress │ │ │ │
674 └─────────────────┴─────────┴──────────┴───────────┘
675 The link layer address type is used for link layer addresses. Link lay‐
676 er addresses are specified as a variable amount of groups of two hexa‐
677 decimal digits separated using colons (:).
678 Link layer address specification
680 # Ethernet destination MAC address
682 filter input ether daddr 20:c9:d0:43:12:d9
683 IPV4 ADDRESS TYPE
686 ┌─────────────┬───────────┬────────┬───────────┐
687 │Name │ Keyword │ Size │ Base type │
688 ├─────────────┼───────────┼────────┼───────────┤
689 │IPv4 address │ ipv4_addr │ 32 bit │ integer │
690 └─────────────┴───────────┴────────┴───────────┘
691 The IPv4 address type is used for IPv4 addresses. Addresses are speci‐
692 fied in either dotted decimal, dotted hexadecimal, dotted octal, deci‐
693 mal, hexadecimal, octal notation or as a host name. A host name will be
694 resolved using the standard system resolver.
695 IPv4 address specification
697 # dotted decimal notation
699 filter output ip daddr 127.0.0.1
700 # host name
702 filter output ip daddr localhost
703 IPV6 ADDRESS TYPE
706 ┌─────────────┬───────────┬─────────┬───────────┐
707 │Name │ Keyword │ Size │ Base type │
708 ├─────────────┼───────────┼─────────┼───────────┤
709 │IPv6 address │ ipv6_addr │ 128 bit │ integer │
710 └─────────────┴───────────┴─────────┴───────────┘
711 The IPv6 address type is used for IPv6 addresses. FIXME
712 IPv6 address specification
714 # abbreviated loopback address
716 filter output ip6 daddr ::1
717 BOOLEAN TYPE
720 ┌────────┬─────────┬───────┬───────────┐
721 │Name │ Keyword │ Size │ Base type │
722 ├────────┼─────────┼───────┼───────────┤
723 │Boolean │ boolean │ 1 bit │ integer │
724 └────────┴─────────┴───────┴───────────┘
725 The boolean type is a syntactical helper type in user space. It's use
726 is in the right-hand side of a (typically implicit) relational expres‐
727 sion to change the expression on the left-hand side into a boolean
728 check (usually for existence).
729 The following keywords will automatically resolve into a boolean type
731 with given value:
732 ┌────────┬───────┐
734 │Keyword │ Value │
735 ├────────┼───────┤
736 │exists │ 1 │
737 ├────────┼───────┤
738 │missing │ 0 │
739 └────────┴───────┘
740 Boolean specification
741 The following expressions support a boolean comparison:
743 ┌───────────┬────────────────────────────┐
745 │Expression │ Behaviour │
746 ├───────────┼────────────────────────────┤
747 │fib │ Check route existence. │
748 ├───────────┼────────────────────────────┤
749 │exthdr │ Check IPv6 extension head‐ │
750 │ │ er existence. │
751 ├───────────┼────────────────────────────┤
752 │tcp option │ Check TCP option header │
753 │ │ existence. │
754 └───────────┴────────────────────────────┘
755 # match if route exists
756 filter input fib daddr . iif oif exists
757 # match only non-fragmented packets in IPv6 traffic
759 filter input exthdr frag missing
760 # match if TCP timestamp option is present
762 filter input tcp option timestamp exists
763 ICMP TYPE TYPE
766 ┌──────────┬───────────┬───────┬───────────┐
767 │Name │ Keyword │ Size │ Base type │
768 ├──────────┼───────────┼───────┼───────────┤
769 │ICMP Type │ icmp_type │ 8 bit │ integer │
770 └──────────┴───────────┴───────┴───────────┘
771 The ICMP Type type is used to conveniently specify the ICMP header's
772 type field.
773 The following keywords may be used when specifying the ICMP type:
775 ┌────────────────────────┬───────┐
777 │Keyword │ Value │
778 ├────────────────────────┼───────┤
779 │echo-reply │ 0 │
780 ├────────────────────────┼───────┤
781 │destination-unreachable │ 3 │
782 ├────────────────────────┼───────┤
783 │source-quench │ 4 │
784 ├────────────────────────┼───────┤
785 │redirect │ 5 │
786 ├────────────────────────┼───────┤
787 │echo-request │ 8 │
788 ├────────────────────────┼───────┤
789 │router-advertisement │ 9 │
790 ├────────────────────────┼───────┤
791 │router-solicitation │ 10 │
792 ├────────────────────────┼───────┤
793 │time-exceeded │ 11 │
794 ├────────────────────────┼───────┤
795 │parameter-problem │ 12 │
796 ├────────────────────────┼───────┤
797 │timestamp-request │ 13 │
798 ├────────────────────────┼───────┤
799 │timestamp-reply │ 14 │
800 ├────────────────────────┼───────┤
801 │info-request │ 15 │
802 ├────────────────────────┼───────┤
803 │info-reply │ 16 │
804 ├────────────────────────┼───────┤
805 │address-mask-request │ 17 │
806 ├────────────────────────┼───────┤
807 │address-mask-reply │ 18 │
808 └────────────────────────┴───────┘
809 ICMP Type specification
810 # match ping packets
812 filter output icmp type { echo-request, echo-reply }
813 ICMP CODE TYPE
816 ┌──────────┬───────────┬───────┬───────────┐
817 │Name │ Keyword │ Size │ Base type │
818 ├──────────┼───────────┼───────┼───────────┤
819 │ICMP Code │ icmp_code │ 8 bit │ integer │
820 └──────────┴───────────┴───────┴───────────┘
821 The ICMP Code type is used to conveniently specify the ICMP header's
822 code field.
823 The following keywords may be used when specifying the ICMP code:
825 ┌─────────────────┬───────┐
827 │Keyword │ Value │
828 ├─────────────────┼───────┤
829 │net-unreachable │ 0 │
830 ├─────────────────┼───────┤
831 │host-unreachable │ 1 │
832 ├─────────────────┼───────┤
833 │prot-unreachable │ 2 │
834 ├─────────────────┼───────┤
835 │port-unreachable │ 3 │
836 ├─────────────────┼───────┤
837 │net-prohibited │ 9 │
838 ├─────────────────┼───────┤
839 │host-prohibited │ 10 │
840 ├─────────────────┼───────┤
841 │admin-prohibited │ 13 │
842 └─────────────────┴───────┘
843 ICMPV6 TYPE TYPE
844 ┌────────────┬─────────────┬───────┬───────────┐
845 │Name │ Keyword │ Size │ Base type │
846 ├────────────┼─────────────┼───────┼───────────┤
847 │ICMPv6 Type │ icmpv6_type │ 8 bit │ integer │
848 └────────────┴─────────────┴───────┴───────────┘
849 The ICMPv6 Type type is used to conveniently specify the ICMPv6 head‐
850 er's type field.
851 The following keywords may be used when specifying the ICMPv6 type:
853 ┌────────────────────────┬───────┐
855 │Keyword │ Value │
856 ├────────────────────────┼───────┤
857 │destination-unreachable │ 1 │
858 ├────────────────────────┼───────┤
859 │packet-too-big │ 2 │
860 ├────────────────────────┼───────┤
861 │time-exceeded │ 3 │
862 ├────────────────────────┼───────┤
863 │parameter-problem │ 4 │
864 ├────────────────────────┼───────┤
865 │echo-request │ 128 │
866 ├────────────────────────┼───────┤
867 │echo-reply │ 129 │
868 ├────────────────────────┼───────┤
869 │mld-listener-query │ 130 │
870 ├────────────────────────┼───────┤
871 │mld-listener-report │ 131 │
872 ├────────────────────────┼───────┤
873 │mld-listener-done │ 132 │
874 ├────────────────────────┼───────┤
875 │mld-listener-reduction │ 132 │
876 ├────────────────────────┼───────┤
877 │nd-router-solicit │ 133 │
878 ├────────────────────────┼───────┤
879 │nd-router-advert │ 134 │
880 ├────────────────────────┼───────┤
881 │nd-neighbor-solicit │ 135 │
882 ├────────────────────────┼───────┤
883 │nd-neighbor-advert │ 136 │
884 ├────────────────────────┼───────┤
885 │nd-redirect │ 137 │
886 ├────────────────────────┼───────┤
887 │router-renumbering │ 138 │
888 ├────────────────────────┼───────┤
889 │ind-neighbor-solicit │ 141 │
890 ├────────────────────────┼───────┤
891 │ind-neighbor-advert │ 142 │
892 ├────────────────────────┼───────┤
893 │mld2-listener-report │ 143 │
894 └────────────────────────┴───────┘
895 ICMPv6 Type specification
896 # match ICMPv6 ping packets
898 filter output icmpv6 type { echo-request, echo-reply }
899 ICMPV6 CODE TYPE
902 ┌────────────┬─────────────┬───────┬───────────┐
903 │Name │ Keyword │ Size │ Base type │
904 ├────────────┼─────────────┼───────┼───────────┤
905 │ICMPv6 Code │ icmpv6_code │ 8 bit │ integer │
906 └────────────┴─────────────┴───────┴───────────┘
907 The ICMPv6 Code type is used to conveniently specify the ICMPv6 head‐
908 er's code field.
909 The following keywords may be used when specifying the ICMPv6 code:
911 ┌─────────────────┬───────┐
913 │Keyword │ Value │
914 ├─────────────────┼───────┤
915 │no-route │ 0 │
916 ├─────────────────┼───────┤
917 │admin-prohibited │ 1 │
918 ├─────────────────┼───────┤
919 │addr-unreachable │ 3 │
920 ├─────────────────┼───────┤
921 │port-unreachable │ 4 │
922 ├─────────────────┼───────┤
923 │policy-fail │ 5 │
924 ├─────────────────┼───────┤
925 │reject-route │ 6 │
926 └─────────────────┴───────┘
927 ICMPVX CODE TYPE
928 ┌────────────┬────────────┬───────┬───────────┐
929 │Name │ Keyword │ Size │ Base type │
930 ├────────────┼────────────┼───────┼───────────┤
931 │ICMPvX Code │ icmpx_code │ 8 bit │ integer │
932 └────────────┴────────────┴───────┴───────────┘
933 The ICMPvX Code type abstraction is a set of values which overlap be‐
934 tween ICMP and ICMPv6 Code types to be used from the inet family.
935 The following keywords may be used when specifying the ICMPvX code:
937 ┌─────────────────┬───────┐
939 │Keyword │ Value │
940 ├─────────────────┼───────┤
941 │no-route │ 0 │
942 ├─────────────────┼───────┤
943 │port-unreachable │ 1 │
944 ├─────────────────┼───────┤
945 │host-unreachable │ 2 │
946 ├─────────────────┼───────┤
947 │admin-prohibited │ 3 │
948 └─────────────────┴───────┘
949 CONNTRACK TYPES
950 This is an overview of types used in ct expression and statement:
951 ┌─────────────────┬───────────┬─────────┬───────────┐
953 │Name │ Keyword │ Size │ Base type │
954 ├─────────────────┼───────────┼─────────┼───────────┤
955 │conntrack state │ ct_state │ 4 byte │ bitmask │
956 ├─────────────────┼───────────┼─────────┼───────────┤
957 │conntrack direc‐ │ ct_dir │ 8 bit │ integer │
958 │tion │ │ │ │
959 ├─────────────────┼───────────┼─────────┼───────────┤
960 │conntrack status │ ct_status │ 4 byte │ bitmask │
961 ├─────────────────┼───────────┼─────────┼───────────┤
962 │conntrack event │ ct_event │ 4 byte │ bitmask │
963 │bits │ │ │ │
964 ├─────────────────┼───────────┼─────────┼───────────┤
965 │conntrack label │ ct_label │ 128 bit │ bitmask │
966 └─────────────────┴───────────┴─────────┴───────────┘
967 For each of the types above, keywords are available for convenience:
968 conntrack state (ct_state)
970 ┌────────────┬───────┐
972 │Keyword │ Value │
973 ├────────────┼───────┤
974 │invalid │ 1 │
975 ├────────────┼───────┤
976 │established │ 2 │
977 ├────────────┼───────┤
978 │related │ 4 │
979 ├────────────┼───────┤
980 │new │ 8 │
981 ├────────────┼───────┤
982 │untracked │ 64 │
983 └────────────┴───────┘
984 conntrack direction (ct_dir)
985 ┌─────────┬───────┐
987 │Keyword │ Value │
988 ├─────────┼───────┤
989 │original │ 0 │
990 ├─────────┼───────┤
991 │reply │ 1 │
992 └─────────┴───────┘
993 conntrack status (ct_status)
994 ┌───────────┬───────┐
996 │Keyword │ Value │
997 ├───────────┼───────┤
998 │expected │ 1 │
999 ├───────────┼───────┤
1000 │seen-reply │ 2 │
1001 ├───────────┼───────┤
1002 │assured │ 4 │
1003 ├───────────┼───────┤
1004 │confirmed │ 8 │
1005 ├───────────┼───────┤
1006 │snat │ 16 │
1007 ├───────────┼───────┤
1008 │dnat │ 32 │
1009 ├───────────┼───────┤
1010 │dying │ 512 │
1011 └───────────┴───────┘
1012 conntrack event bits (ct_event)
1013 ┌──────────┬───────┐
1015 │Keyword │ Value │
1016 ├──────────┼───────┤
1017 │new │ 1 │
1018 ├──────────┼───────┤
1019 │related │ 2 │
1020 ├──────────┼───────┤
1021 │destroy │ 4 │
1022 ├──────────┼───────┤
1023 │reply │ 8 │
1024 ├──────────┼───────┤
1025 │assured │ 16 │
1026 ├──────────┼───────┤
1027 │protoinfo │ 32 │
1028 ├──────────┼───────┤
1029 │helper │ 64 │
1030 ├──────────┼───────┤
1031 │mark │ 128 │
1032 ├──────────┼───────┤
1033 │seqadj │ 256 │
1034 ├──────────┼───────┤
1035 │secmark │ 512 │
1036 ├──────────┼───────┤
1037 │label │ 1024 │
1038 └──────────┴───────┘
1039 Possible keywords for conntrack label type (ct_label) are read at run‐
1040 time from /etc/connlabel.conf.
1041
1043 The lowest order expression is a primary expression, representing ei‐
1044 ther a constant or a single datum from a packet's payload, meta data or
1045 a stateful module.
1046 META EXPRESSIONS
1048 meta {length | nfproto | l4proto | protocol | priority}
1049 [meta] {mark | iif | iifname | iiftype | oif | oifname | oiftype |
1050 skuid | skgid | nftrace | rtclassid | ibriport | obriport | pkttype |
1051 cpu | iifgroup | oifgroup | cgroup | random}
1052 A meta expression refers to meta data associated with a packet.
1054 There are two types of meta expressions: unqualified and qualified meta
1056 expressions. Qualified meta expressions require the meta keyword be‐
1057 fore the meta key, unqualified meta expressions can be specified by us‐
1058 ing the meta key directly or as qualified meta expressions.
1059 Meta expression types
1061 ┌──────────┬─────────────────────┬───────────────────┐
1063 │Keyword │ Description │ Type │
1064 ├──────────┼─────────────────────┼───────────────────┤
1065 │length │ Length of the pack‐ │ integer (32 bit) │
1066 │ │ et in bytes │ │
1067 ├──────────┼─────────────────────┼───────────────────┤
1068 │nfproto │ real hook protocol │ integer (32 bit) │
1069 │ │ family, useful only │ │
1070 │ │ in inet table │ │
1071 ├──────────┼─────────────────────┼───────────────────┤
1072 │protocol │ Ethertype protocol │ ether_type │
1073 │ │ value │ │
1074 ├──────────┼─────────────────────┼───────────────────┤
1075 │priority │ TC packet priority │ tc_handle │
1076 ├──────────┼─────────────────────┼───────────────────┤
1077 │mark │ Packet mark │ mark │
1078 ├──────────┼─────────────────────┼───────────────────┤
1079 │iif │ Input interface in‐ │ iface_index │
1080 │ │ dex │ │
1081 ├──────────┼─────────────────────┼───────────────────┤
1082 │iifname │ Input interface │ string │
1083 │ │ name │ │
1084 ├──────────┼─────────────────────┼───────────────────┤
1085 │iiftype │ Input interface │ iface_type │
1086 │ │ type │ │
1087 ├──────────┼─────────────────────┼───────────────────┤
1088 │oif │ Output interface │ iface_index │
1089 │ │ index │ │
1090 ├──────────┼─────────────────────┼───────────────────┤
1091 │oifname │ Output interface │ string │
1092 │ │ name │ │
1093 ├──────────┼─────────────────────┼───────────────────┤
1094 │oiftype │ Output interface │ iface_type │
1095 │ │ hardware type │ │
1096 ├──────────┼─────────────────────┼───────────────────┤
1097 │skuid │ UID associated with │ uid │
1098 │ │ originating socket │ │
1099 ├──────────┼─────────────────────┼───────────────────┤
1100 │skgid │ GID associated with │ gid │
1101 │ │ originating socket │ │
1102 ├──────────┼─────────────────────┼───────────────────┤
1103 │rtclassid │ Routing realm │ realm │
1104 ├──────────┼─────────────────────┼───────────────────┤
1105 │ibriport │ Input bridge inter‐ │ string │
1106 │ │ face name │ │
1107 ├──────────┼─────────────────────┼───────────────────┤
1108 │obriport │ Output bridge in‐ │ string │
1109 │ │ terface name │ │
1110 ├──────────┼─────────────────────┼───────────────────┤
1111 │pkttype │ packet type │ pkt_type │
1112 ├──────────┼─────────────────────┼───────────────────┤
1113 │cpu │ cpu number process‐ │ integer (32 bits) │
1114 │ │ ing the packet │ │
1115 ├──────────┼─────────────────────┼───────────────────┤
1116 │iifgroup │ incoming device │ devgroup │
1117 │ │ group │ │
1118 ├──────────┼─────────────────────┼───────────────────┤
1119 │oifgroup │ outgoing device │ devgroup │
1120 │ │ group │ │
1121 ├──────────┼─────────────────────┼───────────────────┤
1122 │cgroup │ control group id │ integer (32 bits) │
1123 ├──────────┼─────────────────────┼───────────────────┤
1124 │random │ pseudo-random num‐ │ integer (32 bits) │
1125 │ │ ber │ │
1126 └──────────┴─────────────────────┴───────────────────┘
1127 Meta expression specific types
1128 ┌──────────────┬────────────────────────────┐
1130 │Type │ Description │
1131 ├──────────────┼────────────────────────────┤
1132 │iface_index │ Interface index (32 bit │
1133 │ │ number). Can be specified │
1134 │ │ numerically or as name of │
1135 │ │ an existing interface. │
1136 ├──────────────┼────────────────────────────┤
1137 │ifname │ Interface name (16 byte │
1138 │ │ string). Does not have to │
1139 │ │ exist. │
1140 ├──────────────┼────────────────────────────┤
1141 │iface_type │ Interface type (16 bit │
1142 │ │ number). │
1143 ├──────────────┼────────────────────────────┤
1144 │uid │ User ID (32 bit number). │
1145 │ │ Can be specified numeri‐ │
1146 │ │ cally or as user name. │
1147 ├──────────────┼────────────────────────────┤
1148 │gid │ Group ID (32 bit number). │
1149 │ │ Can be specified numeri‐ │
1150 │ │ cally or as group name. │
1151 ├──────────────┼────────────────────────────┤
1152 │realm │ Routing Realm (32 bit num‐ │
1153 │ │ ber). Can be specified nu‐ │
1154 │ │ merically or as symbolic │
1155 │ │ name defined in │
1156 │ │ /etc/iproute2/rt_realms. │
1157 ├──────────────┼────────────────────────────┤
1158 │devgroup_type │ Device group (32 bit num‐ │
1159 │ │ ber). Can be specified nu‐ │
1160 │ │ merically or as symbolic │
1161 │ │ name defined in │
1162 │ │ /etc/iproute2/group. │
1163 ├──────────────┼────────────────────────────┤
1164 │pkt_type │ Packet type: Unicast (ad‐ │
1165 │ │ dressed to local host), │
1166 │ │ Broadcast (to all), Multi‐ │
1167 │ │ cast (to group). │
1168 └──────────────┴────────────────────────────┘
1169 Using meta expressions
1170 # qualified meta expression
1172 filter output meta oif eth0
1173 # unqualified meta expression
1175 filter output oif eth0
1176 FIB EXPRESSIONS
1179 fib {saddr | daddr | [mark | iif | oif]} {oif | oifname | type}
1180 A fib expression queries the fib (forwarding information base) to ob‐
1182 tain information such as the output interface index a particular ad‐
1183 dress would use. The input is a tuple of elements that is used as input
1184 to the fib lookup functions.
1185 fib expression specific types
1187 ┌────────┬─────────────────────┬──────────────────┐
1189 │Keyword │ Description │ Type │
1190 ├────────┼─────────────────────┼──────────────────┤
1191 │oif │ Output interface │ integer (32 bit) │
1192 │ │ index │ │
1193 ├────────┼─────────────────────┼──────────────────┤
1194 │oifname │ Output interface │ string │
1195 │ │ name │ │
1196 ├────────┼─────────────────────┼──────────────────┤
1197 │type │ Address type │ fib_addrtype │
1198 └────────┴─────────────────────┴──────────────────┘
1199 Using fib expressions
1200 # drop packets without a reverse path
1202 filter prerouting fib saddr . iif oif missing drop
1203 # drop packets to address not configured on ininterface
1205 filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
1206 # perform lookup in a specific 'blackhole' table (0xdead, needs ip appropriate ip rule)
1208 filter prerouting meta mark set 0xdead fib daddr . mark type vmap { blackhole : drop, prohibit : jump prohibited, unreachable : drop }
1209 ROUTING EXPRESSIONS
1212 rt {classid | nexthop}
1213 A routing expression refers to routing data associated with a packet.
1215 Routing expression types
1217 ┌────────┬─────────────────────┬─────────────────────┐
1219 │Keyword │ Description │ Type │
1220 ├────────┼─────────────────────┼─────────────────────┤
1221 │classid │ Routing realm │ realm │
1222 ├────────┼─────────────────────┼─────────────────────┤
1223 │nexthop │ Routing nexthop │ ipv4_addr/ipv6_addr │
1224 ├────────┼─────────────────────┼─────────────────────┤
1225 │mtu │ TCP maximum segment │ integer (16 bit) │
1226 │ │ size of route │ │
1227 └────────┴─────────────────────┴─────────────────────┘
1228 Routing expression specific types
1229 ┌──────┬────────────────────────────┐
1231 │Type │ Description │
1232 ├──────┼────────────────────────────┤
1233 │realm │ Routing Realm (32 bit num‐ │
1234 │ │ ber). Can be specified nu‐ │
1235 │ │ merically or as symbolic │
1236 │ │ name defined in │
1237 │ │ /etc/iproute2/rt_realms. │
1238 └──────┴────────────────────────────┘
1239 Using routing expressions
1240 # IP family independent rt expression
1242 filter output rt classid 10
1243 # IP family dependent rt expressions
1245 ip filter output rt nexthop 192.168.0.1
1246 ip6 filter output rt nexthop fd00::1
1247 inet filter output rt ip nexthop 192.168.0.1
1248 inet filter output rt ip6 nexthop fd00::1
1249
1252 Payload expressions refer to data from the packet's payload.
1253 ETHERNET HEADER EXPRESSION
1255 ether [ethernet header field]
1256 Ethernet header expression types
1258 ┌────────┬─────────────────────┬────────────┐
1260 │Keyword │ Description │ Type │
1261 ├────────┼─────────────────────┼────────────┤
1262 │daddr │ Destination MAC ad‐ │ ether_addr │
1263 │ │ dress │ │
1264 ├────────┼─────────────────────┼────────────┤
1265 │saddr │ Source MAC address │ ether_addr │
1266 ├────────┼─────────────────────┼────────────┤
1267 │type │ EtherType │ ether_type │
1268 └────────┴─────────────────────┴────────────┘
1269 VLAN HEADER EXPRESSION
1270 vlan [VLAN header field]
1271 VLAN header expression
1273 ┌────────┬─────────────────────┬──────────────────┐
1275 │Keyword │ Description │ Type │
1276 ├────────┼─────────────────────┼──────────────────┤
1277 │id │ VLAN ID (VID) │ integer (12 bit) │
1278 ├────────┼─────────────────────┼──────────────────┤
1279 │cfi │ Canonical Format │ integer (1 bit) │
1280 │ │ Indicator │ │
1281 ├────────┼─────────────────────┼──────────────────┤
1282 │pcp │ Priority code point │ integer (3 bit) │
1283 ├────────┼─────────────────────┼──────────────────┤
1284 │type │ EtherType │ ether_type │
1285 └────────┴─────────────────────┴──────────────────┘
1286 ARP HEADER EXPRESSION
1287 arp [ARP header field]
1288 ARP header expression
1290 ┌──────────┬─────────────────────┬──────────────────┐
1292 │Keyword │ Description │ Type │
1293 ├──────────┼─────────────────────┼──────────────────┤
1294 │htype │ ARP hardware type │ integer (16 bit) │
1295 ├──────────┼─────────────────────┼──────────────────┤
1296 │ptype │ EtherType │ ether_type │
1297 ├──────────┼─────────────────────┼──────────────────┤
1298 │hlen │ Hardware address │ integer (8 bit) │
1299 │ │ len │ │
1300 ├──────────┼─────────────────────┼──────────────────┤
1301 │plen │ Protocol address │ integer (8 bit) │
1302 │ │ len │ │
1303 ├──────────┼─────────────────────┼──────────────────┤
1304 │operation │ Operation │ arp_op │
1305 └──────────┴─────────────────────┴──────────────────┘
1306 IPV4 HEADER EXPRESSION
1307 ip [IPv4 header field]
1308 IPv4 header expression
1310 ┌──────────┬─────────────────────┬─────────────────────┐
1312 │Keyword │ Description │ Type │
1313 ├──────────┼─────────────────────┼─────────────────────┤
1314 │version │ IP header version │ integer (4 bit) │
1315 │ │ (4) │ │
1316 ├──────────┼─────────────────────┼─────────────────────┤
1317 │hdrlength │ IP header length │ integer (4 bit) │
1318 │ │ including options │ FIXME scaling │
1319 ├──────────┼─────────────────────┼─────────────────────┤
1320 │dscp │ Differentiated Ser‐ │ dscp │
1321 │ │ vices Code Point │ │
1322 ├──────────┼─────────────────────┼─────────────────────┤
1323 │ecn │ Explicit Congestion │ ecn │
1324 │ │ Notification │ │
1325 ├──────────┼─────────────────────┼─────────────────────┤
1326 │length │ Total packet length │ integer (16 bit) │
1327 ├──────────┼─────────────────────┼─────────────────────┤
1328 │id │ IP ID │ integer (16 bit) │
1329 ├──────────┼─────────────────────┼─────────────────────┤
1330 │frag-off │ Fragment offset │ integer (16 bit) │
1331 ├──────────┼─────────────────────┼─────────────────────┤
1332 │ttl │ Time to live │ integer (8 bit) │
1333 ├──────────┼─────────────────────┼─────────────────────┤
1334 │protocol │ Upper layer proto‐ │ inet_proto │
1335 │ │ col │ │
1336 ├──────────┼─────────────────────┼─────────────────────┤
1337 │checksum │ IP header checksum │ integer (16 bit) │
1338 ├──────────┼─────────────────────┼─────────────────────┤
1339 │saddr │ Source address │ ipv4_addr │
1340 ├──────────┼─────────────────────┼─────────────────────┤
1341 │daddr │ Destination address │ ipv4_addr │
1342 └──────────┴─────────────────────┴─────────────────────┘
1343 ICMP HEADER EXPRESSION
1344 icmp [ICMP header field]
1345 ICMP header expression
1347 ┌─────────┬─────────────────────┬──────────────────┐
1349 │Keyword │ Description │ Type │
1350 ├─────────┼─────────────────────┼──────────────────┤
1351 │type │ ICMP type field │ icmp_type │
1352 ├─────────┼─────────────────────┼──────────────────┤
1353 │code │ ICMP code field │ integer (8 bit) │
1354 ├─────────┼─────────────────────┼──────────────────┤
1355 │checksum │ ICMP checksum field │ integer (16 bit) │
1356 ├─────────┼─────────────────────┼──────────────────┤
1357 │id │ ID of echo re‐ │ integer (16 bit) │
1358 │ │ quest/response │ │
1359 ├─────────┼─────────────────────┼──────────────────┤
1360 │sequence │ sequence number of │ integer (16 bit) │
1361 │ │ echo request/re‐ │ │
1362 │ │ sponse │ │
1363 ├─────────┼─────────────────────┼──────────────────┤
1364 │gateway │ gateway of redi‐ │ integer (32 bit) │
1365 │ │ rects │ │
1366 ├─────────┼─────────────────────┼──────────────────┤
1367 │mtu │ MTU of path MTU │ integer (16 bit) │
1368 │ │ discovery │ │
1369 └─────────┴─────────────────────┴──────────────────┘
1370 IPV6 HEADER EXPRESSION
1371 ip6 [IPv6 header field]
1372 IPv6 header expression
1374 ┌──────────┬─────────────────────┬──────────────────┐
1376 │Keyword │ Description │ Type │
1377 ├──────────┼─────────────────────┼──────────────────┤
1378 │version │ IP header version │ integer (4 bit) │
1379 │ │ (6) │ │
1380 ├──────────┼─────────────────────┼──────────────────┤
1381 │dscp │ Differentiated Ser‐ │ dscp │
1382 │ │ vices Code Point │ │
1383 ├──────────┼─────────────────────┼──────────────────┤
1384 │ecn │ Explicit Congestion │ ecn │
1385 │ │ Notification │ │
1386 ├──────────┼─────────────────────┼──────────────────┤
1387 │flowlabel │ Flow label │ integer (20 bit) │
1388 ├──────────┼─────────────────────┼──────────────────┤
1389 │length │ Payload length │ integer (16 bit) │
1390 ├──────────┼─────────────────────┼──────────────────┤
1391 │nexthdr │ Nexthdr protocol │ inet_proto │
1392 ├──────────┼─────────────────────┼──────────────────┤
1393 │hoplimit │ Hop limit │ integer (8 bit) │
1394 ├──────────┼─────────────────────┼──────────────────┤
1395 │saddr │ Source address │ ipv6_addr │
1396 ├──────────┼─────────────────────┼──────────────────┤
1397 │daddr │ Destination address │ ipv6_addr │
1398 └──────────┴─────────────────────┴──────────────────┘
1399 ICMPV6 HEADER EXPRESSION
1400 icmpv6 [ICMPv6 header field]
1401 ICMPv6 header expression
1403 ┌──────────────────┬─────────────────────┬──────────────────┐
1405 │Keyword │ Description │ Type │
1406 ├──────────────────┼─────────────────────┼──────────────────┤
1407 │type │ ICMPv6 type field │ icmpv6_type │
1408 ├──────────────────┼─────────────────────┼──────────────────┤
1409 │code │ ICMPv6 code field │ integer (8 bit) │
1410 ├──────────────────┼─────────────────────┼──────────────────┤
1411 │checksum │ ICMPv6 checksum │ integer (16 bit) │
1412 │ │ field │ │
1413 ├──────────────────┼─────────────────────┼──────────────────┤
1414 │parameter-problem │ pointer to problem │ integer (32 bit) │
1415 ├──────────────────┼─────────────────────┼──────────────────┤
1416 │packet-too-big │ oversized MTU │ integer (32 bit) │
1417 ├──────────────────┼─────────────────────┼──────────────────┤
1418 │id │ ID of echo re‐ │ integer (16 bit) │
1419 │ │ quest/response │ │
1420 ├──────────────────┼─────────────────────┼──────────────────┤
1421 │sequence │ sequence number of │ integer (16 bit) │
1422 │ │ echo request/re‐ │ │
1423 │ │ sponse │ │
1424 ├──────────────────┼─────────────────────┼──────────────────┤
1425 │max-delay │ maximum response │ integer (16 bit) │
1426 │ │ delay of MLD │ │
1427 │ │ queries │ │
1428 └──────────────────┴─────────────────────┴──────────────────┘
1429 TCP HEADER EXPRESSION
1430 tcp [TCP header field]
1431 TCP header expression
1433 ┌─────────┬──────────────────┬─────────────────────┐
1435 │Keyword │ Description │ Type │
1436 ├─────────┼──────────────────┼─────────────────────┤
1437 │sport │ Source port │ inet_service │
1438 ├─────────┼──────────────────┼─────────────────────┤
1439 │dport │ Destination port │ inet_service │
1440 ├─────────┼──────────────────┼─────────────────────┤
1441 │sequence │ Sequence number │ integer (32 bit) │
1442 ├─────────┼──────────────────┼─────────────────────┤
1443 │ackseq │ Acknowledgement │ integer (32 bit) │
1444 │ │ number │ │
1445 ├─────────┼──────────────────┼─────────────────────┤
1446 │doff │ Data offset │ integer (4 bit) │
1447 │ │ │ FIXME scaling │
1448 ├─────────┼──────────────────┼─────────────────────┤
1449 │reserved │ Reserved area │ integer (4 bit) │
1450 ├─────────┼──────────────────┼─────────────────────┤
1451 │flags │ TCP flags │ tcp_flag │
1452 ├─────────┼──────────────────┼─────────────────────┤
1453 │window │ Window │ integer (16 bit) │
1454 ├─────────┼──────────────────┼─────────────────────┤
1455 │checksum │ Checksum │ integer (16 bit) │
1456 ├─────────┼──────────────────┼─────────────────────┤
1457 │urgptr │ Urgent pointer │ integer (16 bit) │
1458 └─────────┴──────────────────┴─────────────────────┘
1459 UDP HEADER EXPRESSION
1460 udp [UDP header field]
1461 UDP header expression
1463 ┌─────────┬─────────────────────┬──────────────────┐
1465 │Keyword │ Description │ Type │
1466 ├─────────┼─────────────────────┼──────────────────┤
1467 │sport │ Source port │ inet_service │
1468 ├─────────┼─────────────────────┼──────────────────┤
1469 │dport │ Destination port │ inet_service │
1470 ├─────────┼─────────────────────┼──────────────────┤
1471 │length │ Total packet length │ integer (16 bit) │
1472 ├─────────┼─────────────────────┼──────────────────┤
1473 │checksum │ Checksum │ integer (16 bit) │
1474 └─────────┴─────────────────────┴──────────────────┘
1475 UDP-LITE HEADER EXPRESSION
1476 udplite [UDP-Lite header field]
1477 UDP-Lite header expression
1479 ┌─────────┬──────────────────┬──────────────────┐
1481 │Keyword │ Description │ Type │
1482 ├─────────┼──────────────────┼──────────────────┤
1483 │sport │ Source port │ inet_service │
1484 ├─────────┼──────────────────┼──────────────────┤
1485 │dport │ Destination port │ inet_service │
1486 ├─────────┼──────────────────┼──────────────────┤
1487 │checksum │ Checksum │ integer (16 bit) │
1488 └─────────┴──────────────────┴──────────────────┘
1489 SCTP HEADER EXPRESSION
1490 sctp [SCTP header field]
1491 SCTP header expression
1493 ┌─────────┬──────────────────┬──────────────────┐
1495 │Keyword │ Description │ Type │
1496 ├─────────┼──────────────────┼──────────────────┤
1497 │sport │ Source port │ inet_service │
1498 ├─────────┼──────────────────┼──────────────────┤
1499 │dport │ Destination port │ inet_service │
1500 ├─────────┼──────────────────┼──────────────────┤
1501 │vtag │ Verfication Tag │ integer (32 bit) │
1502 ├─────────┼──────────────────┼──────────────────┤
1503 │checksum │ Checksum │ integer (32 bit) │
1504 └─────────┴──────────────────┴──────────────────┘
1505 DCCP HEADER EXPRESSION
1506 dccp [DCCP header field]
1507 DCCP header expression
1509 ┌────────┬──────────────────┬──────────────┐
1511 │Keyword │ Description │ Type │
1512 ├────────┼──────────────────┼──────────────┤
1513 │sport │ Source port │ inet_service │
1514 ├────────┼──────────────────┼──────────────┤
1515 │dport │ Destination port │ inet_service │
1516 └────────┴──────────────────┴──────────────┘
1517 AUTHENTICATION HEADER EXPRESSION
1518 ah [AH header field]
1519 AH header expression
1521 ┌──────────┬─────────────────────┬──────────────────┐
1523 │Keyword │ Description │ Type │
1524 ├──────────┼─────────────────────┼──────────────────┤
1525 │nexthdr │ Next header proto‐ │ inet_proto │
1526 │ │ col │ │
1527 ├──────────┼─────────────────────┼──────────────────┤
1528 │hdrlength │ AH Header length │ integer (8 bit) │
1529 ├──────────┼─────────────────────┼──────────────────┤
1530 │reserved │ Reserved area │ integer (16 bit) │
1531 ├──────────┼─────────────────────┼──────────────────┤
1532 │spi │ Security Parameter │ integer (32 bit) │
1533 │ │ Index │ │
1534 ├──────────┼─────────────────────┼──────────────────┤
1535 │sequence │ Sequence number │ integer (32 bit) │
1536 └──────────┴─────────────────────┴──────────────────┘
1537 ENCRYPTED SECURITY PAYLOAD HEADER EXPRESSION
1538 esp [ESP header field]
1539 ESP header expression
1541 ┌─────────┬─────────────────────┬──────────────────┐
1543 │Keyword │ Description │ Type │
1544 ├─────────┼─────────────────────┼──────────────────┤
1545 │spi │ Security Parameter │ integer (32 bit) │
1546 │ │ Index │ │
1547 ├─────────┼─────────────────────┼──────────────────┤
1548 │sequence │ Sequence number │ integer (32 bit) │
1549 └─────────┴─────────────────────┴──────────────────┘
1550 IPCOMP HEADER EXPRESSION
1551 comp [IPComp header field]
1552 IPComp header expression
1554 ┌────────┬─────────────────────┬──────────────────┐
1556 │Keyword │ Description │ Type │
1557 ├────────┼─────────────────────┼──────────────────┤
1558 │nexthdr │ Next header proto‐ │ inet_proto │
1559 │ │ col │ │
1560 ├────────┼─────────────────────┼──────────────────┤
1561 │flags │ Flags │ bitmask │
1562 ├────────┼─────────────────────┼──────────────────┤
1563 │cpi │ Compression Parame‐ │ integer (16 bit) │
1564 │ │ ter Index │ │
1565 └────────┴─────────────────────┴──────────────────┘
1566 EXTENSION HEADER EXPRESSIONS
1567 Extension header expressions refer to data from variable-sized protocol
1568 headers, such as IPv6 extension headers and TCPs options.
1569 nftables currently supports matching (finding) a given ipv6 extension
1571 header or TCP option.
1572 hbh {nexthdr | hdrlength}
1573 frag {nexthdr | frag-off | more-fragments | id}
1574 rt {nexthdr | hdrlength | type | seg-left}
1575 dst {nexthdr | hdrlength}
1576 mh {nexthdr | hdrlength | checksum | type}
1577 tcp option {eol | noop | maxseg | window | sack-permitted | sack |
1578 sack0 | sack1 | sack2 | sack3 | timestamp} tcp_option_field
1579 The following syntaxes are valid only in a relational expression with
1581 boolean type on right-hand side for checking header existence only:
1582 exthdr {hbh | frag | rt | dst | mh}
1583 tcp option {eol | noop | maxseg | window | sack-permitted | sack |
1584 sack0 | sack1 | sack2 | sack3 | timestamp}
1585 IPv6 extension headers
1587 ┌────────┬──────────────────────┐
1589 │Keyword │ Description │
1590 ├────────┼──────────────────────┤
1591 │hbh │ Hop by Hop │
1592 ├────────┼──────────────────────┤
1593 │rt │ Routing Header │
1594 ├────────┼──────────────────────┤
1595 │frag │ Fragmentation header │
1596 ├────────┼──────────────────────┤
1597 │dst │ dst options │
1598 ├────────┼──────────────────────┤
1599 │mh │ Mobility Header │
1600 └────────┴──────────────────────┘
1601 TCP Options
1602 ┌───────────────┬─────────────────────┬─────────────────────┐
1604 │Keyword │ Description │ TCP option fields │
1605 ├───────────────┼─────────────────────┼─────────────────────┤
1606 │eol │ End of option list │ kind │
1607 ├───────────────┼─────────────────────┼─────────────────────┤
1608 │noop │ 1 Byte TCP No-op │ kind │
1609 │ │ options │ │
1610 ├───────────────┼─────────────────────┼─────────────────────┤
1611 │maxseg │ TCP Maximum Segment │ kind, length, size │
1612 │ │ Size │ │
1613 ├───────────────┼─────────────────────┼─────────────────────┤
1614 │window │ TCP Window Scaling │ kind, length, count │
1615 ├───────────────┼─────────────────────┼─────────────────────┤
1616 │sack-permitted │ TCP SACK permitted │ kind, length │
1617 ├───────────────┼─────────────────────┼─────────────────────┤
1618 │sack │ TCP Selective Ac‐ │ kind, length, left, │
1619 │ │ knowledgement │ right │
1620 │ │ (alias of block 0) │ │
1621 ├───────────────┼─────────────────────┼─────────────────────┤
1622 │sack0 │ TCP Selective Ac‐ │ kind, length, left, │
1623 │ │ knowledgement │ right │
1624 │ │ (block 0) │ │
1625 ├───────────────┼─────────────────────┼─────────────────────┤
1626 │sack1 │ TCP Selective Ac‐ │ kind, length, left, │
1627 │ │ knowledgement │ right │
1628 │ │ (block 1) │ │
1629 ├───────────────┼─────────────────────┼─────────────────────┤
1630 │sack2 │ TCP Selective Ac‐ │ kind, length, left, │
1631 │ │ knowledgement │ right │
1632 │ │ (block 2) │ │
1633 ├───────────────┼─────────────────────┼─────────────────────┤
1634 │sack3 │ TCP Selective Ac‐ │ kind, length, left, │
1635 │ │ knowledgement │ right │
1636 │ │ (block 3) │ │
1637 ├───────────────┼─────────────────────┼─────────────────────┤
1638 │timestamp │ TCP Timestamps │ kind, length, │
1639 │ │ │ tsval, tsecr │
1640 └───────────────┴─────────────────────┴─────────────────────┘
1641 finding TCP options
1642 filter input tcp option sack-permitted kind 1 counter
1644 matching IPv6 exthdr
1647 ip6 filter input frag more-fragments 1 counter
1649 CONNTRACK EXPRESSIONS
1652 Conntrack expressions refer to meta data of the connection tracking en‐
1653 try associated with a packet.
1654 There are three types of conntrack expressions. Some conntrack expres‐
1656 sions require the flow direction before the conntrack key, others must
1657 be used directly because they are direction agnostic. The packets,
1658 bytes and avgpkt keywords can be used with or without a direction. If
1659 the direction is omitted, the sum of the original and the reply direc‐
1660 tion is returned. The same is true for the zone, if a direction is giv‐
1661 en, the zone is only matched if the zone id is tied to the given direc‐
1662 tion.
1663 ct {state | direction | status | mark | expiration | helper | label |
1665 l3proto | protocol | bytes | packets | avgpkt | zone}
1666 ct {original | reply} {l3proto | protocol | proto-src | proto-dst |
1667 bytes | packets | avgpkt | zone}
1668 ct {original | reply} {ip | ip6} {saddr | daddr}
1669 Conntrack expressions
1671 ┌───────────┬─────────────────────┬─────────────────────┐
1673 │Keyword │ Description │ Type │
1674 ├───────────┼─────────────────────┼─────────────────────┤
1675 │state │ State of the con‐ │ ct_state │
1676 │ │ nection │ │
1677 ├───────────┼─────────────────────┼─────────────────────┤
1678 │direction │ Direction of the │ ct_dir │
1679 │ │ packet relative to │ │
1680 │ │ the connection │ │
1681 ├───────────┼─────────────────────┼─────────────────────┤
1682 │status │ Status of the con‐ │ ct_status │
1683 │ │ nection │ │
1684 ├───────────┼─────────────────────┼─────────────────────┤
1685 │mark │ Connection mark │ mark │
1686 ├───────────┼─────────────────────┼─────────────────────┤
1687 │expiration │ Connection expira‐ │ time │
1688 │ │ tion time │ │
1689 ├───────────┼─────────────────────┼─────────────────────┤
1690 │helper │ Helper associated │ string │
1691 │ │ with the connection │ │
1692 ├───────────┼─────────────────────┼─────────────────────┤
1693 │label │ Connection tracking │ ct_label │
1694 │ │ label bit or sym‐ │ │
1695 │ │ bolic name defined │ │
1696 │ │ in connlabel.conf │ │
1697 │ │ in the nftables in‐ │ │
1698 │ │ clude path │ │
1699 ├───────────┼─────────────────────┼─────────────────────┤
1700 │l3proto │ Layer 3 protocol of │ nf_proto │
1701 │ │ the connection │ │
1702 ├───────────┼─────────────────────┼─────────────────────┤
1703 │saddr │ Source address of │ ipv4_addr/ipv6_addr │
1704 │ │ the connection for │ │
1705 │ │ the given direction │ │
1706 ├───────────┼─────────────────────┼─────────────────────┤
1707 │daddr │ Destination address │ ipv4_addr/ipv6_addr │
1708 │ │ of the connection │ │
1709 │ │ for the given di‐ │ │
1710 │ │ rection │ │
1711 ├───────────┼─────────────────────┼─────────────────────┤
1712 │protocol │ Layer 4 protocol of │ inet_proto │
1713 │ │ the connection for │ │
1714 │ │ the given direction │ │
1715 ├───────────┼─────────────────────┼─────────────────────┤
1716 │proto-src │ Layer 4 protocol │ integer (16 bit) │
1717 │ │ source for the giv‐ │ │
1718 │ │ en direction │ │
1719 ├───────────┼─────────────────────┼─────────────────────┤
1720 │proto-dst │ Layer 4 protocol │ integer (16 bit) │
1721 │ │ destination for the │ │
1722 │ │ given direction │ │
1723 ├───────────┼─────────────────────┼─────────────────────┤
1724 │packets │ packet count seen │ integer (64 bit) │
1725 │ │ in the given direc‐ │ │
1726 │ │ tion or sum of │ │
1727 │ │ original and reply │ │
1728 ├───────────┼─────────────────────┼─────────────────────┤
1729 │bytes │ bytecount seen, see │ integer (64 bit) │
1730 │ │ description for │ │
1731 │ │ packets keyword │ │
1732 ├───────────┼─────────────────────┼─────────────────────┤
1733 │avgpkt │ average bytes per │ integer (64 bit) │
1734 │ │ packet, see de‐ │ │
1735 │ │ scription for pack‐ │ │
1736 │ │ ets keyword │ │
1737 ├───────────┼─────────────────────┼─────────────────────┤
1738 │zone │ conntrack zone │ integer (16 bit) │
1739 └───────────┴─────────────────────┴─────────────────────┘
1740 A description of conntrack-specific types listed above can be found
1741 sub-section CONNTRACK TYPES above.
1742
1744 Statements represent actions to be performed. They can alter control
1745 flow (return, jump to a different chain, accept or drop the packet) or
1746 can perform actions, such as logging, rejecting a packet, etc.
1747 Statements exist in two kinds. Terminal statements unconditionally ter‐
1749 minate evaluation of the current rule, non-terminal statements either
1750 only conditionally or never terminate evaluation of the current rule,
1751 in other words, they are passive from the ruleset evaluation perspec‐
1752 tive. There can be an arbitrary amount of non-terminal statements in a
1753 rule, but only a single terminal statement as the final statement.
1754 VERDICT STATEMENT
1756 The verdict statement alters control flow in the ruleset and issues
1757 policy decisions for packets.
1758 {accept | drop | queue | continue | return}
1760 {jump | goto} {chain}
1761 accept Terminate ruleset evaluation and accept the packet.
1763 drop Terminate ruleset evaluation and drop the packet.
1765 queue Terminate ruleset evaluation and queue the packet to userspace.
1767 continue
1769 Continue ruleset evaluation with the next rule. FIXME
1770 return Return from the current chain and continue evaluation at the
1772 next rule in the last chain. If issued in a base chain, it is
1773 equivalent to accept.
1774 jump chain
1776 Continue evaluation at the first rule in chain. The current po‐
1777 sition in the ruleset is pushed to a call stack and evaluation
1778 will continue there when the new chain is entirely evaluated of
1779 a return verdict is issued.
1780 goto chain
1782 Similar to jump, but the current position is not pushed to the
1783 call stack, meaning that after the new chain evaluation will
1784 continue at the last chain instead of the one containing the go‐
1785 to statement.
1786 Verdict statements
1788 # process packets from eth0 and the internal network in from_lan
1790 # chain, drop all packets from eth0 with different source addresses.
1791 filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan
1793 filter input iif eth0 drop
1794 PAYLOAD STATEMENT
1797 The payload statement alters packet content. It can be used for exam‐
1798 ple to set ip DSCP (differv) header field or ipv6 flow labels.
1799 route some packets instead of bridging
1801 # redirect tcp:http from 192.160.0.0/16 to local machine for routing instead of bridging
1803 # assumes 00:11:22:33:44:55 is local MAC address.
1804 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
1805 Set IPv4 DSCP header field
1808 ip forward ip dscp set 42
1810 EXTENSION HEADER STATEMENT
1813 The extension header statement alters packet content in variable-sized
1814 headers. This can currently be used to alter the TCP Maximum segment
1815 size of packets, similar to TCPMSS.
1816 change tcp mss
1818 tcp flags syn tcp option maxseg size set 1360
1820 # set a size based on route information:
1821 tcp flags syn tcp option maxseg size set rt mtu
1822 LOG STATEMENT
1825 log [prefix quoted_string] [level syslog-level] [flags log-flags]
1826 log group nflog_group [prefix quoted_string] [queue-threshold value]
1827 [snaplen size]
1828 The log statement enables logging of matching packets. When this state‐
1830 ment is used from a rule, the Linux kernel will print some information
1831 on all matching packets, such as header fields, via the kernel log
1832 (where it can be read with dmesg(1) or read in the syslog). If the
1833 group number is specified, the Linux kernel will pass the packet to
1834 nfnetlink_log which will multicast the packet through a netlink socket
1835 to the specified multicast group. One or more userspace processes may
1836 subscribe to the group to receive the packets, see libnetfilter_queue
1837 documentation for details. This is a non-terminating statement, so the
1838 rule evaluation continues after the packet is logged.
1839 log statement options
1841 ┌────────────────┬─────────────────────┬─────────────────────┐
1843 │Keyword │ Description │ Type │
1844 ├────────────────┼─────────────────────┼─────────────────────┤
1845 │prefix │ Log message prefix │ quoted string │
1846 ├────────────────┼─────────────────────┼─────────────────────┤
1847 │syslog-level │ Syslog level of │ string: emerg, │
1848 │ │ logging │ alert, crit, err, │
1849 │ │ │ warn [default], no‐ │
1850 │ │ │ tice, info, debug │
1851 ├────────────────┼─────────────────────┼─────────────────────┤
1852 │group │ NFLOG group to send │ unsigned integer │
1853 │ │ messages to │ (16 bit) │
1854 ├────────────────┼─────────────────────┼─────────────────────┤
1855 │snaplen │ Length of packet │ unsigned integer │
1856 │ │ payload to include │ (32 bit) │
1857 │ │ in netlink message │ │
1858 ├────────────────┼─────────────────────┼─────────────────────┤
1859 │queue-threshold │ Number of packets │ unsigned integer │
1860 │ │ to queue inside the │ (32 bit) │
1861 │ │ kernel before send‐ │ │
1862 │ │ ing them to │ │
1863 │ │ userspace │ │
1864 └────────────────┴─────────────────────┴─────────────────────┘
1865 log-flags
1866 ┌─────────────┬────────────────────────────┐
1868 │Flag │ Description │
1869 ├─────────────┼────────────────────────────┤
1870 │tcp sequence │ Log TCP sequence numbers. │
1871 ├─────────────┼────────────────────────────┤
1872 │tcp options │ Log options from the TCP │
1873 │ │ packet header. │
1874 ├─────────────┼────────────────────────────┤
1875 │ip options │ Log options from the │
1876 │ │ IP/IPv6 packet header. │
1877 ├─────────────┼────────────────────────────┤
1878 │skuid │ Log the userid of the │
1879 │ │ process which generated │
1880 │ │ the packet. │
1881 ├─────────────┼────────────────────────────┤
1882 │ether │ Decode MAC addresses and │
1883 │ │ protocol. │
1884 ├─────────────┼────────────────────────────┤
1885 │all │ Enable all log flags list‐ │
1886 │ │ ed above. │
1887 └─────────────┴────────────────────────────┘
1888 Using log statement
1889 # log the UID which generated the packet and ip options
1891 ip filter output log flags skuid flags ip options
1892 # log the tcp sequence numbers and tcp options from the TCP packet
1894 ip filter output log flags tcp sequence,options
1895 # enable all supported log flags
1897 ip6 filter output log flags all
1898 REJECT STATEMENT
1901 reject [ with {icmp | icmpv6 | icmpx} type {icmp_code | icmpv6_code |
1902 icmpx_code} ]
1903 reject [ with {tcp} {reset} ]
1904 A reject statement is used to send back an error packet in response to
1906 the matched packet otherwise it is equivalent to drop so it is a termi‐
1907 nating statement, ending rule traversal. This statement is only valid
1908 in the input, forward and output chains, and user-defined chains which
1909 are only called from those chains.
1910 The different ICMP reject variants are meant for use in different table
1912 families:
1913 ┌────────┬────────┬─────────────┐
1915 │Variant │ Family │ Type │
1916 ├────────┼────────┼─────────────┤
1917 │icmp │ ip │ icmp_code │
1918 ├────────┼────────┼─────────────┤
1919 │icmpv6 │ ip6 │ icmpv6_code │
1920 ├────────┼────────┼─────────────┤
1921 │icmpx │ inet │ icmpx_code │
1922 └────────┴────────┴─────────────┘
1923 For a description of the different types and a list of supported key‐
1924 words refer to DATA TYPES section above. The common default reject
1925 value is port-unreachable.
1926 COUNTER STATEMENT
1928 A counter statement sets the hit count of packets along with the number
1929 of bytes.
1930 counter {packets number } {bytes number }
1932 CONNTRACK STATEMENT
1934 The conntrack statement can be used to set the conntrack mark and con‐
1935 ntrack labels.
1936 ct {mark | event | label | zone} set value
1938 The ct statement sets meta data associated with a connection. The zone
1940 id has to be assigned before a conntrack lookup takes place, i.e. this
1941 has to be done in prerouting and possibly output (if locally generated
1942 packets need to be placed in a distinct zone), with a hook priority of
1943 -300.
1944 Conntrack statement types
1946 ┌────────┬─────────────────────┬─────────────────────┐
1948 │Keyword │ Description │ Value │
1949 ├────────┼─────────────────────┼─────────────────────┤
1950 │event │ conntrack event │ bitmask, integer │
1951 │ │ bits │ (32 bit) │
1952 ├────────┼─────────────────────┼─────────────────────┤
1953 │helper │ name of ct helper │ quoted string │
1954 │ │ object to assign to │ │
1955 │ │ the connection │ │
1956 ├────────┼─────────────────────┼─────────────────────┤
1957 │mark │ Connection tracking │ mark │
1958 │ │ mark │ │
1959 ├────────┼─────────────────────┼─────────────────────┤
1960 │label │ Connection tracking │ label │
1961 │ │ label │ │
1962 ├────────┼─────────────────────┼─────────────────────┤
1963 │zone │ conntrack zone │ integer (16 bit) │
1964 └────────┴─────────────────────┴─────────────────────┘
1965 save packet nfmark in conntrack
1966 ct mark set meta mark
1968 set zone mapped via interface
1971 table inet raw {
1973 chain prerouting {
1974 type filter hook prerouting priority -300;
1975 ct zone set iif map { "eth1" : 1, "veth1" : 2 }
1976 }
1977 chain output {
1978 type filter hook output priority -300;
1979 ct zone set oif map { "eth1" : 1, "veth1" : 2 }
1980 }
1981 }
1982 restrict events reported by ctnetlink
1985 ct event set new,related,destroy
1987 META STATEMENT
1990 A meta statement sets the value of a meta expression. The existing
1991 meta fields are: priority, mark, pkttype, nftrace.
1992 meta {mark | priority | pkttype | nftrace} set value
1994 A meta statement sets meta data associated with a packet.
1996 Meta statement types
1998 ┌─────────┬─────────────────────┬───────────┐
2000 │Keyword │ Description │ Value │
2001 ├─────────┼─────────────────────┼───────────┤
2002 │priority │ TC packet priority │ tc_handle │
2003 ├─────────┼─────────────────────┼───────────┤
2004 │mark │ Packet mark │ mark │
2005 ├─────────┼─────────────────────┼───────────┤
2006 │pkttype │ packet type │ pkt_type │
2007 ├─────────┼─────────────────────┼───────────┤
2008 │nftrace │ ruleset packet │ 0, 1 │
2009 │ │ tracing on/off. Use │ │
2010 │ │ monitor trace com‐ │ │
2011 │ │ mand to watch │ │
2012 │ │ traces │ │
2013 └─────────┴─────────────────────┴───────────┘
2014 LIMIT STATEMENT
2015 limit rate [over] packet_number / {second | minute | hour | day} [burst
2016 packet_number packets]
2017 limit rate [over] byte_number {bytes | kbytes | mbytes} / {second |
2018 minute | hour | day | week} [burst byte_number bytes]
2019 A limit statement matches at a limited rate using a token bucket fil‐
2021 ter. A rule using this statement will match until this limit is
2022 reached. It can be used in combination with the log statement to give
2023 limited logging. The over keyword, that is optional, makes it match
2024 over the specified rate.
2025 limit statement values
2027 ┌──────────────┬───────────────────┬─────────────────────┐
2029 │Value │ Description │ Type │
2030 ├──────────────┼───────────────────┼─────────────────────┤
2031 │packet_number │ Number of packets │ unsigned integer │
2032 │ │ │ (32 bit) │
2033 ├──────────────┼───────────────────┼─────────────────────┤
2034 │byte_number │ Number of bytes │ unsigned integer │
2035 │ │ │ (32 bit) │
2036 └──────────────┴───────────────────┴─────────────────────┘
2037 NAT STATEMENTS
2038 snat to address [:port] [persistent, random, fully-random]
2039 snat to address - address [:port - port] [persistent, random, fully-
2040 random]
2041 dnat to address [:port] [persistent, random, fully-random]
2042 dnat to address [:port - port] [persistent, random, fully-random]
2043 masquerade to [:port] [persistent, random, fully-random]
2044 masquerade to [:port - port] [persistent, random, fully-random]
2045 redirect to [:port] [persistent, random, fully-random]
2046 redirect to [:port - port] [persistent, random, fully-random]
2047 The nat statements are only valid from nat chain types.
2049 The snat and masquerade statements specify that the source address of
2051 the packet should be modified. While snat is only valid in the
2052 postrouting and input chains, masquerade makes sense only in postrout‐
2053 ing. The dnat and redirect statements are only valid in the prerouting
2054 and output chains, they specify that the destination address of the
2055 packet should be modified. You can use non-base chains which are called
2056 from base chains of nat chain type too. All future packets in this con‐
2057 nection will also be mangled, and rules should cease being examined.
2058 The masquerade statement is a special form of snat which always uses
2060 the outgoing interface's IP address to translate to. It is particularly
2061 useful on gateways with dynamic (public) IP addresses.
2062 The redirect statement is a special form of dnat which always trans‐
2064 lates the destination address to the local host's one. It comes in
2065 handy if one only wants to alter the destination port of incoming traf‐
2066 fic on different interfaces.
2067 Note that all nat statements require both prerouting and postrouting
2069 base chains to be present since otherwise packets on the return path
2070 won't be seen by netfilter and therefore no reverse translation will
2071 take place.
2072 NAT statement values
2074 ┌───────────┬─────────────────────┬─────────────────────┐
2076 │Expression │ Description │ Type │
2077 ├───────────┼─────────────────────┼─────────────────────┤
2078 │address │ Specifies that the │ ipv4_addr, ipv6_ad‐ │
2079 │ │ source/destination │ dr, eg. abcd::1234, │
2080 │ │ address of the │ or you can use a │
2081 │ │ packet should be │ mapping, eg. meta │
2082 │ │ modified. You may │ mark map { 10 : │
2083 │ │ specify a mapping │ 192.168.1.2, 20 : │
2084 │ │ to relate a list of │ 192.168.1.3 } │
2085 │ │ tuples composed of │ │
2086 │ │ arbitrary expres‐ │ │
2087 │ │ sion key with ad‐ │ │
2088 │ │ dress value. │ │
2089 ├───────────┼─────────────────────┼─────────────────────┤
2090 │port │ Specifies that the │ port number (16 │
2091 │ │ source/destination │ bits) │
2092 │ │ address of the │ │
2093 │ │ packet should be │ │
2094 │ │ modified. │ │
2095 └───────────┴─────────────────────┴─────────────────────┘
2096 NAT statement flags
2097 ┌─────────────┬────────────────────────────┐
2099 │Flag │ Description │
2100 ├─────────────┼────────────────────────────┤
2101 │persistent │ Gives a client the same │
2102 │ │ source-/destination-ad‐ │
2103 │ │ dress for each connection. │
2104 ├─────────────┼────────────────────────────┤
2105 │random │ If used then port mapping │
2106 │ │ will be randomized using a │
2107 │ │ random seeded MD5 hash mix │
2108 │ │ using source and destina‐ │
2109 │ │ tion address and destina‐ │
2110 │ │ tion port. │
2111 ├─────────────┼────────────────────────────┤
2112 │fully-random │ If used then port mapping │
2113 │ │ is generated based on a │
2114 │ │ 32-bit pseudo-random algo‐ │
2115 │ │ rithm. │
2116 └─────────────┴────────────────────────────┘
2117 Using NAT statements
2118 # create a suitable table/chain setup for all further examples
2120 add table nat
2121 add chain nat prerouting { type nat hook prerouting priority 0; }
2122 add chain nat postrouting { type nat hook postrouting priority 100; }
2123 # translate source addresses of all packets leaving via eth0 to address 1.2.3.4
2125 add rule nat postrouting oif eth0 snat to 1.2.3.4
2126 # redirect all traffic entering via eth0 to destination address 192.168.1.120
2128 add rule nat prerouting iif eth0 dnat to 192.168.1.120
2129 # translate source addresses of all packets leaving via eth0 to whatever
2131 # locally generated packets would use as source to reach the same destination
2132 add rule nat postrouting oif eth0 masquerade
2133 # redirect incoming TCP traffic for port 22 to port 2222
2135 add rule nat prerouting tcp dport 22 redirect to :2222
2136 QUEUE STATEMENT
2139 This statement passes the packet to userspace using the nfnetlink_queue
2140 handler. The packet is put into the queue identified by its 16-bit
2141 queue number. Userspace can inspect and modify the packet if desired.
2142 Userspace must then drop or reinject the packet into the kernel. See
2143 libnetfilter_queue documentation for details.
2144 queue [num queue_number] [bypass]
2146 queue [num queue_number_from - queue_number_to] [bypass,fanout]
2147 queue statement values
2149 ┌──────────────────┬─────────────────────┬─────────────────────┐
2151 │Value │ Description │ Type │
2152 ├──────────────────┼─────────────────────┼─────────────────────┤
2153 │queue_number │ Sets queue number, │ unsigned integer │
2154 │ │ default is 0. │ (16 bit) │
2155 ├──────────────────┼─────────────────────┼─────────────────────┤
2156 │queue_number_from │ Sets initial queue │ unsigned integer │
2157 │ │ in the range, if │ (16 bit) │
2158 │ │ fanout is used. │ │
2159 ├──────────────────┼─────────────────────┼─────────────────────┤
2160 │queue_number_to │ Sets closing queue │ unsigned integer │
2161 │ │ in the range, if │ (16 bit) │
2162 │ │ fanout is used. │ │
2163 └──────────────────┴─────────────────────┴─────────────────────┘
2164 queue statement flags
2165 ┌───────┬────────────────────────────┐
2167 │Flag │ Description │
2168 ├───────┼────────────────────────────┤
2169 │bypass │ Let packets go through if │
2170 │ │ userspace application can‐ │
2171 │ │ not back off. Before using │
2172 │ │ this flag, read libnetfil‐ │
2173 │ │ ter_queue documentation │
2174 │ │ for performance tuning re‐ │
2175 │ │ comendations. │
2176 ├───────┼────────────────────────────┤
2177 │fanout │ Distribute packets between │
2178 │ │ several queues. │
2179 └───────┴────────────────────────────┘
2181 These are some additional commands included in nft.
2182 MONITOR
2184 The monitor command allows you to listen to Netlink events produced by
2185 the nf_tables subsystem, related to creation and deletion of objects.
2186 When they occur, nft will print to stdout the monitored events in ei‐
2187 ther XML, JSON or native nft format.
2188 To filter events related to a concrete object, use one of the keywords
2190 'tables', 'chains', 'sets', 'rules', 'elements' , 'ruleset'.
2191 To filter events related to a concrete action, use keyword 'new' or
2193 'destroy'.
2194 Hit ^C to finish the monitor operation.
2196 Listen to all events, report in native nft format
2198 % nft monitor
2200 Listen to added tables, report in XML format
2203 % nft monitor new tables xml
2205 Listen to deleted rules, report in JSON format
2208 % nft monitor destroy rules json
2210 Listen to both new and destroyed chains, in native nft format
2213 % nft monitor chains
2215 Listen to ruleset events such as table, chain, rule, set, counters and
2218 quotas, in native nft format
2219 % nft monitor ruleset
2221
2224 When an error is detected, nft shows the line(s) containing the error,
2225 the position of the erroneous parts in the input stream and marks up
2226 the erroneous parts using carrets (^). If the error results from the
2227 combination of two expressions or statements, the part imposing the
2228 constraints which are violated is marked using tildes (~).
2229 For errors returned by the kernel, nft can't detect which parts of the
2231 input caused the error and the entire command is marked.
2232 Error caused by single incorrect expression
2234 <cmdline>:1:19-22: Error: Interface does not exist
2236 filter output oif eth0
2237 ^^^^
2238 Error caused by invalid combination of two expressions
2241 <cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
2243 filter output tcp dport == tcp dport
2244 ~~ ^^^^^^^^^
2245 Error returned by the kernel
2248 <cmdline>:0:0-23: Error: Could not process rule: Operation not permitted
2250 filter output oif wlan0
2251 ^^^^^^^^^^^^^^^^^^^^^^^
2252
2255 On success, nft exits with a status of 0. Unspecified errors cause it
2256 to exit with a status of 1, memory allocation errors with a status of
2257 2, unable to open Netlink socket with 3.
2258
2260 iptables(8), ip6tables(8), arptables(8), ebtables(8), ip(8), tc(8)
2261 There is an official wiki at: https://wiki.nftables.org
2263
2265 nftables was written by Patrick McHardy and Pablo Neira Ayuso, among
2266 many other contributors from the Netfilter community.
2267
2269 Copyright © 2008-2014 Patrick McHardy <kaber@trash.net>
2270 Copyright © 2013-2016 Pablo Neira Ayuso <pablo@netfilter.org>
2271 nftables is free software; you can redistribute it and/or modify it un‐
2274 der the terms of the GNU General Public License version 2 as published
2275 by the Free Software Foundation.
2276 This documentation is licenced under the terms of the Creative Commons
2278 Attribution-ShareAlike 4.0 license, CC BY-SA 4.0 ⟨http://
2279 creativecommons.org/licenses/by-sa/4.0/⟩ .
2280 20 June 2018 nft(8)