Control ARP Traffic Safely with arptables-nft

You will inspect the nft-based ARP filter, add one narrowly scoped rule, confirm its position and remove it again. Allow about fifteen minutes. The examples use the installed arptables-nft from iptables 1.8.10-3ubuntu2. You need root privileges for table changes and usually for listing the kernel ruleset.

ARP rules affect address resolution on a local network. A mistaken DROP rule can make a host or neighbour unreachable, so use a maintenance window for production changes and keep a second administrative path available.

1. Check the installed command

Start with read-only checks. The command is the nftables-backed implementation of arptables, not a separate nftables rule editor:

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

The installed program reports one ARP table, named filter. The -t filter argument is optional, but if you use -t it must be the first argument. The built-in chains are INPUT for frames destined for this host and OUTPUT for locally generated frames.

2. List the current rules

Listing does not change rules, but reading the kernel ruleset can require elevated privileges. Ask for line numbers so a later deletion can refer to a stable-looking position during this inspection:

$ sudo arptables-nft -t filter -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     0x800 --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Your output may have no rules, different policies or different columns. The exact formatting is version dependent. On an unprivileged shell, this installed command returns an error such as Could not fetch rule set generation id: Permission denied; that is a privilege problem, not proof that the table is empty.

There is no FORWARD chain in this nft-based arptables implementation. ARP forwarding is associated with Linux bridges; filtering that traffic belongs with the bridge filtering tools described by the local manual, not an invented arptables chain.

3. Add a harmless test rule

For a controlled smoke test, append a rule that matches one documentation-only source address on one interface and continues evaluation. Replace eth0 only after checking the real interface name with ip link:

$ ip link show
$ sudo arptables-nft -t filter -A INPUT -i eth0 -s 192.0.2.10 -j CONTINUE

192.0.2.10 is reserved for documentation and should not be a real peer address. CONTINUE does not accept or drop the frame; it tells the chain to examine the next rule. This makes the test less disruptive, but it still changes the live kernel ruleset and may increment a counter if matching traffic exists.

Checkpoint: list the chain again and verify that the rule appears at the expected position:

$ sudo arptables-nft -t filter -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num  target    prot opt source       destination
1    CONTINUE  0x800 --  192.0.2.10  0.0.0.0/0

Do not treat a displayed rule as proof that it matches traffic. Its interface, addresses, opcode and protocol type must describe the ARP frames you actually intend to inspect.

4. Narrow a rule with ARP fields

Rule specifications can match source or destination IP addresses, source or destination MAC addresses, the input or output interface, hardware length, opcode, hardware type and protocol type. For example, this matches IPv4 ARP requests arriving on eth0 from one source MAC:

$ sudo arptables-nft -t filter -A INPUT \
    -i eth0 \
    --source-ip 192.0.2.10 \
    --source-mac 02:00:00:00:00:10 \
    --opcode 1 \
    --proto-type 0x800 \
    -j CONTINUE

Opcode 1 is an ARP request, while 2 is a reply. The manual lists Ethernet as hardware type 1 and IPv4 as protocol type 0x800. Keep a rule specific enough that it cannot accidentally affect unrelated address resolution.

The target is the action after a match. ACCEPT lets the frame through, DROP discards it, CONTINUE examines the next rule, and RETURN leaves a user-defined chain. A user-defined chain can also be a target. Put a restrictive rule only after you understand the existing order: the first matching action can determine what happens next.

5. Remove the test rule

Undo the first example by deleting its complete rule specification. This is safer than relying on a line number after another administrator or automation has changed the chain:

$ sudo arptables-nft -t filter -D INPUT -i eth0 -s 192.0.2.10 -j CONTINUE
$ sudo arptables-nft -t filter -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source       destination

If you have a deliberate maintenance change and record its line number immediately before removal, -D INPUT 1 deletes rule 1. Confirm the listing first. Deleting by number is easy to get wrong when rule order has changed.

Do not use -F as a general undo command. It flushes every rule in the selected chain, or every chain when no chain is named, while leaving the policy unchanged. To remove an unused user-defined chain, use -X; arptables refuses if rules still reference it.

6. Treat policies and persistence separately

-P INPUT ACCEPT, -P INPUT DROP and -P INPUT RETURN change the chain policy. A policy is the fallback when no rule matches, so changing it can disrupt networking immediately. Save the current listing and define a tested rollback before changing one:

$ sudo arptables-nft -t filter -L > /tmp/arptables-before.txt
$ sudo arptables-nft -t filter -P INPUT ACCEPT
$ sudo arptables-nft -t filter -L INPUT

The commands above change only the current kernel ruleset. The local arptables-nft manual does not define a distribution-wide persistence file or service. If your system restores firewall rules at boot, use that system's documented configuration mechanism and test a reboot separately. Do not assume a successful command will survive one.