Matching packet metainformation

The meta selectors allows you to match -- and in some cases, set -- packet metainformation. That is, information the local host has about the packet (such as how / when it was received) that is not necessarily carried in the packet itself.

Matching by interface

The following meta selectors match packets based on incoming or outgoing interfaces:

meta Interface Selectors
Keyword	Settable	Description	Data Type	Notes
iif		input interface index	iface_index	Faster than iifname as it only has to compare a 32-bit unsigned integer instead of a string. The interface index is dynamically allocated, so don't use this for interfaces that are dynamically created and destroyed, eg. ppp0.
iifname		input interface name	ifname
iifgroup		input interface group	devgroup
iiftype		input interface type	iface_type
ibrname		input bridge interface name	ifname
oif		output interface index	iface_index	Faster than oifname as it only has to compare a 32-bit unsigned integer instead of a string. The interface index is dynamically allocated, so don't use this for interfaces that are dynamically created and destroyed, eg. ppp0.
oifname		output interface name	ifname
oifgroup		output interface group	devgroup
oiftype		output interface type	iface_type
obrname		output bridge interface name	ifname

An example rule that uses iifname to accept all traffic entering the loopback pseudodevice lo:

% nft add rule filter input meta iifname lo accept

Matching by packet mark

You can match packets whose mark is 123 with the following rule:

nft add rule filter output meta mark 123 counter

Matching by socket UID

You can use your user name to match traffic, eg.

% nft add rule filter output meta skuid pablo counter

Or the 32-bits unsigned integer (UID) in case there is no entry in /etc/passwd for a given user.

% nft add rule filter output meta skuid 1000 counter

Let's just generate some HTTP traffic to test this rule:

% wget --spider http://www.google.com

Then, if you check the counters, you can verify that the packets are matching that rule.

% nft list table filter
table ip filter {
        chain output {
                 type filter hook output priority 0;
                 skuid pablo counter packets 7 bytes 510
        }

        chain input {
                 type filter hook input priority 0;
        }
}

Important: Beware if you test this with ping, it is usually installed with suid so that traffic will match the root user (uid=0).

Matching by tc priority

• Since nftables v0.7 you can match the packet priority, the tc classid:

% nft add rule filter forward meta priority abcd:1234

• Packet without set priority can be matched using meta priority none

% nft add rule filter forward meta priority none

Matching by miscellaneous selectors

In addition to the meta selectors in the preceding subsections, the following meta selectors are available:

meta Miscellaneous Selectors
Keyword	Settable	Description	Data Type	Notes
mark	Y	packet mark	mark
skuid		UID associated with originating socket	uid
skgid		GID associated with originating socket	gid
nftrace	Y	nftrace debugging bit
rtclassid		routing realm	realm
ibriport		input bridge port
obriport		output bridge port
pkttype	Y	packet type	pkt_type
cpu		CPU number processing the packet	integer (32 bit)
cgroup		control group ID	integer (32 bit)
ipsec		true if packet was ipsec encrypted	boolean (1 bit)
time		timestamp of packet reception	integer (32 bit) or string
day		day of week	integer (32 bit) or string
hour		hour of day	string
length		packet length in bytes	integer (32 bit)
protocol		packet protocol / EtherType protocol value	ether_type	as in skb->protocol
nfproto		netfilter packet protocol family	integer (32 bit)	like ipv4, ipv6, etc...; useful only in inet table
l4proto		layer 4 protocol	integer (8 bit)	like tcp, udp, etc...; skips ipv6 extension headers
priority	Y	tc packet priority	tc_handle
random		pseudo-random number	integer (32 bit)
secmark	Y	packet secmark
ibrvproto		bridge protocol
ibrpvid		bridge pvid