Home / Alt manpages / netfilter-persistent(8)

  • netfilter-persistent(8)
  • Admin command
  • linux

Save and Restore Firewall Rules with netfilter-persistent

You will finish with a repeatable way to save the currently loaded firewall rules, restore them after a reboot, and flush them only when you mean to remove them. The examples use netfilter-persistent 1.0.20, installed from the netfilter-persistent package.

Allow about fifteen minutes. You need a shell, the package installed, and a maintenance window if the host is remote or carries live traffic. The commands that change kernel firewall state or write persistent rules need elevated privileges. The read-only checks do not.

Checkpoint

The workflow is save, inspect, start, verify. Stop here if you are trying to remove rules rather than preserve and reload them: flush is a separate, disruptive operation.

1. Check the installed command and configuration

First confirm the binary and package version. This is an ordinary read-only check:

$ command -v netfilter-persistent
/usr/sbin/netfilter-persistent
$ dpkg-query -W -f='${Package} ${Version}\n' netfilter-persistent
netfilter-persistent 1.0.20

The documented interface has four actions: start loads rules, stop handles the stop policy, flush removes rules, and save writes the currently loaded rules to persistent storage. The installed wrapper also accepts reload and restart; both call the plugin start action on this version. Use the documented actions in scripts unless you have checked the wrapper supplied by your distribution.

Read the default configuration before relying on stop:

$ sed -n '1,160p' /etc/default/netfilter-persistent
FLUSH_ON_STOP=0
...

On this installation, FLUSH_ON_STOP=0 means stop warns instead of flushing. A local administrator may have changed that value, and plugins may extend the file, so treat the file as the source of truth.

2. Inspect the rules that are currently loaded

Before saving anything, record what the kernel currently has. These commands only read state:

$ sudo iptables-save
$ sudo ip6tables-save

Both commands print an iptables-save ruleset. The exact chains and rules depend on the host. An empty or very small result is still useful evidence: saving it may replace a more complete rules file. If your firewall is managed by another tool, identify that owner before using this package, because two managers can overwrite each other's rules.

Checkpoint

Keep a copy of the output if the current rules matter. For example, write it to a root-readable temporary file outside the package's persistent directory:

$ sudo sh -c 'iptables-save > /tmp/iptables-current.v4'
$ sudo sh -c 'ip6tables-save > /tmp/iptables-current.v6'

3. Save the loaded rules

Warning

save changes persistent configuration. It does not design a firewall and it does not make the current rules safer. Only run it after checking that the loaded rules are the ones you want at the next start.

$ sudo netfilter-persistent save

The installed iptables plugins save IPv4 rules to /etc/iptables/rules.v4 and IPv6 rules to /etc/iptables/rules.v6, with mode 0640. The package configuration can disable saving for an individual family with IPTABLES_SKIP_SAVE=yes or IP6TABLES_SKIP_SAVE=yes. Check the result without editing it:

$ sudo ls -l /etc/iptables/rules.v4 /etc/iptables/rules.v6
$ sudo iptables-restore --test < /etc/iptables/rules.v4
$ sudo ip6tables-restore --test < /etc/iptables/rules.v6

A successful restore test produces no error and returns status 0. The files are input to the plugins, so preserve them before making manual changes:

$ sudo cp --preserve=all /etc/iptables/rules.v4 /etc/iptables/rules.v4.before-change
$ sudo cp --preserve=all /etc/iptables/rules.v6 /etc/iptables/rules.v6.before-change

4. Load the saved rules deliberately

Warning

start changes the active firewall. On this installation the plugins test each ruleset first, then restore it. A valid test reduces the chance of applying a broken file, but it is not a substitute for an access plan. Keep a local console or out-of-band route available on a remote machine.

$ sudo netfilter-persistent start

The wrapper runs every executable in /usr/share/netfilter-persistent/plugins.d with the start argument. The stock plugins load the IPv4 and IPv6 files when present. Confirm the active state afterwards:

$ sudo iptables-save
$ sudo ip6tables-save

Compare the relevant output with the files you intended to load. A command returning successfully proves that the plugin calls completed; it does not prove that the policy is appropriate for your application or that a remote connection will remain reachable.

5. Understand stop, flush and recovery

stop is not the normal way to clear this firewall. With the default configuration it prints a warning such as Automatic flush disabled; use '/usr/sbin/netfilter-persistent flush' and leaves the rules in place. If an administrator has enabled FLUSH_ON_STOP, however, stop can call the plugins' flush action. Check the configuration before using it.

Destructive action

flush removes the loaded rules, resets built-in policies to ACCEPT, clears counters and deletes user-defined chains in the stock iptables plugins. This can expose services and can interrupt traffic expectations. Do not run it on a remote host without an out-of-band recovery path.

$ sudo netfilter-persistent flush

There is no undo command that reconstructs the previous kernel state. If you saved the intended rules first, reload them:

$ sudo netfilter-persistent start

If the saved files are wrong, restore the backups from step 3 and run the restore tests again before starting. If a load fails, read the plugin error, leave the last known-good backup untouched, and fix the rules file offline. Do not repeatedly flush and start while troubleshooting a remote lockout.

6. Avoid the common traps

  • Saving the wrong state: save records what is loaded now, not what you intended to load later. Inspect first.
  • Checking only IPv4: IPv6 rules have a separate file and plugin. Test both families when IPv6 is enabled.
  • Assuming stop means flush: this installation defaults to FLUSH_ON_STOP=0; another configuration may differ.
  • Adding arbitrary options: the wrapper passes one action to each plugin. Plugin-specific configuration belongs in /etc/default/netfilter-persistent or the plugin's own documented files.
  • Ignoring ownership: Docker, firewalld, nftables compatibility tools and other managers may also alter netfilter state. Establish which tool owns the rules before enabling boot-time loading.

Done means

  • The installed version and /etc/default/netfilter-persistent were checked.
  • The active IPv4 and IPv6 rules were inspected before saving.
  • save completed and both persistent files passed restore tests where present.
  • A backup exists before manual changes or recovery work.
  • start was run only with a tested ruleset and a recovery route.
  • flush was treated as destructive, with a tested reload path available.