shoud ferm call legacy tools directly

[532910]

There are pairs of each tool: iptables-legacy iptables-nft, ebtables-lagacy ebtables-ntf ...
The question is should ferm call -legacy tools derectly as sometime there are some issues:

# cat /etc/ferm/printer.ferm
domain eb table broute chain BROUTING {
	daddr $PrinterMAC DROP;
}

# ferm /etc/ferm/printer.ferm
Policy ACCEPT not allowed for user defined chains.
Cannot rollback domain 'eb' because there is no ebtables-restore

Reference debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929416

[MaxKellermann]

So the netfilter released new tools which are incompatible with the old ones, and they have a different set of tools which are still compatible... and now it's up to ferm to find the ones it should use?
Clearly the netfilter project is to blame for this breakage. But how shall ferm detect which tools to be used?

[532910]

I think the check is simple: if -legacy binaries are present on the PATH (iptables-legacy, iptables-legacy-restore, iptables-legacy-save, ebtables-legacy) then they should be called directly, otherwise tools without -legacy suffix should be called.

[532910]

https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools

[532910]

I confirm that it works fine in debian sid. Thank you!

[KimBrodowski]

Unfortunately this causes issues for us on Debian Bullseye, since other scripts interacting with the firewall use iptables. One way to solve that would be using update-alternatives to switch back to xtables, but since they're considered legacy this doesn't sit right with me. A dirty hack to circumvent this fallback can be used by setting up a drop-in unit:

[Service]
BindPaths=/dev/null:/usr/sbin/iptables-legacy
BindPaths=/dev/null:/usr/sbin/iptables-legacy-save
BindPaths=/dev/null:/usr/sbin/iptables-legacy-restore
BindPaths=/dev/null:/usr/sbin/ip6tables-legacy
BindPaths=/dev/null:/usr/sbin/ip6tables-legacy-save
BindPaths=/dev/null:/usr/sbin/ip6tables-legacy-restore

We have not experienced issues with nftables and ferm yet. Overriding the update-alternatives mechanism seems odd.

Ultimately we'll switch to a more native nftables approach I believe.

[MaxKellermann]

If you're using nftables, then what's the point of using ferm?

[532910]

Unfortunately this causes issues for us on Debian Bullseye

What issues exactly? Is there a debian bug?

We have not experienced issues with nftables and ferm yet.

Have you checked the example from the top comment?

You can update-alternatives to legacy tools.

[KimBrodowski]

If you're using nftables, then what's the point of using ferm?

Debian Buster ships with /usr/sbin/iptables pointing to /usr/sbin/iptables-nft. So we're using the iptables command in various components and ferm for the bulk of the work. This is effectively using nftables through ferm. ferm is just an abstraction layer. The commit linked above broke that on Bullseye since now ferm is using xtables again, while the rest of the system uses nftables.

The native nftables syntax is quite close to what ferm is doing. We have been using ferm for a while now though. Migrating from the ferm configuration to the nftables native syntax will take some time and create a couple of headaches. Migrating a server here and there is easy, but I'm looking at migrating over 10k servers automatically, preferably without touching a single one while preserving all local modifications. These aren't eactly simple firewall configurations either.

Using update-alternative to switch back to xtables would be an option, but this is going in the wrong direction.