Restore nft-Based ARP Rules Safely with arptables-nft-restore

A firewall rollback goes wrong at 2am without a tested backup, and arptables-nft-restore reloads a saved ARP ruleset from exactly that kind of file. You will restore a saved ruleset through the nftables-backed interface, check the expected rules are actually present, and keep a rollback copy throughout. The command comes from iptables 1.8.10-3ubuntu2. Allow fifteen minutes, plus a maintenance window if the rules protect a busy host.

You need a root-capable shell, the iptables package, and a rules file readable by root. The command reads rules from standard input or the first file argument, and it flushes the existing contents of the relevant ARP table before loading the replacement. That makes it a state-changing, potentially service-disrupting operation: never test it on production without a console or another recovery route ready.

1. Check the installed nft-backed commands

Confirm the command names resolve to the binaries you expect. These checks only read local state and need no elevated privileges:

$ command -v arptables-nft-restore
/usr/sbin/arptables-nft-restore
$ command -v arptables-nft-save
/usr/sbin/arptables-nft-save
$ dpkg-query -W -f='${Package} ${Version}\n' iptables
iptables 1.8.10-3ubuntu2

The -nft in the name matters: this is the xtables command using the nf_tables kernel API, not a legacy ARP-table backend. The companion arptables-nft manages the single kernel table named filter, with the built-in INPUT and OUTPUT chains the local manual describes.

2. Save the live rules before changing anything

Use the matching save command to create a rollback file. It needs root to read the kernel ruleset; the destination below is a temporary file, so use a protected path if this is part of a real change record:

$ sudo arptables-nft-save > /tmp/arptables-before-restore.rules
$ sudo test -s /tmp/arptables-before-restore.rules
$ sudo sed -n '1,120p' /tmp/arptables-before-restore.rules

arptables-nft-save writes an easily parseable ruleset to standard output, including current policies, user-defined chains and rules, so keep this file intact and never edit it in place. If the save command errors on permissions, stop and fix that before you attempt any restore.

3. Inspect the replacement file

Use an existing rules file produced by arptables-nft-save, or prepare one in that format under change control. Read it as an ordinary user if it is readable, or with root for a protected file:

$ sudo sed -n '1,160p' /path/to/arptables-restore.rules

Look for the table declaration, chain declarations, rule lines and the final commit marker. This is configuration data, not a shell script: never execute it, source it, or substitute untrusted text into a shell command with it. Check especially for DROP policies and rules matching your own management traffic; a syntactically valid file can still cut you off.

The safest replacement is a file previously produced by the matching nft-backed save command on a comparable machine. Never feed this tool an IPv4 iptables-save file. It accepts ARP table rules and the same rule specifications documented for arptables-nft: source or destination IP, MAC address, interface, opcode and a target such as ACCEPT or DROP.

4. Restore from the file

Once the backup and replacement have both passed review, run the restore with elevated privileges. The file argument is the first positional argument:

$ sudo arptables-nft-restore /path/to/arptables-restore.rules
$ printf 'restore exit status: %s\n' "$?"
restore exit status: 0

Exit status zero means the command accepted and applied the input, not that the rules express your intended security policy. A non-zero status means treat the change as failed and inspect the diagnostic before retrying; do not rerun an uncertain file against a live host repeatedly without checking current state.

The same input can arrive on standard input instead:

$ sudo arptables-nft-restore < /path/to/arptables-restore.rules

Pick one method at a time. Shell redirection happens before sudo runs, so it is the restore process, not the shell, that needs permission to read the file. If it is protected and the command cannot open it, grant access through normal file permissions or a controlled root-readable location, never by making a private rules file world-readable.

5. Verify the loaded rules

List the nft-backed ARP table immediately after a successful restore:

$ sudo arptables-nft -L

Compare the output against the reviewed input: chain policies, rule order, match values and targets. The local manual says a matching rule selects a target and processing otherwise continues down the ordered chain, so never assume one rule is safe just because it looks present; an earlier rule may match first.

For an independent view, ask nft to show the ARP family if it is installed:

$ sudo nft list table arp filter

Formatting varies by nftables version, but the table should be the arp family with a chain and policy structure matching the restored rules. If either listing disagrees with the reviewed file, stop traffic tests and reach for the saved backup.

6. Roll back a bad restore

Rollback is just another restore, so it also flushes the current table. Keep the original backup until the replacement has survived your checks and a normal traffic test:

$ sudo arptables-nft-restore /tmp/arptables-before-restore.rules
$ sudo arptables-nft -L

Once the new policy is confirmed, move the backup into your protected change archive or delete the temporary copy deliberately. Removing it is not required for the rules to stay active, and losing your only rollback copy makes the next incident harder to recover from.

Common failure traps

• Wrong backend. arptables-nft-restore writes through nf_tables. Keep save and restore on the same nft-backed family when pairing a backup with a recovery.
• Wrong input. An ARP rules file is not interchangeable with an IPv4 or IPv6 iptables dump. Confirm producer and consumer before redirecting one into the other.
• Forgotten flush. Restore replaces the existing table contents outright. A failed or incomplete change can remove working rules, which is exactly why the pre-change save is mandatory.
• Lost status. Capture $? immediately. Run sed, nft or anything else first and you have lost the restore's own status.
• Overconfident verification. A zero exit status and a plausible listing do not prove the intended ARP traffic is safe. Review ordering and test the actual network path.