The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| List the ruleset | sudo nft list ruleset | View examples |
| Show rule handles | sudo nft --handle list ruleset | View examples |
| Back up active rules | sudo nft list ruleset > ./nftables.backup | View examples |
| Validate a file | sudo nft --check --file ./nftables.conf | View examples |
| Load a batch | sudo nft --file ./nftables.conf | View examples |
| Create an inet table | sudo nft add table inet filter | View examples |
| Create an input base chain | sudo nft \
'add chain inet filter input { type filter hook input priority filter; policy drop; }' | View examples |
| Allow established traffic | sudo nft add rule inet filter input ct state \
established,related accept | View examples |
| Allow loopback | sudo nft add rule inet filter input iifname lo accept | View examples |
| Allow TCP service | sudo nft add rule inet filter input tcp dport 22 ct \
state new accept comment 'management SSH' | View examples |
| Create an address set | sudo nft \
'add set inet filter admins { type ipv4_addr; flags interval; }' | View examples |
| Count rule matches | sudo nft add rule inet filter input tcp dport 443 \
counter accept | View examples |
| Monitor traces | sudo nft monitor trace | View examples |
| Monitor ruleset events | sudo nft monitor ruleset | View examples |
nftables is a stateful packet-filtering framework whose rules can immediately disrupt local or remote access. Inspect the complete active ruleset and management path, preserve a verified rollback, validate files before loading, use named tables and comments, and test from a separate session before making changes persistent.
Step by step
Detailed examples
Capture the active policy before touching it
Rules may be managed by a distribution firewall service, container runtime, or configuration system. Record the full ruleset with handles and identify its owner before manual changes. Store backups with restricted permissions because rules can reveal network topology and service exposure.
sudo nft --handle list ruleset
sudo nft list ruleset > ./nftables.backup
sudo systemctl status nftables --no-pagerValidate a complete batch and retain out-of-band recovery
nft -c checks commands without applying them; -f submits a file in one batch so a failing command prevents partial batch application. Semantic mistakes can still pass validation. Keep another administrative session and a timed or console rollback when changing remote ingress.
sudo nft --check --file ./nftables.conf
# Review the exact diff and rollback path before running:
# sudo nft --file ./nftables.confUnderstand hooks, priority, and policy
Tables contain chains; base chains attach to hooks such as input, forward, and output with a type and priority. Regular chains are reached by jump or goto. Multiple base chains may share a hook, so a rule in one table is not the whole policy. inet families can handle IPv4 and IPv6 together.
table inet filter {
chain input {
type filter hook input priority filter; policy drop;
}
chain forward {
type filter hook forward priority filter; policy drop;
}
}Allow return traffic and management before default drop
Connection tracking identifies established and related traffic. Loopback and required management traffic normally need explicit acceptance before a drop policy. Interface names, address families, service ports, and source restrictions must reflect the real host; test both IPv4 and IPv6.
ct state invalid drop
ct state established,related accept
iifname "lo" accept
ip saddr 192.0.2.0/24 tcp dport 22 ct state new accept comment "management SSH"
tcp dport 443 ct state new counter acceptUse sets for changing membership and counters for evidence
Sets keep address or port membership separate from rule logic and can support intervals and timeouts. Named counters provide reusable telemetry; anonymous counters stay with one rule. Counter hits show matching traffic, not whether an application completed successfully.
set admins {
type ipv4_addr
flags interval
elements = { 192.0.2.0/24, 198.51.100.8 }
}
ip saddr @admins tcp dport 22 counter acceptTrace narrowly and persist through one owner
Tracing requires a rule that sets nftrace, then nft monitor trace observes matching traversal; broad tracing can be noisy. Runtime changes vanish after reboot unless the system's nftables configuration service saves and loads them. Do not let two firewall managers overwrite each other.
sudo nft monitor ruleset
# In a separate diagnostic workflow, trace only a narrowly matched packet set:
# sudo nft monitor traceSources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
Help us improve
Found a typo or missing example?
Tell us what would make this cheat sheet clearer, more complete, or more useful.