[pkg-netfilter-team] Bug#1032843: nftables / netfilter: bug: ether type 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,

this message is nearly a copy of the message I have sent you a few minutes ago. I have thought about describing both bugs in one message, but that's not what you prefer, so here we go :-)

I believe that I have found a 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;

     ether type 0x0806 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 "ether type 0x0806") 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 "ether type" stanza in filter chains that are attached to the output hook in arp family tables on the current Debian version, which I consider a failure.

Of course, I am aware that it absolutely makes no sense to have "ether type 0x0806" in a rule that is part of a chain for the arp family, so we probably can live with that rule not working as expected. However, I couldn't find a statement in nftable's man page or wiki saying that we must not use "ether type" here and there. Therefore, such rules not being executed is a bug, or at least destroys trust in nftables rules being always correctly executed.


I have no clue whether the misbehavior 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 or in Debian testing or unstable. I am thinking about testing it in arch linux, because that seems the most convenient way to get hold of the newest 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