Run iptables-nft Safely and See the nftables Behind It

The commands look like classic iptables, but iptables-nft quietly writes every change into the kernel's nftables engine instead. You will identify the active firewall backend, inspect the rules it manages, save a rollback copy, and see how the familiar iptables syntax actually alters the nftables ruleset underneath. The commands apply to the IPv4, IPv6 and bridge-family variants, with examples centred on IPv4.

This guide describes the installed iptables package, version 1.8.10-3ubuntu2, reporting iptables v1.8.10 (nf_tables) on this host.

Safety boundary: firewall commands can cut off your SSH session or change traffic immediately. Work from a console or an existing maintenance window, save the current rules first, and keep a tested recovery path handy. The read-only version checks do not need sudo; anything that reads or changes the kernel ruleset usually does.

1. Confirm that you are using the nftables backend

Start with the executable and its version. Do not infer the backend from the command name alone: a system can have both legacy and nft variants installed, and a bare iptables command may be routed by alternatives or a symlink to either:

$ command -v iptables-nft
/usr/sbin/iptables-nft
$ iptables-nft --version
iptables v1.8.10 (nf_tables)
$ dpkg-query -W -f='${Package} ${Version}\n' iptables
iptables 1.8.10-3ubuntu2

The (nf_tables) suffix is what actually matters here. This tool speaks libxtables command syntax but sends changes through the kernel's nf_tables subsystem. The matching commands are ip6tables-nft for IPv6, ebtables-nft for bridge filtering, and arptables-nft where that is installed. Save and restore use the same family naming.

Checkpoint: if the version says legacy, stop. Do not mix legacy and nft commands while chasing a missing rule. Check command -v, your alternatives configuration, and the exact executable a service or provisioning script actually calls.

2. Inspect the current rules without guessing

List the IPv4 rules with the familiar syntax:

$ sudo iptables-nft -L -n -v --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in  out  source        destination
...

Output depends entirely on the host, so treat the lines above as only the shape to expect. -n skips reverse DNS lookups, -v adds counters and interfaces, and --line-numbers makes later rule references easier to check. Listing is not always purely observational: the installed manual warns that on a fresh machine, the first list operation can itself create the base nf_tables tables and chains. Treat that as a small state change, and note what was present beforehand.

Now inspect the same backend with the native nftables command:

$ sudo nft list ruleset
table ip filter {
        chain INPUT {
                type filter hook input priority 0; policy accept;
        }
        ...
}

The two views should describe the same relevant rules. The nftables view is authoritative for tables, chains, hooks, policies and anything created by other nftables tooling. A first list on an empty system commonly creates ip, ip6, bridge and arp filter skeletons for the requested families, so do not mistake an empty policy for a production ruleset.

3. Save a recovery copy before changing anything

Save the current IPv4 rules to a new file. The redirection target is created by your shell, so pick a path you will not accidentally overwrite later:

$ sudo sh -c 'iptables-nft-save > /root/iptables-nft-2026-09-28.rules'
$ sudo test -s /root/iptables-nft-2026-09-28.rules && echo 'backup written'
backup written

Use matching commands for other families that are in scope:

$ sudo sh -c 'ip6tables-nft-save > /root/ip6tables-nft-2026-09-28.rules'
$ sudo sh -c 'ebtables-nft-save > /root/ebtables-nft-2026-09-28.rules'

Keep the backup until the replacement rules have been tested. It contains firewall policy and may reveal network details, so protect it like sensitive system data. A backup is no guarantee a remote connection survives a bad change either way: you still need console access or an out-of-band recovery path.

4. Make one deliberate rule change

Use the normal iptables syntax, but read the effect before pressing enter. This example permits new SSH connections from the documentation-only network 192.0.2.0/24 to the input chain:

$ sudo iptables-nft -A INPUT -p tcp --dport 22 -s 192.0.2.0/24 -m conntrack --ctstate NEW -j ACCEPT

This is a real change, not a harmless demonstration. Swap in a source network you actually control, and only run it once the chain order and existing policy make the result safe. An appended rule is evaluated after whatever is already in the chain, so an earlier drop can still win. Adding and deleting rules through this backend is atomic, unlike the legacy read, modify and reload dance.

Check the result immediately, in both syntaxes:

$ sudo iptables-nft -L INPUT -n -v --line-numbers
$ sudo nft list ruleset
$ sudo xtables-monitor --event

The monitor is useful while another terminal makes changes, but it just waits for events. Press Ctrl-C once you have seen the change land. For packet-traversal tracing with -j TRACE, the manual points you to xtables-monitor in trace mode instead of the old legacy workflow.

5. Undo the example precisely

Delete the rule using the same specification, then verify it is gone. This beats relying on a line number that can shift after another edit:

$ sudo iptables-nft -D INPUT -p tcp --dport 22 -s 192.0.2.0/24 -m conntrack --ctstate NEW -j ACCEPT
$ sudo iptables-nft -C INPUT -p tcp --dport 22 -s 192.0.2.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables v1.8.10 (nf_tables): Bad rule (does a matching rule exist in that chain?).
$ sudo iptables-nft -L INPUT -n --line-numbers

The final check should show no matching rule. The failed -C is expected after deletion, though its exact diagnostic text varies by release. If you made several changes, restore only during a controlled window, because a restore can replace the active policy and end connections outright:

$ sudo iptables-nft-restore /root/iptables-nft-2026-09-28.rules
$ sudo iptables-nft -L -n -v --line-numbers

Restore the matching family with ip6tables-nft-restore or ebtables-nft-restore. Never feed an IPv4 save file to an IPv6 or bridge restore command.

6. Migrate legacy rules with a checkpoint

The nft variants can read the native iptables syntax while storing the result in nf_tables. For a legacy IPv4 ruleset, capture the legacy source and read it first:

$ sudo iptables-legacy-save > /root/legacy-iptables.rules
$ sudo less /root/legacy-iptables.rules

That file becomes the input to the nft backend:

$ sudo iptables-nft-restore /root/legacy-iptables.rules
$ sudo iptables-nft -L -n -v --line-numbers
$ sudo nft list ruleset

Run the migration only after checking for unsupported matches and targets. The installed manual specifically lists the CLUSTERIP target as unsupported and recommends a Linux kernel of at least 4.17. A successful restore does not prove every intended packet path behaves the same, so test allowed, rejected and established traffic from a separate session.

If your actual goal is a native nftables ruleset rather than continued xtables syntax, use the project's translation tools and review their output before loading it. The official migration documentation covers iptables-translate and iptables-restore-translate; translation is a review step, not automatic proof of policy equivalence.

Done means