iptables rules you added on a Linux server work immediately but are gone after a reboot. Where do those rules actually live, how do you make them persist on a Debian/Ubuntu and on a RHEL-family host, and what is most often forgotten?

## Rules are kernel state, not configuration files This is the whole answer in one sentence: `iptables` is a client that programs the running kernel. There is no config file it reads and no file it writes. Everything you add with `-A`, `-I` or `-P` exists in kernel memory, applies instantly, and is gone the moment the machine reboots. Persistence is a separate concern that you have to arrange yourself, and every distribution's mechanism is a wrapper around the same two commands. ## `iptables-save` and `iptables-restore` `iptables-save` prints the current ruleset to standard output in a compact text format: a `*filter` line opening a table, `:CHAIN POLICY [pkts:bytes]` lines recording each built-in chain's default policy, then one `-A` line per rule, then `COMMIT`. Crucially it records **policies as well as rules**, so a saved dump is a complete description of the filter state, not just a list of rules. `iptables-restore` reads that format back. Two properties matter operationally: - **It replaces, it does not merge.** By default, restoring a dump flushes each table that appears in the file and installs the file's contents. Pass `-n` (`--noflush`) if you want the rules added to what is already there instead. Replacement is usually what you want. - **It applies a table atomically.** The whole table is committed in one operation rather than rule by rule, so there is no window in which the chain is half-built and traffic is being evaluated against a nonsense ruleset. Applying a ruleset from a file is therefore safer than replaying a script of individual `iptables` calls. ```bash iptables-save > /etc/iptables/rules.v4 ip6tables-save > /etc/iptables/rules.v6 iptables-restore < /etc/iptables/rules.v4 ``` `iptables-save -c` includes the packet and byte counters in the dump; without it the restored rules start at zero, which is normally what you want. ## Debian and Ubuntu Install `iptables-persistent`. The package installs a `netfilter-persistent` service that runs at boot and restores `/etc/iptables/rules.v4` and `/etc/iptables/rules.v6`. The installer offers to save the current rules for you the first time. Afterwards, `netfilter-persistent save` re-dumps the live ruleset into those two files, and `netfilter-persistent reload` re-applies them. Writing the files directly with `iptables-save` works exactly as well — the service does not care who wrote them. ## The RHEL family Modern RHEL, CentOS Stream, Rocky and Alma ship `firewalld` as the default firewall management layer. If you are managing rules with `iptables` directly on such a host, the persistence package is `iptables-services`, which provides `iptables` and `ip6tables` services that load `/etc/sysconfig/iptables` and `/etc/sysconfig/ip6tables` at boot. You write those files with `iptables-save`; older releases also accept `service iptables save` as a shortcut for the same thing. Running `firewalld` and a hand-managed iptables service at the same time is a recipe for two systems overwriting each other's rules, so pick one. ## What actually gets forgotten **IPv6.** `iptables` and `ip6tables` are two independent rulesets with two independent dumps. A host whose IPv4 rules are saved and restored perfectly can come back from a reboot with a completely open IPv6 stack, and a client that prefers IPv6 will sail straight through. If your service has an AAAA record, this is not theoretical. **Drift between live and saved.** The saved file is a snapshot. Every `iptables` command you run after saving changes the live ruleset and nothing else. The failure mode is nasty because it is delayed: the change works, everyone moves on, and weeks later a reboot quietly reverts a firewall change nobody remembers making. Either re-save immediately after every change, or — much better — treat the file as the source of truth, edit it, and apply it with `iptables-restore`. **Saving a broken state.** `netfilter-persistent save` and `iptables-save` faithfully persist whatever is loaded, including the half-finished ruleset you were experimenting with. Save deliberately, not reflexively. **Other software that installs its own rules at start-up.** Container runtimes and VPN daemons commonly add rules of their own when they start. A blanket restore that flushes the tables can remove those rules from under a service that is already running, and ordering between your restore and their start-up decides who wins. On a host running such software, verify the ruleset after a reboot rather than assuming the file describes what is loaded. ## The habit worth adopting Keep the intended ruleset in a file, under version control, and make the boot-time restore the only thing that installs it. Then "what are this host's firewall rules" is a question you answer by reading a reviewed file, and a reboot is a re-assertion of the intended state rather than a source of surprises.