nftables Cheat Sheet

Listing Rules

Everything here needs root. nft prints nothing at all when a table does not exist, which usually means the firewall is empty rather than broken.

From iptables

Most people land here with an iptables ruleset already running. iptables-translate prints the nft equivalent of any iptables command without touching the firewall.

Paste a ruleset into the iptables to nftables converter for the same job in a browser, or the firewall rule generator to write one rule for nft, iptables, UFW, and firewalld at once.

The full iptables side of the mapping is on the iptables cheat sheet.

Tables and Chains

nftables ships with nothing: no filter table, no INPUT chain. You create what you need. The inet family covers IPv4 and IPv6 in one place and is the right default.

A chain only sees traffic if it is a base chain, meaning it declares a type, a hook, and a priority. The shell eats {, }, and ;, so quote the block.

sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0; policy accept; }'
sudo nft add chain inet filter forward '{ type filter hook forward priority 0; policy drop; }'
sudo nft add chain inet filter output '{ type filter hook output priority 0; policy accept; }'

Chain types are filter, nat, and route. Priority is a number, low first, and named values read better: raw (-300), mangle (-150), dstnat (-100), filter (0), srcnat (100). Two base chains on the same hook both run, in priority order.

SSH Lockout

A base input chain with policy drop and no rules kills the session you are typing in, not just the next one, because nftables judges every packet including the ones carrying your keystrokes. Build the allow rules first and set the policy last.

sudo nft add table inet filter
sudo nft add chain inet filter input '{ type filter hook input priority 0; policy accept; }'
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input ct state invalid drop
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 accept
# only now, once port 22 is open:
sudo nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'

Cancel the deadman switch once the new ruleset works: systemctl stop run-r*.timer, or list the pending jobs with systemctl list-timers. If SSH listens somewhere other than 22, open that port instead, and check with the SSH port checker from outside the box. The SSH cheat sheet covers the client side of a connection that will not come back.

Adding Rules

add appends to the end of a chain, insert puts the rule at the top. Order matters: the first rule with a verdict wins, so a drop above an accept is the end of the story.

Rule Syntax

A rule is a list of matches followed by a verdict. Everything before the verdict has to be true for the verdict to apply.

Variables keep a file readable. define wan = "eth0" at the top, then oifname $wan in the rules.

Deleting and Flushing

There are no rule numbers. Deletion works by handle, and handles only appear with -a, which is where this stops being obvious.

Handles are assigned in order but are not reused and do not survive a reload, so list them again after every nft -f.

Sets and Maps

Sets replace ipset. A named set is part of the ruleset, so it saves and reloads with everything else, and lookups stay fast as it grows.

sudo nft add set inet filter blocklist '{ type ipv4_addr; flags interval; }'
sudo nft add element inet filter blocklist '{ 203.0.113.0/24, 198.51.100.7 }'
sudo nft add rule inet filter input ip saddr @blocklist drop

A map pairs a key with a value, which is how you write a port forwarding table in one rule:

sudo nft add map ip nat porthost '{ type inet_service : ipv4_addr; }'
sudo nft add element ip nat porthost '{ 80 : 10.0.0.5, 8443 : 10.0.0.6 }'
sudo nft add rule ip nat prerouting dnat to tcp dport map @porthost

NAT and Port Forwarding

NAT needs its own table with nat type chains; a filter chain cannot rewrite addresses. Forwarding between interfaces also needs net.ipv4.ip_forward=1 and a forward chain that accepts the traffic.

sudo nft add table ip nat
sudo nft add chain ip nat prerouting '{ type nat hook prerouting priority dstnat; }'
sudo nft add chain ip nat postrouting '{ type nat hook postrouting priority srcnat; }'
sudo nft add rule ip nat postrouting oifname "eth0" masquerade
sudo nft add rule ip nat prerouting iifname "eth0" tcp dport 8080 dnat to 10.0.0.5:80

A dnat rule that does nothing is usually a forward chain with policy drop and no matching accept, or ip_forward left at 0. Traffic from the same machine does not pass through prerouting, so a local test of a port forward always fails; test from another host, or with the SSH port checker.

Rate Limiting

limit matches while traffic is under the rate; limit rate over matches once it goes above. Put the verdict that suits the one you picked.

A plain limit counts every packet together, so one noisy address starves everyone. For a per-address limit, use a dynamic set:

sudo nft add set inet filter ssh_meter '{ type ipv4_addr; flags dynamic; timeout 1m; }'
sudo nft add rule inet filter input tcp dport 22 ct state new \
  add @ssh_meter { ip saddr limit rate 3/minute } accept

Each source address gets its own counter. Over the limit the statement stops matching, so the packet falls through to whatever comes next, which should be a drop rule. For a single server, ufw limit 22/tcp does the same thing in one line; see the UFW cheat sheet.

Counters and Logging

Unlike iptables, counters are off unless you ask for them, which is why an nftables ruleset is cheaper to evaluate.

Logging happens where the rule sits, so a log rule at the bottom of a policy drop chain shows you exactly what the firewall is turning away. journalctl has the rest of the reading options.

nftables.conf

One file holds the whole ruleset. flush ruleset on the first line makes loading it idempotent: the file replaces what is running instead of adding to it.

#!/usr/sbin/nft -f

flush ruleset

define wan = "eth0"
define admin = { 203.0.113.10, 198.51.100.0/24 }

table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;

		ct state established,related accept
		ct state invalid drop
		iif lo accept

		ip protocol icmp accept
		ip6 nexthdr icmpv6 accept

		ip saddr $admin tcp dport 22 accept
		tcp dport { 80, 443 } accept

		limit rate 5/minute log prefix "nft-input-drop " counter
	}

	chain forward {
		type filter hook forward priority filter; policy drop;
	}

	chain output {
		type filter hook output priority filter; policy accept;
	}
}

Persist and Reload

Rules added with nft add are live immediately and gone at the next reboot. Nothing writes them to disk for you.

Saving and enabling, in full:

sudo sh -c 'echo "flush ruleset" > /etc/nftables.conf && nft -s list ruleset >> /etc/nftables.conf'
sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables

nft -f is atomic: the whole file applies or none of it does. A reload never leaves the firewall half configured, which is the main reason to edit the file rather than type rules one at a time.

Syntax Check

-c parses and checks without applying, so a broken file never reaches the kernel. Run it before every reload.

An error names the file, line, and column, with a caret under the token it choked on:

/etc/nftables.conf:14:17-20: Error: syntax error, unexpected string
		tcp dport 80 ACCEPT
		             ^^^^^^

The usual causes: iptables words in an nft file (-A, -j ACCEPT, uppercase verdicts), unquoted {, }, or ; on a shell command line, a base chain missing its type ... hook ... priority line, a set used before it is declared, and nft reading a file that was written for iptables-restore.

nftables vs iptables

Existing iptables scripts keep working through iptables-nft, so there is no rush. New rulesets are worth writing in native nft syntax.

Gotchas

• A base chain with policy drop and no rules drops the packets carrying your SSH session, immediately. Add ct state established,related accept and the port 22 rule before you set the policy.
• nft flush ruleset deletes the tables, so the policies go with them and the box ends up wide open. That is the opposite of the iptables trap, where flushing with a DROP policy locks you out. Both are worth a deadman switch.
• The shell, not nft, is what rejects { type filter hook input priority 0; policy drop; }. Wrap the braces in single quotes.
• Handles are not line numbers. They do not survive a reload, so re-run nft -a list ruleset after every nft -f before deleting anything.
• A rule added with nft add is not in /etc/nftables.conf, and a rule written in that file is not live. Nothing syncs them.
• iif/oif match the interface index and go stale when a device is recreated, which happens with VPN and container interfaces. Use iifname/oifname unless you have measured that you need the speed.
• Docker writes its own rules and publishes container ports through the forward path, so a container with -p 8080:80 is reachable even when your input chain says otherwise. Bind it to 127.0.0.1 and put a reverse proxy in front.
• Two base chains on the same hook both run. If a rule seems to be ignored, look for another table hooking the same place at a lower priority, including the tables iptables-nft and firewalld create.
• nft list ruleset shows nothing when there are no tables. That is an open firewall, not a broken command.