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

You will restore a saved ARP ruleset through the nftables-backed arptables-nft interface, check that the expected rules are present, and keep a rollback file. The installed command comes from iptables 1.8.10-3ubuntu2. Allow about 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 its rules from standard input or from the first file argument. It flushes the existing contents of the relevant ARP table before loading the replacement, so this is a state-changing and potentially service-disrupting operation. Do not test it on a production host without a console or another recovery route.

1. Check the installed nft-backed commands

First confirm that the command names resolve to the binaries you expect. These checks only read local state and do not need 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 name matters. This guide is about the xtables command using the nf_tables kernel API, not a legacy ARP-table backend. The companion arptables-nft command manages the single kernel table named filter, which has the built-in INPUT and OUTPUT chains described by the local manual.

2. Save the live rules before changing them

Use the matching save command to create a rollback file. The command needs root to read the kernel ruleset; the destination below is a temporary file, so adjust it to a protected path if the rules are 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. The file may contain the current policies, user-defined chains and rules, so keep it intact. Do not edit this backup in place. If the save command reports a permission error, stop here and fix the privilege or kernel-interface problem before attempting a restore.

3. Inspect the replacement file

Choose an existing rules file produced by arptables-nft-save, or prepare one from that format under change control. Inspect it as an ordinary user if it is readable, or use 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. The file is configuration data, not a shell script: do not execute it, source it, or substitute untrusted text into a shell command. Check especially for DROP policies and rules that match your management traffic. ARP rules can affect address resolution, so a syntactically valid file can still disconnect a host.

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

4. Restore from the file

When the backup and replacement have 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

An exit status of zero means the command accepted and applied the input. It does not prove that the rules express your intended security policy. A non-zero status means you should treat the change as failed and inspect the diagnostic before retrying. Do not repeatedly rerun an uncertain file against a live host without checking the current state.

The same input can be supplied on standard input:

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

Use one method at a time. Shell redirection happens before sudo, so it is the restore process, not the shell, that must have permission to read the file. If the file is protected and the command reports that it cannot open it, either grant the command access through your normal file permissions or use a controlled root-readable location. Do not make a private rules file world-readable just to get past the error.

5. Verify the loaded rules

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

$ sudo arptables-nft -L

Compare the output with the reviewed input. Check the chain policies, rule order, match values and targets. The local manual says that a matching rule selects a target and that processing otherwise continues through the ordered chain. Do not rely on a single rule being present if an earlier rule can match first.

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

$ sudo nft list table arp filter

The exact formatting varies with the nftables version, but the table should be the arp family and the chain and policy structure should correspond to the restored ARP rules. If either listing differs from the reviewed file, stop traffic tests and use the saved backup for recovery.

6. Roll back a bad restore

Rollback is another restore, so it also flushes the current ARP 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

If the host is already unreachable, use the console, out-of-band management or a pre-arranged recovery shell. Do not assume that closing the terminal undoes the change. The rules live in the kernel-backed nftables state until another administrative operation replaces or removes them.

When the new policy is confirmed, move the backup into your protected change archive or remove the temporary copy deliberately. Removing the file is not required for the rules to remain active, and deleting the 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 making a backup and recovery pair.
• Wrong input: an ARP rules file is not interchangeable with an IPv4 or IPv6 iptables dump. Confirm the producer and consumer before using redirection.
• Forgotten flush: restore replaces the existing ARP table contents. A failed or incomplete change can remove working rules, which is why the pre-change save is mandatory.
• Lost status: capture $? immediately. Running sed, nft or another command first reports that later command's status instead.
• Overconfident verification: a zero exit status and a plausible listing do not prove that the intended ARP traffic is safe. Review ordering and test the actual network path.