[LINUX] man nftables Japanese translation

Japanese translation of the manual displayed by man nftables.

name

nft-Nftables framework management tool for packet filtering and classification

Overview

nft [ -nNscae ] [ -I directory ] [ -f filename | -i | cmd ...]
nft -h
nft -v

Description

nft is a command line tool used by the Linux kernel of the nftables framework to set, manage, and inspect packet filtering and classification rules. The Linux kernel subsystem is known as nf_tables, where nf stands for Netfilter.

option

Run nft --help to see a complete summary of the options.

• -h, -help Display help messages and all options.
• -v, -version Show the version.
• -n, -numeric Display the data numerically. Once specified (default behavior), address-to-symbol name conversion is skipped. Specify twice to display the Internet service (port number) numerically. Specify three times to display the protocol and UID / GID numerically.
• -N, -reversedns Converts an IP address to a name. DNS lookups typically require network traffic.
• -s, -stateless Omits state information for rules and stateful objects.
• -c, -check Check the validity of the command without actually applying the changes.
• -a, -handle Shows the object handle in the output.
• -e, -echo Display notifications similar to nft monitors when inserting items into a ruleset using the add, insert, replace commands.
• -I, -includepath directory Adds the directory specified in the argument directory to the list of directories to search for include files. This option can be specified multiple times.
• -f、-file filename Read the input from the file name. If the file name is -, read from standard input. The nft script must start with #! / Usr / sbin / nft -f.
• -i, -interactive Reads input from the interactive readline CLI. You can either exit with quit or use the EOF marker. The EOF marker is usually CTRL-D.

Input file format

Vocabulary rules

The input is parsed line by line. If the last character on a line (immediately before the newline character) is an unquoted backslash (\), the next line is treated as a continuation. Multiple commands on the same line can be separated using a semicolon (; ).

The hash sign ( #) starts the comment. All subsequent characters on the same line are ignored.

Identifiers begin with an alphabetic character (az, AZ), with zero or more alphanumeric characters (az, AZ, 0-9), a slash (/), a backslash (\), and an underscore ( It is followed by the characters _) and dots ( .). Identifiers that use different characters or conflict with keywords must be enclosed in double quotes ( ").

Read file

You can use the include statement to read other files. The directory to search for include files can be specified using the -I / --includepath option. To override this behavior, either prefix the path with ./ to force the files in the current working directory (that is, relative paths) to be included, or use the / absolute path. Specifies the location of the file to be represented.

If -I / --includepath is not specified, nft will use the default directory specified at compile time. This default directory can be obtained with the -h / --help option.

The include statement supports the usual shell wildcard symbols (*, ? , []). If the include statement uses wildcard symbols, no error will occur even if there is no match for the include statement. This allows you to specify a potentially empty include directory, such as `ʻinclude / etc / firewall / rules / * . Wildcard matches are read alphabetically. Files that start with a dot ( .``) do not match in the include statement.

Variable symbol

Variable expression definition

$variable

Variable symbols can be defined using the define statement. Variable references are expressions and can be used to initialize other variables. The scope of the definition is the current block and all the blocks contained within it.

Variable usage example

define int_if1 = eth0
define int_if2 = eth1
define int_ifs = { $int_if1, $int_if2 }

filter input iif $int_ifs accept

Address family

The address family determines the type of packet processed. For each address family, the kernel contains hooks that represent specific stages of the packet processing process. These hooks call nftables if the hook's rules exist.

• ip: IPv4 address family.
• ip6: IPv6 address family.
• inet: Internet (IPv4 / IPv6) address family.
• arp: ARP address family. Handles IPv4 ARP packets.
• bridge: Bridge address family. Handles packets passing through the bridge device.
• netdev: Netdev address family. Process packets from the input.

All identifiers include an address family because all nftables objects reside in an address family-specific namespace. If you specify an identifier without an address family, the ip family is used by default.

IPV4 / IPV6 / INET address family

The IPv4 / IPv6 / Inet address family handles IPv4, IPv6, or both types of packets. They contain five hooks at different packet processing stages of the network stack.

IPv4 / IPv6 / Inet Address Family Hook

ARP address family

The ARP address family handles ARP packets sent and received by the system. It is typically used to mangle ARP packets for clustering.

ARP address family hook

Bridge address family

The bridge address family handles Ethernet packets that pass through the bridge device.

The list of supported hooks is the same as the IPv4 / IPv6 / Inet address family above.

NETDEV address family

The Netdev address family handles packets from ingress.

Netdev address family hook

Rule set

{list | flush} ruleset [family]
export [ruleset] format

The ruleset keyword is used to identify the entire set of tables, chains, etc. currently located in the kernel. The following ruleset commands exist.

• list: Displays the ruleset in a human-readable format.
• flush: Flush the entire ruleset. Note that unlike iptables, this removes all tables and everything they contain, leaving a virtually empty ruleset. Packet filtering no longer occurs, so the kernel accepts all valid packets it receives.
• export: Displays the ruleset in machine readable format. The required format parameter is either xml or json.

It is possible to limit the list and flush only specific address families. See Address Family (#Address Family) above for a list of valid family names.

Note that, contrary to expectations, the output produced by export cannot be parsed by nft -f. Instead, the output of the list command serves that purpose.

table

{add | create} table [family] table [ { flags flags } ]
{delete | list | flush} table [family] table
delete table [family] handle handle

Tables are containers for chains, sets, and stateful objects. They are identified by address family and name. The address family must be one of ip, ip6, inet, arp, bridge, netdev. The inet address family is a dummy family used to create hybrid IPv4 / IPv6 tables. You can use the meta-expression nfproto keyword to test the family (IPv4 or IPv6) context in which packets are being processed. If no address family is specified, ip is used by default. The only difference between add and create is that create returns an error, while add does not return an error if the specified table already exists.

Table flag

Example of adding, modifying, or deleting a table

#Launch nft in interactive mode
nft --interactive

#Create a new table.
create table inet mytable

#Add new base chain:Get input packet
add chain inet mytable myin { type filter hook input priority 0; }

#Add a single counter to the chain
add rule inet mytable myin counter

#Temporarily disable the table(Rules are not evaluated)
add table inet mytable { flags dormant; }

#Reactivate the table:
add table inet mytable

• add: Adds a new table for the specified family with the specified name.
• delete: Deletes the specified table.
• list: Lists all chains and rules for the specified table.
• flush: Flush all chains and rules for the specified table.

chain

{add | create} chain [family] table chain [ { type type hook hook [device device] priority priority ; [policy policy ;] } ]
{delete | list | flush} chain [family] table chain
delete chain [family] table handle handle
rename chain [family] table chain newname

A chain is a container for rules. There are two types of chains, base chains and regular chains. The base chain is the entry point for packets from the networking stack. Regular chains can be used as jump targets and are used for better rule formation.

• add: Adds a new chain to the specified table. If a hook and priority value is specified, the chain will be created as a base chain and hooked onto the network stack.
• Similar to the create: add command, but returns an error if the chain already exists.
• delete: Deletes the specified chain. Do not include rules in the chain or use it as a jump target.
• rename: Renames the specified chain.
• list: Lists all the rules for the specified chain.
• flush: Flush all rules in the specified chain.

For base chains, the type, hook, and priority parameters are required.

Supported chain types

Apart from the special case above (for example, the nat type does not support forward hooks, or the route type only supports output hooks), there are two more quirks to note.

• The netdev family only supports a single combination: the filter type and the input hook. The base chain for this family exists for each receiving interface, so device parameters must also be present.

• The arp family is a filter type chain that only supports input and output hooks.

The priority parameter accepts a signed integer value that specifies the order in which chains with the same hook value are traversed. The order is ascending. That is, low priority values take precedence over high values.

The base chain also allows you to set chain policies. The policy sets what happens to packets that are not explicitly accepted or rejected by the predefined rules. The supported policy values are `ʻaccept(default) or drop``.

rule

[add | insert] rule [family] table chain [ {handle | position} handle | index index] statement...
replace rule [family] table chain handle handle statement...
delete rule [family] table chain handle handle

The rule is added to the chain of the specified table. If no family is specified, the ip family will be used. A rule consists of two types of components according to a set of grammatical rules. Expressions and statements.

The add and insert commands support arbitrary position specifiers. This is either the handle or index (starting from zero) of an existing rule. Internally, the location of the rule is always identified by the handle, and the conversion from the index is done in user space. If simultaneous ruleset changes occur after conversion, this has two potential implications. If a rule is inserted or deleted before the referenced rule, the valid rule index may change. If the referenced rule is deleted, the command will be rejected by the kernel, as if an invalid handle was specified.

• add: Adds a new rule described in the list of statements. Unless a handle is specified, the rule will be added to the specified chain. If a handle is specified, the rule is added to the rule specified by the handle. Alternate name positions are deprecated. Please do not use it in the future.
• insert: Similar to the add command, but the rule is added at the beginning of the chain or before the rule with the specified handle.
• replace: Similar to the add command, but replaces the specified rule.
• delete: Deletes the specified rule.

Example of adding a rule to the input chain of iptables

# 'ip filter'Is expected
nft add rule filter output ip daddr 192.168.0.0/24 accept
#Same command, a little more detail
nft add rule ip filter output ip daddr 192.168.0.0/24 accept

Example of deleting a rule from the inet table

nft -a list ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
    ct state established,related accept # handle 4
    ip saddr 10.1.1.1 tcp dport ssh accept # handle 5
    ...

#Delete the rule of handle 5.
nft delete rule inet filter input handle 5

set

nftables provides two types of set concepts. Anonymous sets are sets that do not have a specific name. The members of the set are enclosed in curly braces and the elements are separated by commas when creating rules that use the set. When the rule is deleted, so is the set. You cannot update them. That is, once an anonymous set is declared, it cannot be updated unless the rules that use the anonymous set are deleted or modified.

An example of accepting a specific subnet and port using an anonymous set

nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept

A named set is the first set that must be defined before it can be referenced in a rule. Unlike anonymous sets, elements can be added or removed from named sets at any time. The set is referenced by the rule by prefixing the set name with @.

An example of accepting an address and port using a named set

nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept

The sets ʻallowed_hosts`` and ʻallowed_ports`` must be created first.

The next section details the nft set syntax.

add set [family] table set { type type ; [flags flags ;] [timeout timeout ;] [gc-interval gc-interval ;] [elements = { element[,...] } ;] [size size ;] [policy policy ;] [auto-merge auto-merge ;] }
{delete | list | flush} set [family] table set
delete set [family] table handle handle
{add | delete} element [family] table set { element[,...] }

A set is an element container of a user-defined data type that is uniquely identified by a user-defined name and attached to a table.

• add: Adds a new set to the specified table.
• delete: Deletes the specified set.
• list: Shows the elements of the specified set.
• flush: Flush all elements from the specified set.
• add element A comma-separated list of elements to add to the specified set.
• delete element A comma-separated list of elements to remove from the specified set.

Set specifications

map

add map [family] table map { type type [flags flags ;] [elements = { element[,...] };] [size size ;] [policy policy ;] }
{delete | list | flush} map [family] table map
{add | delete} element [family] table map { elements = { element[,...] } ; }

Maps store data based on a specific key used as input, are uniquely identified by a user-defined name, and are attached to a table.

• add: Adds a new map to the specified table.
• delete: Deletes the specified map.
• list: Shows the elements of the specified map.
• flush: Flush all elements from the specified map.
• add element A comma-separated list of elements to add to the specified map.
• delete element A comma-separated list of element keys to remove from the specified map.

Map specifications

Flow table

{add | create} flowtable [family] table flowtable { hook hook priority priority ; devices = { device[,...] } ; }
{delete | list} flowtable [family] table flowtable

Flow tables can be used to speed up packet forwarding in software. Flow table entries are represented by tuples consisting of ingress interfaces, source and destination addresses, source and destination ports; and Layer 3/4 protocols. Each entry caches the destination interface and gateway address, updates the destination link layer address, and forwards the packet. The ttl and hoplimit fields are also reduced. The flow table therefore provides an alternative path that allows the packet to bypass the traditional forwarding path. The flow table is on the ingress hook in front of the prerouting hook. Flows from the forward chain You can use the offload expression to select the flow to offload. Flow tables are identified by address family and name. The address family must be ip, ip6, or inet. The inet address family is a dummy family used to create hybrid IPv4 / IPv6 tables. If no address family is specified, ip is used by default.

• add: Adds a new flow table for the specified family with the specified name.
• delete: Deletes the specified flow table.
• list: Lists all flow tables.

Stateful object

{add | delete | list | reset} type [family] table object
delete type [family] table handle handle

Stateful objects are attached to the table and identified by a unique name. They group stateful information from the rule and the keyword type name is used to refer to them in the rule. Example: counter name.

• add: Adds a new stateful object to the specified table.
• delete: Deletes the specified object.
• list: Shows the stateful information held by the object.
• reset: Lists and resets stateful objects.

CT

ct helper helper { type type protocol protocol ; [l3proto family ;] }

The ct helper is used to define a connection tracking helper that can be used in combination with the ct helper set statement. type and protocol are required. l3proto is derived from the table family by default. That is, if the kernel supports it, the kernel will try to load both IPv4 and IPv6 helper backends in the inet table.

conntrack helper spec

FTP helper definition and assignment

Unlike iptables, helper assignments should be done, for example, with the default 0 hook priority after the conntrack search is complete.

table inet myhelpers {
  ct helper ftp-standard {
    type "ftp" protocol tcp
  }
  chain prerouting {
    type filter hook prerouting priority 0;
    tcp dport 21 ct helper set "ftp-standard"
  }
}

counter

counter [packets bytes]

Counter specifications

quota

quota [over | until] [used]

Quota specifications

formula

The expression represents the value of either a constant such as a network address or port number, or the data collected from the packet during rule set evaluation. You can combine formulas with binary, logical, relational, and other types of formulas to form complex or relational (matching) formulas. They are also used as arguments for certain types of operations, such as NAT and packet marking.

Each expression has a data type, which determines the size, parsing, representation, and type compatibility of symbolic values with other expressions.

DESCRIBE command

describe expression

The describe command displays information about the type of expression and its data type.

$ nft describe tcp flags
payload expression, datatype tcp_flag (TCP flag) (basetype bitmask, integer), 8 bits

predefined symbolic constants:
fin                           0x01
syn                           0x02
rst                           0x04
psh                           0x08
ack                           0x10
urg                           0x20
ecn                           0x40
cwr                           0x80

Data type

The data type determines the size, parsing, representation, and expression type compatibility of symbolic values. There are several global data types, and some expression types define additional data types that are specific to that expression type. Most data types are fixed size, but some are dynamic size. (Example: string type)

Types can be derived from lower-order types. The IPv4 address type is derived from the integer type. That is, you can also specify the IPv4 address as an integer value.

In certain contexts (set and map definitions), you need to explicitly specify the data type. Each type has a name used for this.

Integer type

The integer type is used for numbers. You can specify it in decimal, hexadecimal, or octal. The integer type is not a fixed size, its size is determined by the expression used.

Bit mask type

The bitmask type (bitmask) is used for the bitmask.

String type

The string type is used for strings. The string begins with an alphabetic character (a-zA-Z), followed by zero or more alphanumeric characters or characters and symbols (/, -, _, .. ) Follows. In addition, anything enclosed in double quotes (") is recognized as a string.

String type specification

#Interface name
filter input iifname eth0

#Strange interface name
filter input iifname "(eth0)"

Link layer address type

The link layer address type is used for the link layer address. Link-layer addresses are specified as a two-digit hexadecimal variable number group separated by colons (:).

Link layer addressing

#Ethernet destination MAC address
filter input ether daddr 20:c9:d0:43:12:d9

IPV4 address type

The IPv4 address type is used for IPv4 addresses. The address is specified as a dotted decimal number, a dotted hexadecimal number, a dotted decimal number, a decimal number, a hexadecimal number, an octal number, or a host name. Hostnames are resolved using a standard system resolver.

IPv4 address specification

#Dot decimal notation
filter output ip daddr 127.0.0.1

#hostname
filter output ip daddr localhost

IPV6 address type

The IPv6 address type is used for IPv6 addresses. The address is specified as a host name or as a colon-separated hexadecimal halfword. The address may be enclosed in square brackets ([]) to distinguish it from the port number.

Specifying an IPv6 address

#Omitted loopback address
filter output ip6 daddr ::1

#Specifying an IPv6 address using square brackets
# []None port number(22)Is parsed as part of the ipv6 address.
ip6 nat prerouting tcp dport 2222 dnat to [1ce::d0]:22

Boolean type

Boolean types are syntax helper types in user space. This is the right-hand side of the (usually implicit) relation and is used to change the expression on the left-hand side to a Boolean check (usually `ʻexists``).

The following keywords are automatically resolved to a Boolean type with the specified value.

Boolean specifications

The following formula supports Boolean comparisons.

#Match if route exists
filter input fib daddr . iif oif exists

#Matches only unfragmented packets of IPv6 traffic
filter input exthdr frag missing

#Match if TCP timestamp option is present
filter input tcp option timestamp exists

ICMP type

ICMP type types are used to easily specify the type field in the ICMP header.

You can use the following keywords when specifying the ICMP type:

ICMP type specification

#Match ping packet
filter output icmp type { echo-request, echo-reply }

ICMP code type

The ICMP code type is used to easily specify the code fields in the ICMP header.

You can use the following keywords when specifying the ICMP code:

ICMPV6 type

The ICMPv6 type type is used to easily specify the type field in the ICMPv6 header.

You can use the following keywords when specifying the ICMPv6 type:

ICMPv6 type specification

#Match ICMPv6 ping packets
filter output icmpv6 type { echo-request, echo-reply }

ICMPV6 code type

The ICMPv6 code type is used to easily specify the code fields in the ICMPv6 header.

You can use the following keywords when specifying the ICMPv6 code:

ICMPVX code type

The ICMPvX code type abstraction is a set of duplicate values between the ICMP and ICMPv6 code types used by the inet family.

You can use the following keywords when specifying the ICMPvX code:

Conntrack type

This is an overview of the types used in ct expressions and statements.

You can use keywords for convenience for each of the above types.

conntrack state(ct_state)

conntrack direction(ct_dir)

conntrack status(ct_status)

conntrack event bits(ct_event)

The keywords that can be specified for conntrack label type (ct_label) are read from /etc/connlabel.conf at run time.

Linear expression

The lowest-level expression is a linear expression that represents a packet's payload, metadata, or constant or single data from a stateful module.

Meta expression

meta {length | nfproto | l4proto | protocol | priority}
[meta] {mark | iif | iifname | iiftype | oif | oifname | oiftype | skuid | skgid | nftrace | rtclassid | ibrname | obrname | pkttype | cpu | iifgroup | oifgroup | cgroup | random | secpath}

A meta expression is the metadata associated with a packet.

There are two types of meta-expressions: unqualified meta-expressions and qualified meta-expressions. Qualified meta expressions require the meta keyword before the meta key. Unqualified meta-expressions allow you to specify the meta key directly or as a qualified meta-expression. The meta l4proto helps to match specific transport protocols that are part of an IPv4 or IPv6 packet. It also skips IPv6 extension headers present in IPv6 packets.

Meta expression type

Meta expression specific type

Example of using meta expression

#Qualified meta expression
filter output meta oif eth0

#Unqualified meta expression
filter output oif eth0

#Packs that were the target of ipsec processing
raw prerouting meta secpath exists accept

FIB (Forwarding Information Base) formula

fib {saddr | daddr | {mark | iif | oif}} {oif | oifname | type}

The fib expression queries fib (forwarding information base) to get information such as the egress interface index used by a particular address. The input is a tuple of elements used as input to the fib search function.

fib expression-specific type

FIB expression usage example

#Drop packets without reverse path
filter prerouting fib saddr . iif oif missing drop

#Drop packets to addresses that are not configured on the interface
filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop

#specific'blackhole'Perform a search on the table( 0xdead,Requires proper ip rules)
filter prerouting meta mark set 0xdead fib daddr . mark type vmap { blackhole : drop, prohibit : jump prohibited, unreachable : drop }

Routing formula

rt {classid | nexthop}

A routing expression refers to the routing data associated with a packet.

Routing expression type

Routing expression specific type

Routing expression usage example

#IP family independent rt expression
filter output rt classid 10

#IP family dependent rt expression
ip filter output rt nexthop 192.168.0.1
ip6 filter output rt nexthop fd00::1
inet filter output rt ip nexthop 192.168.0.1
inet filter output rt ip6 nexthop fd00::1

Payload expression

The payload expression refers to the data from the packet's payload.

Ethernet header expression

ether [Ethernet header field]

Ethernet header expression type

VLAN header expression

vlan [VLAN header field]

ARP header expression

arp [ARP header field]

IPV4 header expression

ip [IPv4 header field]

ICMP header expression

icmp [ICMP header field]

IPV6 header expression

ip6 [IPv6 header field]

This expression references the ipv6 header field. A caveat when using ʻip6 nexthdr``, the value refers only to the next header. That is, ʻip6 nexthdr tcpmatches only if the ipv6 packet does not contain an extension header. It will not be matched if it contains fragmented packets or routing extension headers. Use meta l4proto`` if you want to match the actual transport headers and ignore the additional extension headers instead.

Match if the first extension header points to a fragment

ip6 nexthdr ipv6-frag counter

ICMPV6 header expression

icmpv6 [ICMPv6 header field]

TCP header expression

tcp [TCP header field]

UDP header expression

udp [UDP header field]

Simple UDP header expression

udplite [UDP-Lite header field]

SCTP header expression

sctp [SCTP header field]

DCCP header expression

dccp [DCCP header field]

Authentication header expression

ah [AH header field]

Encrypted security payload header expression

esp [ESP header field]

IPCOMP header expression

comp [IPComp header field]

RAW payload expression

@ [base,offset,length]

The Raw payload expression tells you to load lengthbits that start with offsetbits. Bit 0 points to the first bit. In the C programming language, this corresponds to the most significant bit, or 0x80 in the case of octets. These are useful for matching headers that do not yet have a human-readable template expression. Note that nft does not add raw payload expression dependencies. For example, to match the protocol field in the transport header to protocol number 5, you must manually exclude packets with different transport headers. For example, use meta l4proto 5 before the Raw expression.

Supported payload protocol base

python

#Destination port that matches both UDP and TCP
inet filter input meta l4proto {tcp, udp} @th,16,16 { dns, http }

#If the target protocol address matches the specified address
#rewrite the target hardware address of the arp packet.
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

Extended header expression

Extended header expressions refer to data from variable-sized protocol headers, such as IPv6 extended headers and TCP options.

nftables currently supports matching (searching) for certain ipv6 extension headers or TCP options.

hbh {nexthdr | hdrlength}
frag {nexthdr | frag-off | more-fragments | id}
rt {nexthdr | hdrlength | type | seg-left}
dst {nexthdr | hdrlength}
mh {nexthdr | hdrlength | checksum | type}
srh {flags | tag | sid | seg-left}
tcp option {eol | noop | maxseg | window | sack-permitted | sack | sack0 | sack1 | sack2 | sack3 | timestamp} tcp_option_field

The following syntax is valid only for relational expressions that have a Boolean type on the right side and only check for the existence of headers.

exthdr {hbh | frag | rt | dst | mh}
tcp option {eol | noop | maxseg | window | sack-permitted | sack | sack0 | sack1 | sack2 | sack3 | timestamp}

IPv6 extension header

TCP options

#Search for TCP options
filter input tcp option sack-permitted kind 1 counter

#IPv6 exthdr search
ip6 filter input frag more-fragments 1 counter

CONNTRACK expression

The conntrack expression references the metadata of the connection tracking entry associated with the packet.

There are three types of conntrack expressions. Some conntrack expressions require the flow direction before the conntrack key, while others are direction-independent and must be used directly. The packets, bytes, and ```avgpkt`` keywords can be used with or without orientation. If you omit the direction, the sum of the original direction and the reply direction is returned. The same applies to zones. If a direction is specified, the zones will match only if the zone ID is associated with the specified direction.

ct {state | direction | status | mark | expiration | helper | label | l3proto | protocol | bytes | packets | avgpkt | zone}
ct {original | reply} {l3proto | protocol | proto-src | proto-dst | bytes | packets | avgpkt | zone}
ct {original | reply} {ip | ip6} {saddr | daddr}

A description of the conntrack-specific types above can be found in the CONNTRACK TYPES subsection above.

statement

The statement represents the action to be taken. You can change the control flow (return, jump to another chain, accept or drop packets), and perform actions such as logging and denying packets.

There are two types of statements. The end statement unconditionally ends the evaluation of the current rule. Non-terminating statements only conditionally terminate or never terminate the evaluation of the current rule. That is, they are passive in terms of ruleset evaluation. The rule can contain any number of non-terminating statements, but only a single terminating statement can be used as the final statement.

Judgment statement

The decision statement modifies the control flow of the ruleset and issues a packet policy decision.

{accept | drop | queue | continue | return}
{jump | goto} chain

• accept: Finish ruleset evaluation and accept the packet.
• drop: Finishes ruleset evaluation and drops the packet.
• queue: Finishes ruleset evaluation and queues packets into user space.
• continue: Continue evaluating the ruleset with the following rules. FIXME.
• return: Return from the current chain and continue the evaluation with the next rule in the last chain. When issued in the basechain, it is equivalent to accept.
• jump chain: Continue the evaluation with the first rule in the chain. The current position of the ruleset is pushed onto the call stack, and when the new chain is fully evaluated and a return decision is issued, the evaluation continues there.
• goto chain: Similar to jump, but the current position is not pushed onto the call stack. That is, after evaluating a new chain, it will continue with the last chain, not the chain containing the goto statement.

#Packets from eth0 and internal network from_Process with lan.
filter input iif eth0 ip saddr 192.168.0.0/24 jump from_lan

#Drop all packets from the chain, eth0 with different source addresses.
filter input iif eth0 drop

Payload statement

The payload statement modifies the contents of the packet. For example, it can be used to set the ip DSCP (differv) header field or the ipv6 flow label.

Route some packets instead of bridging.

# tcp:http 192.160.0.0/Redirect from 16 to your local machine and route instead of bridging
# 00:11:22:33:44:It is assumed that 55 is the local MAC address.
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

#IPv4 DSCP header field settings
ip forward ip dscp set 42

Extended header statement

The extended header statement modifies the packet content of variable-sized headers. This can now be used to change the TCP maximum segment size of a packet, similar to TCPMSS.

#Change tcp mss
tcp flags syn tcp option maxseg size set 1360

#Set the size based on the route information
tcp flags syn tcp option maxseg size set rt mtu

Log statement

log [prefix quoted_string] [level syslog-level] [flags log-flags]
log group nflog_group [prefix quoted_string] [queue-threshold value] [snaplen size]

The log statement enables logging of matching packets. When this statement is used from a rule, the Linux kernel prints information about all matching packets, including header fields, through the kernel log (which can be read by dmesg (1) or syslog). If a group number is specified, the Linux kernel passes the packet to the nfnetlink_log and multicasts the packet through the netlink socket to the specified multicast group. One or more userspace processes may be registered in a group and receive packets. See the libnetfilter_queue documentation for more information. Since this is a non-terminating statement, rule evaluation continues even after the packet is logged.

Log statement options

Log flag

Log statement usage example

#Log the UID that generated the packet and IP options
ip filter output log flags skuid flags ip options

#Log TCP sequence numbers and TCP options from TCP packets
ip filter output log flags tcp sequence,options

#Enable all supported log flags
ip6 filter output log flags all

Rejection statement

reject [ with {icmp | icmpv6 | icmpx} type {icmp_code | icmpv6_code | icmpx_code} ]
reject [ with tcp reset ]

The reject statement is used to send back an error packet in response to a matched packet. Otherwise it is the same as drop, so it is an end statement that ends rule traversal. This statement is valid only for input chains, forward chains, output chains, and user-defined chains that are called only from these chains.

The various ICMP deny variables are intended for use with different table families.

See the Data Types (# Data Types) section above for a description of the types and a list of supported keywords. The default deny value is generally port-unreachable.

Note that in the bridge family, reject statements are only allowed on basechains that hook into input or prerouting.

Counter statement

The counter statement sets the number of packet hits as well as the number of bytes.

counter [ packets number bytes number ]

CONNTRACK statement

You can use the conntrack statement to set the conntrack mark and the conntrack label.

ct {mark | event | label | zone} set value

The ct statement sets the metadata associated with the connection. The zone ID must be assigned before a conntrack search can be performed. That is, this should be done with prerouting and output (if locally generated packets need to be placed in separate zones) and the hook priority is -300.

Conntrack statement type

#Save the packet nfmark to conntrack
ct mark set meta mark

#Set up mapped zones through the interface
table inet raw {
  chain prerouting {
    type filter hook prerouting priority -300;
    ct zone set iif map { "eth1" : 1, "veth1" : 2 }
  }
  chain output {
    type filter hook output priority -300;
    ct zone set oif map { "eth1" : 1, "veth1" : 2 }
  }
}

#Limit events reported by ctnetlink
ct event set new,related,destroy

Meta statement

The meta statement sets the value of the meta expression. The existing metafields are priority, mark, pkttype, nftrace.

meta {mark | priority | pkttype | nftrace} set value

The meta statement sets the metadata associated with the packet.

Meta statement type

Restriction statement

limit rate [over] packet_number / {second | minute | hour | day} [burst packet_number packets]
limit rate [over] byte_number {bytes | kbytes | mbytes} / {second | minute | hour | day | week} [burst byte_number bytes]

The limit statement matches at a limited rate using the token bucket filter. Rules that use this statement will match until this limit is reached. You can use this in combination with a log statement to limit logging. The optional `ʻover`` keyword matches beyond the specified rate.

NAT statement

snat to address [:port] [persistent, random, fully-random]
snat to address - address [:port - port] [persistent, random, fully-random]
dnat to address [:port] [persistent, random, fully-random]
dnat to address [:port - port] [persistent, random, fully-random]
masquerade to [:port] [persistent, random, fully-random]
masquerade to [:port - port] [persistent, random, fully-random]
redirect to [:port] [persistent, random, fully-random]
redirect to [:port - port] [persistent, random, fully-random]

The nat statement is valid only from the nat chain type.

The snat and masquerade statements indicate that the source address of the packet should be changed. snat is only valid for postrouting and input chains, but masquerade is only valid for postrouting. The dnat and redirect statements are valid only in the prerouting and output chains and indicate that the destination address of the packet should be changed. You can also use non-base chains that are called from nat chain type base chains. All future packets on this connection will be dropped and rule evaluation will be aborted.

The masquerade statement is a special form of snat that always uses the IP address of the destination sending interface. This is especially useful for gateways with dynamic (public) IP addresses.

The redirect statement is a special form of dnat that always translates the destination address to the address of the local host. This is useful if you only want to change the destination port for incoming traffic on different interfaces.

Note that every nat statement must have both prerouting and postrouting basechains. Otherwise, packets on the return route will not be recognized by netfilter and no reverse translation will occur.

NAT statement value

NAT statement flag

Use of NAT statements

#A table suitable for all other examples/Create a chain setting
add table nat
add chain nat prerouting { type nat hook prerouting priority 0; }
add chain nat postrouting { type nat hook postrouting priority 100; }

#Address 1 the source address of all packets sent via eth0.2.3.Convert to 4
add rule nat postrouting oif eth0 snat to 1.2.3.4

#Destination address 192 for all traffic coming in via eth0.168.1.Redirect to 120
add rule nat prerouting iif eth0 dnat to 192.168.1.120

#Translate the source address of all packets sent via eth0 to anything
#Locally generated packets are used as a source to reach the same destination
add rule nat postrouting oif eth0 masquerade

#Redirect incoming TCP traffic on port 22 to port 2222
add rule nat prerouting tcp dport 22 redirect to :2222

Flow offload statement

The flow offload statement allows you to select a flow that speeds up the transfer over the Layer 3 network stack bypass. You must specify the name of the flow table to offload this flow.

flow offload @flowtable

Queue statement

This statement uses the nfnetlink_queue handler to pass the packet to user space. Packets are queued, identified by a 16-bit queue number. Userspace can inspect and modify packets as needed. Userspace then needs to drop or reinject the packet from the kernel. See the libnetfilter_queue documentation for more information.

queue [num queue_number] [bypass]
queue [num queue_number_from - queue_number_to] [bypass,fanout]

Queue statement value

Queue statement flag

DUP statement

The dup statement is used to duplicate a packet and send the copy to another destination.

dup to device
dup to address device device

Value of Dup statement

Example of using the dup statement

#IP address 10 with eth0.2.3.Send to 4 machines
ip filter forward dup to 10.2.3.4 device "eth0"

#Copy raw frame to another interface
netdetv ingress dup to "eth0"
dup to "eth0"

#Map to gateway Combine with dst addr
dup to ip daddr map { 192.168.7.1 : "eth0", 192.168.7.2 : "eth1" }

FWD statement

The fwd statement is used to redirect raw packets to another interface. It can only be used with the ingress hooks of the netdev family. Similar to a dup statement, except that no copy is made.

fwd to device

set statement

The set statement is used to dynamically add or update elements in the set from the packet path. set setname must already exist in the specified table. In addition, sets that are dynamically updated from the nftables ruleset must specify both a maximum set size (to prevent running out of memory) and a timeout (to prevent the number of entries in the set from growing indefinitely). .. The set statement creates, for example, a dynamic blacklist.

{add | update} @setname {expression [timeout timeout] [comment string]}

Simple blacklist example

#family"ip"Table"filter"Declare the set bound to. Timeout and size are required to add elements from the packet path.
nft add set ip filter blackhole "{type ipv4_addr; flags timeout; size 65536;}"

#Whitelist the internal interface.
nft add rule ip filter input meta iifname "internal" accept

#Discard packets from blacklisted IP addresses.
nft add rule ip filter input ip saddr @blackhole counter drop

#If there are more than 10 TCP connection requests per second, blacklist the source IP address.
#The entry times out after 1 minute. After that, if the restricted state continues, the entry may be added again.
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

#Check the status of the rate limiting meter.
nft list meter ip filter flood

#Inspect the contents of a black hole:
nft list set ip filter blackhole

#Manually add the two addresses to the set:
nft add element filter blackhole { 10.2.3.4, 10.23.1.42 }

Additional commands

These are some of the additional commands included in nft.

monitor

You can use the monitor command to listen for Netlink events generated by the nf_tables subsystem related to the creation and deletion of objects. When an event occurs, nft prints the monitored event to standard output in either XML, JSON, or native nft format.

To filter events related to concrete objects, use the keywords tables, chains, sets, rules, ```elements, ruleset`` Or use.

Use the keywords new or destroy to filter events related to a specific action.

Press ^ C to end the monitoring operation.

#Listens for all events and outputs a report in native nft format
% nft monitor

#Listen to the added table and output the report in XML format
% nft monitor new tables xml

#Listens for deleted rules and outputs a report in JSON format
% nft monitor destroy rules json

#Waits for both new and destroyed chains in native nft format
% nft monitor chains

#Listens for ruleset events such as tables, chains, rules, sets, counters, quotas in native nft format
% nft monitor ruleset

Error report

When an error is detected, nft indicates the line containing the error, the location of the erroneous part in the input stream, and the caret (^) to mark the erroneous part. I will upload it. If the error is due to a combination of two expressions or statements, the part imposing the violating constraint is marked with a tilde (~).

For errors returned by the kernel nft cannot detect which part of the input is causing the error and the entire command is marked.

Error due to one incorrect expression

<cmdline>:1:19-22: Error: Interface does not exist
filter output oif eth0
                  ^^^^

Error due to invalid combination of two expressions

<cmdline>:1:28-36: Error: Right hand side of relational expression (==) must be constant
filter output tcp dport == tcp dport
                        ~~ ^^^^^^^^^

Error returned by kernel

<cmdline>:0:0-23: Error: Could not process rule: Operation not permitted
filter output oif wlan0
^^^^^^^^^^^^^^^^^^^^^^^

Exit status

If successful, nft exits with status 0. If an unspecified error occurs, it exits with status 1, status 2 is a memory allocation error, and status 3 if the Netlink socket cannot be opened.

Related item

• iptables(8)
• ip6tables(8)
• arptables(8)
• ebtables(8)
• ip(8)
• tc(8)

There is an official wiki at https://wiki.nftables.org.