nftables rules are ephemeral by default, meaning they vanish when the system restarts unless explicitly saved and reloaded.
Let’s see nftables in action. Imagine a simple setup where we want to allow SSH traffic on port 22 from a specific IP address.
# Create a new table and chain
nft add table ip filter
nft add chain ip filter input { type filter hook input priority 0 \; }
# Add a rule to allow SSH from 192.168.1.100
nft add rule ip filter input ip saddr 192.168.1.100 tcp dport 22 accept
# Verify the rule
nft list ruleset
This output shows our filter table, input chain, and the specific rule allowing SSH. If we reboot now, this rule is gone.
To make these rules persistent, nftables uses a configuration file, typically located at /etc/nftables.conf. This file is a direct representation of the nft list ruleset output.
Here’s what our /etc/nftables.conf might look like after saving the rule above:
table ip filter {
chain input {
type filter hook input priority 0; policy accept;
ip saddr 192.168.1.100 tcp dport 22 accept
}
}
The policy accept on the input chain means that by default, everything is allowed. Our specific rule then selectively denies or allows traffic. In a real-world scenario, you’d likely have a policy drop and then explicitly allow what you need.
The core problem nftables configuration solves is managing the state of the firewall. Without persistence, every system boot would require manually re-applying all firewall rules, which is impractical and error-prone. The configuration file acts as the desired end-state for your firewall.
The key commands for managing this are nft list ruleset (to see the current state) and nft -f <filename> (to apply rules from a file). The nftables service itself, when enabled and started, reads /etc/nftables.conf on boot and applies those rules.
The nftables service management is usually done via systemd.
sudo systemctl enable nftables will ensure it starts on boot.
sudo systemctl start nftables will apply the rules from /etc/nftables.conf immediately.
sudo systemctl status nftables will show if it’s running and if there were any errors loading the rules.
When you save your ruleset using nft list ruleset > /etc/nftables.conf, you are essentially taking a snapshot of the currently active rules and writing them to the file that nftables will read on startup. If you make changes directly with nft add rule or nft delete rule and want them to persist, you must then re-save the ruleset to /etc/nftables.conf.
A common misconception is that simply editing /etc/nftables.conf and restarting the nftables service is enough. While that’s part of it, the nftables service’s primary job is to load the configuration file if it exists and is valid. If you’ve made live changes with nft commands and haven’t updated the file, restarting the service will just revert to the last saved state in the file, losing your live modifications. The safe workflow is: make live changes, verify, then nft list ruleset > /etc/nftables.conf to save them.
The next step after ensuring your rules persist across reboots is understanding how to manage multiple nftables configuration files for different environments or how to integrate nftables with dynamic IP address management.