Watch nft-backed iptables Rules and TRACE Packets with xtables-monitor

You will finish with two practical ways to observe an iptables ruleset: a live stream of ruleset changes, and a trace of selected packets as they pass through the rules. The examples use xtables-monitor 1.8.10 from iptables 1.8.10, using the nf_tables backend.

Allow about fifteen minutes for a read-only monitoring session. You need a shell, iptables-nft and a terminal with access to the host's netfilter interfaces. Root access is usually required for the monitor and for any rule change. Monitoring does not itself edit the firewall, but a TRACE rule does change packet-filtering configuration.

1. Confirm the installed backend

Start with ordinary, read-only checks. They do not need elevated privileges:

$ command -v xtables-monitor
/usr/sbin/xtables-monitor
$ iptables --version
iptables v1.8.10 (nf_tables)
$ xtables-monitor --help
xtables-monitor 1.8.10 (nf_tables)
Usage: xtables-monitor [ -t | -e ]

The important detail is (nf_tables). The monitor reads events from the nftables-backed iptables path. The installed manual says that rules added with iptables-legacy cannot be monitored, so do not treat a silent session as proof that no one is changing the firewall until you have checked which command family is being used.

Checkpoint: record the version and backend. If iptables --version reports a legacy backend, this guide's monitoring examples are not the right observation point.

2. Watch ruleset changes

Open a terminal and start the event monitor. This is a long-running command. Use sudo if the unprivileged attempt cannot access the netfilter event socket:

$ sudo xtables-monitor --event

The command runs until you stop it with Ctrl-C. It reports changes such as table, chain and rule creation, together with the program that caused the update. The exact event sequence depends on the host and on the tool making the change.

In another terminal, make a harmless, deliberate change only if you are authorised to alter this firewall. The following creates a temporary user-defined chain and then removes it:

$ sudo iptables -N XT_MONITOR_TEST
$ sudo iptables -X XT_MONITOR_TEST

Back in the monitor, expect event lines containing the equivalent of -N XT_MONITOR_TEST and -X XT_MONITOR_TEST. Event output can also include nft-native table and chain details, so do not build a parser that assumes every line is an iptables command.

3. Understand the event checkpoint

When iptables-nft restores or rebuilds a ruleset, the monitor may show a new table, base chains and several rules before a NEWGEN line. The manual's example uses NEWGEN to mark the point at which the new ruleset generation becomes active, and includes the process ID and program name.

That distinction matters during incident work. Seeing a rule-creation line means that an update was described to the monitor. A later generation event tells you when the changed ruleset became active. Capture the complete sequence, including the program name, rather than copying only the rule that caught your eye.

If the monitor immediately prints cannot bind to nfnetlink socket: Operation not permitted, the process lacks the required access in that environment. Try the same command with sudo. If it still fails inside a container or restricted service, the missing capability may be outside the container's control; do not weaken host security merely to make a diagnostic stream available.

4. Add a narrow TRACE rule

xtables-monitor --trace watches trace events generated by packets marked with the iptables TRACE target. Starting the monitor alone does not cause packets to be traced. You must add a rule that selects them.

For a controlled HTTP test, start the monitor first:

$ sudo xtables-monitor --trace --ipv4

Then, in a second terminal, add a deliberately narrow rule. This example selects at most one new TCP connection per second to port 80 arriving at the IPv4 raw table's PREROUTING chain:

$ sudo iptables -t raw -A PREROUTING -p tcp --dport 80 --syn -m limit --limit 1/s -j TRACE

Generate a matching connection, or wait for one if the host serves HTTP. The monitor should print TRACE lines for the packet, a PACKET line containing interface and header information, and later chain or policy results. A packet identifier in the trace lets you correlate lines belonging to the same packet. The output is diagnostic data, not a substitute for the complete ruleset.

TRACE is security-sensitive operational state because it changes the firewall's rule path and exposes packet metadata. Keep the match specific. Do not use a catch-all TRACE rule on a busy interface unless you have measured the impact and have a maintenance window.

5. Remove the TRACE rule

Remove the exact rule as soon as the capture is complete. This is an elevated, state-changing command:

$ sudo iptables -t raw -D PREROUTING -p tcp --dport 80 --syn -m limit --limit 1/s -j TRACE

The deletion must match the rule that was added. Verify that it is gone with a read-only listing:

$ sudo iptables -t raw -S PREROUTING
# the TRACE rule should no longer be listed

If you changed the port, protocol or limit, substitute the same values in the delete command. If the rule was inserted in a different position or had extra matches, inspect iptables -t raw -S PREROUTING and remove the exact rule shown there. Do not flush the raw table as a shortcut: that can remove unrelated production rules.

6. Filter the address family

The monitor supports -4 or --ipv4 for IPv4 and -6 or --ipv6 for IPv6. Use one when the other protocol family would distract from the investigation:

$ sudo xtables-monitor --event --ipv4
$ sudo xtables-monitor --trace --ipv6

These filters affect what the monitor reports. They do not convert an IPv4 rule into an IPv6 rule, and they do not add or remove firewall policy.

Common traps

• No output is not necessarily no activity. Check that the command uses iptables-nft, that the monitor has permission to open its netfilter socket, and that the selected address family matches the traffic.
• Do not confuse event and trace modes. --event watches ruleset updates. --trace watches packets that a TRACE rule has tagged.
• Do not leave TRACE enabled. Keep the delete command in your terminal history or notes before adding the rule, then verify removal.
• Do not infer a stable output format. nft-native records, iptables command-style records and generation metadata can appear in one event stream.
• Legacy rules are outside the monitor's coverage. Rules added through iptables-legacy cannot be monitored by this tool.