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
