iptables-save turns the live kernel ruleset into a readable, restorable file, and getting counters and tables right up front saves guesswork later. Allow about ten minutes for a one-off backup, or longer for several hosts. The examples use iptables 1.8.10, from Ubuntu package version 1.8.10-3ubuntu2.
You need the iptables package and access to the host whose rules you are inspecting. Reading the kernel rule set normally needs elevated privileges. The command itself does not edit rules, but the file-writing examples can overwrite an existing destination if you pick one carelessly.
Check which binaries will run before saving anything. The package provides separate commands for IPv4 and IPv6:
$ command -v iptables-save
/usr/sbin/iptables-save
$ command -v ip6tables-save
/usr/sbin/ip6tables-save
$ dpkg-query -W -f='${Package} ${Version}\n' iptables
iptables 1.8.10-3ubuntu2The installed manual describes both commands together. iptables-save dumps the IPv4 tables; ip6tables-save dumps the IPv6 tables. They share the same options, but they are not interchangeable backups.
Checkpoint: make sure you know whether the rules you need are IPv4, IPv6, or both. A successful IPv4 dump says nothing about IPv6 policy.
Run a read-only dump to standard output first, using sudo if the current account cannot read the kernel rule set:
$ sudo iptables-save
# Generated by iptables-save v1.8.10 on ...
*filter
...
COMMITThe exact output depends on the active tables and rules. It is a structured restore format, not a report meant for casual reading. On a host where the command lacks permission, the installed binary reports an error such as Could not fetch rule set generation id: Permission denied and exits non-zero. Add sudo or use an account with the required capability; do not treat an empty or failed unprivileged command as proof the firewall is empty.
This command does not alter the rule set, but it can reveal security-sensitive network policy, so do not paste its output into public tickets or shell history where that is inappropriate.
Choose a destination that is not already a valuable backup. The -f option writes the dump to that filename instead of standard output:
$ sudo iptables-save -f /root/iptables-$(date +%F).rules
$ sudo test -s /root/iptables-$(date +%F).rules
$ sudo head -n 8 /root/iptables-$(date +%F).rules
# Generated by iptables-save v1.8.10 on ...
*filter
:INPUT ACCEPT [0:0]
...Do not run that exact example twice if you need to keep the first capture: the date-based name is the same all day. For a repeat capture, use a more specific name such as /root/iptables-before-change.rules, or include a time in the filename.
Warning: selecting an existing filename can replace its contents. If the destination matters, copy it aside first or pick a new name. The firewall rules themselves stay unchanged by iptables-save; only the output file is at risk.
Checkpoint: verify both the exit status and the file, not just the absence of an error message:
$ sudo test -s /root/iptables-2026-09-24.rules
$ echo $?
0Repeat the capture with ip6tables-save and a clearly labelled file:
$ sudo ip6tables-save -f /root/ip6tables-2026-09-24.rules
$ sudo test -s /root/ip6tables-2026-09-24.rules
Keep the files separate. The aliases in the manual describe related commands, not one combined IPv4 and IPv6 output format. If you are documenting a host, record which file came from which command.
By default, the dump leaves out the current packet and byte counter values. Add -c, or --counters, when those values matter for incident review, traffic accounting, or comparing a before-and-after change:
$ sudo iptables-save --counters -f /root/iptables-with-counters.rules
$ sudo grep '^:' /root/iptables-with-counters.rules
:INPUT ACCEPT [123:45678]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [789:13579]Counter values change as traffic passes through the rules: they are a snapshot, not a permanent property of the rule definition. Leave -c out for a cleaner policy backup meant for comparison or transfer. Include it when the observed counts are part of the evidence you need to keep.
Without -t, the command includes all available tables and does not load extra table modules. Use -t when you deliberately want one table, for example the filter table:
$ sudo iptables-save --table filter -f /root/iptables-filter.rules
$ sudo grep '^\*' /root/iptables-filter.rules
*filterThe table name is not a free-form label: it must be a table available to the kernel and command backend. With -t, iptables-save may try to load the appropriate module if automatic module loading is configured; without it, no module loading happens, so a table whose module is not loaded may not appear in an all-table dump.
This is a common review trap: an all-table capture is not automatically evidence that every possible table exists on the host. If a particular table matters, request it explicitly and check the command's exit status.
Inspect a saved file as text before relying on it. Look for the table markers, chain policies and rule lines:
$ sudo sed -n '1,80p' /root/iptables-2026-09-24.rules
$ sudo grep -E '^(\*|:|-[A-Za-z])' /root/iptables-2026-09-24.rulesA normal dump contains table sections beginning with lines such as *filter, chain definitions beginning with :, rule lines beginning with -A, and COMMIT at the end of each section. The exact chains and extensions vary with the host. Do not edit a backup in place while investigating it; make a copy if you need to experiment with a restore file.
iptables-save only reads and serialises the current state. It does not restore a file, validate that a future kernel supports every extension, or make the backup persistent across reboot. Restoring rules is a separate, disruptive operation with its own maintenance-window decision and rollback plan.
iptables-save and IPv6 with ip6tables-save when both matter.