[pkg-netfilter-team] Bug#1032841: nftables / netfilter: severe bug: oifname not usable in arp - filter - output chains

[Binarus]

Package: nftables
Version: 0.9.8-3.1+deb11u1

Possible further package: linux-image-amd64
Version: 5.10.162-1

OS: Debian bullseye, amd64, vanilla installation, up to date at the time of writing.

NICs: Only one NIC, device enp3s0, working correctly and configured with a static IP address.

IPv6 is disabled at the kernel command line, IPv4 is fully enabled.


Dear nftables / netfilter maintainer,

I believe that I have found a severe bug in the nftables package (or in the kernel where the rules that have been compiled by nft are executed). Please consider the following ruleset (of course, it actually is nonsense by intention, but shows the problem):

table arp t_ARP
delete table arp t_ARP
table arp t_ARP {

   chain output-filter {
     type filter hook output priority -800; policy drop;

     oifname enp3s0 arp ptype 0x0800 log prefix "Foo:" accept;
     log prefix "arp-output-filter:" drop;
   }
}

With that ruleset active, the machine is not reachable via network any more, because it does no more answer ARP requests for its IP address. The reason is that the kernel does not execute the accept rule. I can clearly see this in /var/log/messages; there are no new entries that contain the "Foo:" prefix when I try to connect to that machine from another PC that does not have the respective MAC address in the ARP cache.

If I change the accept rule to

     arp ptype 0x0800 log prefix "Foo:" accept;

(that is, if I leave away "oifname enp3s0") and activate that "new" ruleset, the machine immediately answers ARP queries again as expected, and new messages with the "Foo:" prefix appear in /var/log/messages as soon as I connect to that machine from another PC that does not have the respective MAC address in the ARP cache.


This means that we can't use the "oifname" stanza in filter chains that are attached to the output hook in arp family tables on the current Debian version, which I consider a serious failure. It must be possible to create ARP output rules that take the outgoing interface into account.

I have no clue whether this is due to bugs in the kernel (where the nftables rules are executed) or due to a bug in the nft userspace program. Likewise, I have no clue whether this has been fixed upstream. I am thinking about testing it in arch linux, because that seems the most convenient way to get hold of recent kernel and nftables versions. However, I am using debian exclusively since nearly 20 years now, and learning something else would cost a lot of time, so I probably won't do that.

It would be great if you could let me know what you think about the situation as soon as your time allows (we are currently under pressure with a project that aims to replace all our iptables-based firewall scripts by nftables-based ones, but that's not possible if we can't circumvent this issue). If I am wrong, I would be glad and would be very grateful for a hint.


Thank you very much, and have a nice Sunday (it's already evening here),

Binarus