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
