Firewall Package Installed, Rules Gone After the Reboot

The package installed cleanly, the rules were tested, and after the next reboot the gateway was wide open. Nothing in the transaction failed; the failure was in what was assumed to persist. Installing firewall tooling, deciding which rules should survive and restoring them at the right moment are three separate jobs.

What the symptom actually tells you

A rule set that disappears on reboot has one of three owners: nothing saved it, something else replaced it, or it was restored before the thing it depends on existed. The first two are visible in the configuration; the third only shows up in ordering. That is why a reboot can look like data loss when it is really a sequence problem.

Start by writing down what was true before the reboot: which service held the rules, which file or database it read at start, and whether that source had ever been written. A live rule set that nobody saved is a valid explanation and the most common one.

Do not begin by reinstalling the package.

Read the persistence tool before you use it

The Debian tooling treats persistence as a plugin problem: each plugin knows how to write its own rules, and one wrapper calls them. Its save action stores whatever is loaded at that moment, and its start action loads that snapshot back. Nothing in either action reviews what it is storing.

That is a snapshot, not a review. A leftover allow from a debugging session, a half-finished experiment, or a permissive rule another helper inserted all become permanent alongside the policy you meant to keep. Saving state and approving state are different activities, and only one of them requires judgment. Read the loaded set first, then decide which lines deserve to survive.

Save deliberately, after reading what is loaded.

Decide what should survive

Some rules belong to an interface lifecycle and should disappear with it. Others must outlive the tunnel, and the clearest example is a restriction that forbids client traffic from falling back to the physical interface when the tunnel drops. Those two categories need different restoration triggers, not one shared snapshot.

Write the intended result for three moments: boot, VPN activation and tunnel loss. Then check whether the tool you chose can express each of them. A persistence package that reloads a static snapshot handles the first and may handle neither of the others, because a snapshot has no idea when the tunnel state changed. If it cannot express them, the gap belongs in a different component.

The policy, not the package, decides the answer.

Check the restoration order

Restoring the file is not the same as owning the result. Another manager can replace the rules, an earlier accept can shadow them, or clients can start sending before the restriction lands. Review startup and reconnect behaviour, not just the presence of a saved file.

systemctl status netfilter-persistent
iptables -S

Do not assume that stopping the persistence service is harmless, because the package documents a conditional flush when it stops. Establish the service's actual configuration before using stop or restart as an experiment on a gateway you administer remotely. A console session and a documented rollback are the minimum before that test.

Order is a property of the running system, not of the file on disk.

Accept three separate results

Record the package installation, the loaded rule set and the enforced policy as separate facts. A package name in a support thread answers only the first, and it is the one that rarely matters.

nft list ruleset

Then test a permitted operation and a required denial.

If the denial holds after a reboot and after a tunnel drop, the policy survives. If it holds in only one of those states, you have found the ordering problem rather than fixed it.