nft gripe (was: MBF: Removal of iptables-legacy)
On Sun, Nov 23, 2025 at 03:12:27PM +0000, Colin Watson wrote:
On Sun, Nov 23, 2025 at 10:57:39AM +0100, Bastian Blank wrote:
There are some packages that hardcode the use of iptables-legacy. In
those cases just using the non-legacy counterparts should work. It just
needs a reboot to get rid of the old incompatible rules loaded into the
kernel.
I wonder how many of these are conditional code in packages that also
support nft? For example, incus caught my eye in your list: it has
both xtables and nftables drivers, and it prefers nftables if it's
available. It doesn't look as though anything would need to change in
that package to cope with a kernel without iptables support.
nft is a tragedy in itself. I keep comparing nft(8) with ferm(1) and nft
falls short of that THIS far that this has kept me from nft and made me
even consider moving my Firewalls away from Linux and towards OPNsense.
I find it exceptionally distressing that I have been unable to
sensibilize nft upstream what features they're missing and they they are
unwilling to implement at least one of them¹ because they say that this
will make their parser slower (not realizing that having a bad syntax
wastes minutes of human time just to save a few seconds of CPU time)².
At least the removal of iptables-legacy will save me from implementing a
configuration option in ferm to choose between iptables-legacy and
iptables¹ my leaving just one option.
I am aware this doesn't help, but thank you for listening.
Greetings
Marc
¹ in ferm, you can have both IPv4 and IPv6 addresses in variables AND
rules and ferm will automatically pull them apart and emit the
appropriate "compiled" rules for IPv4 and IPv6 which makes it VASTLY
easier to write firewall rules in dual-stacked scenarios. This is what
makes ferm in my opinion the by far most superior firewall rule
generator available. It is somehow unjustifiedly mocked as being
"iptables' macro assembler", it is just pretty darn comfortable.
² Yes, it's open source, and I could just write that myself, but my C is
by far not good enough that I would write security relevant code in C,
and having an nft preprocessor is stupid since the whole concept of
nftables is to write directly to the kernel and we already have a parser
and "rule generator" that does so much of the job that it just needs to
be extended, and it's nft(8) itself.
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Reply to: