[solved] Please enable CONFIG_NFT_FIB_IPV4/IPV6 (firewalld fails to start)

[minixjr]

firewalld does not work on siduction. The service starts, fails and exits with
status 0 - so it never shows up in "systemctl --failed". No nftables ruleset is
ever active, while the plasma-firewall KCM keeps showing a configured firewall.
Silent failure, which is why it went unnoticed.

Code Select Expand

firewalld[1308]: ERROR: 'python-nftables' failed: internal:0:0-0:
                Error: Could not process rule: No such file or directory
firewalld[1308]: ERROR: Failed to load full stock configuration. This likely
                indicates a system level issue, e.g. the firewall backend
                (nftables, iptables) is broken. All hope is lost. Exiting.

CAUSE

firewalld builds an nftables "fib" expression for the IPv6 reverse path filter,
in build_rpfilter_rules(),
nftables.py line 2649:

Code Select Expand

{"match": {"left": {"fib": {"flags": fib_flags, "result": "oif"}}, ...

This is the only fib usage in the nftables backend. The shipped default is
IPv6_rpfilter=strict, which the
parser in fw.py:405-414
maps to the else branch of build_rpfilter_rules(). Only the value "no" skips the
call entirely
(guard in fw.py:1022)
- so the stock configuration always hits it.

The siduction kernel has no fib support at all:

Code Select Expand

$ modinfo -n nft_fib nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib_netdev
-> none found

$ ls /lib/modules/7.1.8-1-siduction-amd64/kernel/net/netfilter/ | grep fib
-> empty

$ grep NFT_FIB /boot/config-7.1.8-1-siduction-amd64
# CONFIG_NFT_FIB_IPV4 is not set
# CONFIG_NFT_FIB_IPV6 is not set

The kernel rejects the rule with ENOENT and the whole transaction is aborted.

DEBIAN COMPARISON

From debian/config/config
in salsa kernel-team/linux, branch debian/latest (grep NFT_FIB in that file):

Code Select Expand

CONFIG_NFT_FIB_IPV4=m
CONFIG_NFT_FIB_IPV6=m
CONFIG_NFT_FIB_INET=m
CONFIG_NFT_FIB_NETDEV=m
CONFIG_NF_TABLES_ARP=y

VERIFIED ON A CLEAN STATE

Purged firewalld, python3-firewall and plasma-firewall, removed /etc/firewalld,
rebooted (empty kernel ruleset, "nft list tables" returned nothing), reinstalled
from sid. Same failure. Local configuration is ruled out.

Affects at least 7.1.7-1 and 7.1.8-1.
Versions: firewalld 2.5.1-2, nftables 1.1.6-1+b1, python3-nftables 1.1.6-1+b1.

NOTE ON THE 2023 THREAD

Topic 8905 reported
the same error message and it was answered with "python-nftables does not exist
in debian unstable". That was a misreading: "python-nftables" is a
string literal in nftables.py:389,
not a package name. The package python3-nftables is installed and works. The
cause was already the kernel back then. The reporter moved to Debian testing,
where firewalld ran - consistent with the config difference above.

WORKAROUND

Set IPv6_rpfilter=no in /etc/firewalld/firewalld.conf. firewalld then starts and
builds its ruleset, at the cost of losing the IPv6 reverse path filter.

REQUEST

Please enable CONFIG_NFT_FIB_IPV4=m and CONFIG_NFT_FIB_IPV6=m
(NFT_FIB_INET/NETDEV follow automatically).

Thank you!

---
Diagnosis worked out together with Claude Code (Opus 5), all findings measured
on my own machine: the module check, the config comparison and the clean-state
reproducer are verified here.

[DeepDayze]

This sounds like a good idea and hopefully Towo could implement that change.

[towo]

Next kernel will have those modules enabled.

[minixjr]

Confirmed fixed in 7.1.9-1-siduction-amd64 - thank you, towo!

The new kernel ships the missing options:

Code Select Expand

$ grep NFT_FIB /boot/config-7.1.9-1-siduction-amd64
CONFIG_NFT_FIB=m
CONFIG_NFT_FIB_INET=m
CONFIG_NFT_FIB_NETDEV=m
CONFIG_NFT_FIB_IPV4=m
CONFIG_NFT_FIB_IPV6=m
I removed the workaround from my first post, i.e. put IPv6_rpfilter back to
the upstream default strict in /etc/firewalld/firewalld.conf, and rebooted.
Everything I could check on the same machine (firewalld 2.5.1-2), before and after:

Code Select Expand

                              7.1.8 (IPv6_rpfilter=no)  7.1.9 (IPv6_rpfilter=strict)
nft_fib* modules loaded      none                      nft_fib, _inet, _ipv4, _ipv6
lines in "nft list ruleset"  411                        413
fib expressions in ruleset    0                          1
firewalld errors in journal  COMMAND_FAILED            none
The rule that used to make the whole transaction fail is now in place:

Code Select Expand

# nft list ruleset | grep 'fib '
        meta nfproto ipv6 fib saddr . mark . iif check missing drop
# lsmod | grep nft_fib
nft_fib_inet          12288  1
nft_fib_ipv4          12288  1 nft_fib_inet
nft_fib_ipv6          12288  1 nft_fib_inet
nft_fib                12288  3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet
Note the reference count of 3 on nft_fib - the expression is held by a live
rule, so this is not just an autoloaded module.

After the reboot journalctl -u firewalld -b contains exactly one line
("Started firewalld.service - firewalld - dynamic firewall daemon."). The
errors quoted in my first post do not appear any more.

Three things worth adding for anyone who runs into this:

1. systemctl is not a usable test here. With the broken kernel the unit
still reported active (running) with exit status 0 and firewall-cmd --state
answered running - while the ruleset was empty. The only reliable check is the
content of nft list ruleset.

2. IPv6_rpfilter=strict does not break IPv6 connectivity here (globally
routed address, ping to 2606:4700:4700::1111 with 0% loss), so there is no reason
to keep the workaround.

3. One side effect is worth expecting: on a machine where firewalld is
enabled, it has effectively been filtering nothing all this time. From 7.1.9 on it
really does apply its ruleset, so services that used to work may suddenly stop -
and the firewall is the last place one looks after a kernel update. Here it hit
IPv4 multicast (Telekom IPTV): multicast UDP creates no conntrack entry, the IGMP
join is not a UDP flow, so every stream packet counts as NEW and is dropped by the
default deny - silently, with the stream still arriving at the interface. The fix
was one rich rule:

Code Select Expand

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" destination address="232.0.0.0/8" accept'
firewall-cmd --reload
If you applied IPv6_rpfilter=no back then: it is safe to revert it now, but do
verify with nft list ruleset rather than with the service state.

Thanks again for enabling the options so quickly.