Full disclosure: the patch and repo were made by me, the bug reporter.
I'd be happy to work with you on getting them upstream, as discussed on
the GitHub PR.
Marc Haber schreef op 2025-12-20 11:45:
On Mon, May 16, 2022 at 01:24:52PM +0200, William Edwards wrote:
On 'regular' >= Debian Buster systems, the alternative for xtables is
xtables-nft. These are compatibility layers to use the nf_tables
backend
with xtables tooling and syntax.
In GitHub issue #47, a ferm user proposed xtables-legacy be used
directly.
ferm changed this behaviour with commit 47b78b6. This causes the
xtables
backends to be used, rather than the nftables compatibility layers.
The
rationale behind this change is that the xtables-legacy and
xtables-nft
tools are not fully compatible. The number of reports related to this
issue
is limited.
The aforementioned commit, which changes the behaviour to use
xtables-legacy, was included in package version 2.5-1 (see Debian Bug
report
#929416). ferm 2.5.1-1 is now the most recent package version in the
stable
repository. As such, the current ferm package in the stable repository
no
longer uses nftables (albeit by means of the compatibility layer). Yet
users
are adviced to use the nf_tables backend. This effectively means that
users
must phase out ferm before upgrading Debian. I believe this greatly
complicates the upgrade path. Especially as the general concensus
seems to
be that ferm alternatives, and even the native nftables configuration
format, are currently missing useful features that ferm does provide.
I doubt that the incompatibility between xtables-legacy outweighs
this. I
propose commit 47b78b6 not be included in this package.
There is also https://github.com/MaxKellermann/ferm/pull/90 to address
this and a new repository on https://gitlab.tuxis.nl/oss_public/ferm
I am adding this here so that I don't forget this when I will
eventually
work on the ferm package as well.
Greetings
Marc
Met vriendelijke groeten,
William David Edwards
