Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #119678 > unrolled thread

MBF: Removal of iptables-legacy

Back to article view | Back to linux.debian.devel

Contents

  MBF: Removal of iptables-legacy Bastian Blank <waldi@debian.org> - 2025-11-23 11:20 +0100
    Re: MBF: Removal of iptables-legacy Colin Watson <cjwatson@debian.org> - 2025-11-23 16:20 +0100
      Re: MBF: Removal of iptables-legacy Vincent Danjean <vdanjean.ml@free.fr> - 2025-11-23 17:00 +0100
        Re: MBF: Removal of iptables-legacy Lucas Castro <lucas@gnuabordo.com.br> - 2025-11-24 17:20 +0100
          Re: MBF: Removal of iptables-legacy Marc Haber <mh+debian-devel@zugschlus.de> - 2025-11-24 17:50 +0100
            Re: MBF: Removal of iptables-legacy Lucas Castro <lucas@gnuabordo.com.br> - 2025-11-24 18:00 +0100
      nft gripe (was: MBF: Removal of iptables-legacy) Marc Haber <mh+debian-devel@zugschlus.de> - 2025-11-23 17:30 +0100
      Re: MBF: Removal of iptables-legacy Bastian Blank <waldi@debian.org> - 2025-11-23 17:50 +0100
        Re: MBF: Removal of iptables-legacy Colin Watson <cjwatson@debian.org> - 2025-11-24 15:20 +0100
    Re: MBF: Removal of iptables-legacy Tianon Gravi <tianon@debian.org> - 2025-11-25 02:10 +0100
    Re: MBF: Removal of iptables-legacy Andrea Bolognani <eof@kiyuko.org> - 2026-01-07 02:50 +0100
      Re: MBF: Removal of iptables-legacy Jeremy Sowden <azazel@debian.org> - 2026-01-07 09:20 +0100

#119678 — MBF: Removal of iptables-legacy

[Multipart message — attachments visible in raw view] — view raw

Hi

The Debian Kernel team decided to deprecate and remove support for the
legacy interfaces used by iptables, arptables and ebtables from the
kernel.  The replacement nftables compatibility layer was introduced
around 2016.  It is finally time to try and get rid of the legacy
interfaces, which are now disabled by default in the kernel.

Our plan is to drop usage in all packages and the binaries for forky.
We will then go and remove the kernel support itself after the release
of forky.  So in forky, using legacy iptables will still work, but
Debian will not provide any support and consider it deprecated.

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.

Bastian

-- 
There are always alternatives.
		-- Spock, "The Galileo Seven", stardate 2822.3

[toc] | [next] | [standalone]

#119682

[fixed typo in debian-kernel@ address]

On Sun, Nov 23, 2025 at 10:57:39AM +0100, Bastian Blank wrote:
>The Debian Kernel team decided to deprecate and remove support for the
>legacy interfaces used by iptables, arptables and ebtables from the
>kernel.  The replacement nftables compatibility layer was introduced
>around 2016.  It is finally time to try and get rid of the legacy
>interfaces, which are now disabled by default in the kernel.
>
>Our plan is to drop usage in all packages and the binaries for forky.
>We will then go and remove the kernel support itself after the release
>of forky.  So in forky, using legacy iptables will still work, but
>Debian will not provide any support and consider it deprecated.
>
>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.

I'd expect many userspace programs to take similar strategies if they've 
been around for long enough to have needed to support pre-nftables 
kernels at some point, so this MBF will likely need a fair amount of 
filtering.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#119684

Le 23/11/2025 à 16:12, Colin Watson a écrit :
> [fixed typo in debian-kernel@ address]
> 
> On Sun, Nov 23, 2025 at 10:57:39AM +0100, Bastian Blank wrote:
>> The Debian Kernel team decided to deprecate and remove support for the
>> legacy interfaces used by iptables, arptables and ebtables from the
>> kernel.  The replacement nftables compatibility layer was introduced
>> around 2016.  It is finally time to try and get rid of the legacy
>> interfaces, which are now disabled by default in the kernel.
>>
>> Our plan is to drop usage in all packages and the binaries for forky.
>> We will then go and remove the kernel support itself after the release
>> of forky.  So in forky, using legacy iptables will still work, but
>> Debian will not provide any support and consider it deprecated.

I'm not sure to correctly understand.
Is it only the kernel interface that will be removed (and the 'iptables-legacy' package) ?
Or would the binary 'iptables', ... from the 'nftables' package also be removed ? (compat layer on top of nftables)

I'm using the shorewall{,6} firewall for now. I've never found another firewall packaged by Debian being able to handle multi-ISP (I would be please to be wrong).
If I recall correctly, shorewall relies on iptables (but works with nftables compat layer) and upstream does not want to work on a switch to a pure nftable implementation (too much work)[1]

Regards,
   Vincent

[1] https://gitlab.com/shorewall/code/-/issues/2

[toc] | [prev] | [next] | [standalone]

#119702

[Multipart message — attachments visible in raw view] — view raw

Em 23/11/2025 12:54, Vincent Danjean escreveu:
> Le 23/11/2025 à 16:12, Colin Watson a écrit :
>> [fixed typo in debian-kernel@ address]
>>
>> On Sun, Nov 23, 2025 at 10:57:39AM +0100, Bastian Blank wrote:
>>> The Debian Kernel team decided to deprecate and remove support for the
>>> legacy interfaces used by iptables, arptables and ebtables from the
>>> kernel.  The replacement nftables compatibility layer was introduced
>>> around 2016.  It is finally time to try and get rid of the legacy
>>> interfaces, which are now disabled by default in the kernel.
>>>
>>> Our plan is to drop usage in all packages and the binaries for forky.
>>> We will then go and remove the kernel support itself after the release
>>> of forky.  So in forky, using legacy iptables will still work, but
>>> Debian will not provide any support and consider it deprecated.
>
> I'm not sure to correctly understand.
> Is it only the kernel interface that will be removed (and the 
> 'iptables-legacy' package) ?
> Or would the binary 'iptables', ... from the 'nftables' package also 
> be removed ? (compat layer on top of nftables)
>
> I'm using the shorewall{,6} firewall for now. I've never found another 
> firewall packaged by Debian being able to handle multi-ISP (I would be 
> please to be wrong).
> If I recall correctly, shorewall relies on iptables (but works with 
> nftables compat layer) and upstream does not want to work on a switch 
> to a pure nftable implementation (too much work)[1]

I can't guess what problem you get when handling multi-ISP, but my guess 
that should be related against routing and not firewalling.


>
> Regards,
>   Vincent
>
> [1] https://gitlab.com/shorewall/code/-/issues/2
>

[toc] | [prev] | [next] | [standalone]

#119704

On Mon, Nov 24, 2025 at 01:07:29PM -0300, Lucas Castro wrote:
>I can't guess what problem you get when handling multi-ISP, but my 
>guess that should be related against routing and not firewalling.

Marking packets in iptables and then routing according to the fwmark is 
a rather common usecase.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
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

[toc] | [prev] | [next] | [standalone]

#119705

[Multipart message — attachments visible in raw view] — view raw

Em 24/11/2025 13:44, Marc Haber escreveu:
> On Mon, Nov 24, 2025 at 01:07:29PM -0300, Lucas Castro wrote:
>> I can't guess what problem you get when handling multi-ISP, but my 
>> guess that should be related against routing and not firewalling.
>
> Marking packets in iptables and then routing according to the fwmark 
> is a rather common usecase.

I'm aware of that and I indeed use that way, but almost the problem 
isn't on firewall.

I can be wrong but marking rules isn't that hard and do not differ when 
handling multi-ISP, routing setting on multi-ISP require attention.


>
> Greetings
> Marc
>

[toc] | [prev] | [next] | [standalone]

#119685 — 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

[toc] | [prev] | [next] | [standalone]

#119686

On Sun, Nov 23, 2025 at 03:12:27PM +0000, Colin Watson wrote:
> 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.

The source check matched this reference to the legacy stuff:

| test/suites/container_devices_nic_bridged_filtering.sh:            echo "==> SKIP: ebtables must be legacy version (try update-alternatives --set ebtables /usr/sbin/ebtables-legacy)"

Bastian

-- 
Extreme feminine beauty is always disturbing.
		-- Spock, "The Cloud Minders", stardate 5818.4

[toc] | [prev] | [next] | [standalone]

#119701

On Sun, Nov 23, 2025 at 05:25:09PM +0100, Bastian Blank wrote:
>On Sun, Nov 23, 2025 at 03:12:27PM +0000, Colin Watson wrote:
>> 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.
>
>The source check matched this reference to the legacy stuff:
>
>| test/suites/container_devices_nic_bridged_filtering.sh:            echo "==> SKIP: ebtables must be legacy version (try update-alternatives --set ebtables /usr/sbin/ebtables-legacy)"

That code is within a [ "$firewallDriver" = "xtables" ] check, which 
will be false on a modern system.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#119711

On Sun, 23 Nov 2025 at 02:15, Bastian Blank <waldi@debian.org> wrote:
> The Debian Kernel team decided to deprecate and remove support for the
> legacy interfaces used by iptables, arptables and ebtables from the
> kernel.  The replacement nftables compatibility layer was introduced
> around 2016.  It is finally time to try and get rid of the legacy
> interfaces, which are now disabled by default in the kernel.
>
> Our plan is to drop usage in all packages and the binaries for forky.
> We will then go and remove the kernel support itself after the release
> of forky.  So in forky, using legacy iptables will still work, but
> Debian will not provide any support and consider it deprecated.
>
> 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.

Thanks for the src:docker.io heads-up!  However, I think this is a
false positive:

https://codesearch.debian.net/search?q=iptables-legacy+pkg%3Adocker.io&literal=1

(only 4 hits, two of which are Dockerfiles that aren't used in the
package build at all, nor shipped in the builds, and two in the
d/changelog -- even less hits for "ip6tables-legacy" and zero for
"ebtables-legacy")

♥,
- Tianon

[toc] | [prev] | [next] | [standalone]

#120108

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 23, 2025 at 10:57:39AM +0100, Bastian Blank wrote:
> Hi
> 
> The Debian Kernel team decided to deprecate and remove support for the
> legacy interfaces used by iptables, arptables and ebtables from the
> kernel.  The replacement nftables compatibility layer was introduced
> around 2016.  It is finally time to try and get rid of the legacy
> interfaces, which are now disabled by default in the kernel.
> 
> Our plan is to drop usage in all packages and the binaries for forky.
> We will then go and remove the kernel support itself after the release
> of forky.  So in forky, using legacy iptables will still work, but
> Debian will not provide any support and consider it deprecated.
> 
> 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.

Bit late to the party, sorry.

Can you please confirm that it's only iptables-legacy (and the
underlying kernel code) going away, and that iptables-nft will keep
working going forward?

libvirt tried to switch to nft a year ago but unfortunately that
turned out to be unfeasible at the time, so we are currently relying
on the compatibility interface provided by iptables-nft. Additional
details in #1090355.

Thanks!

-- 
Andrea Bolognani <eof@kiyuko.org>
Resistance is futile, you will be garbage collected.

[toc] | [prev] | [next] | [standalone]

#120110

[Multipart message — attachments visible in raw view] — view raw

On 2026-01-07, at 02:40:37 +0100, Andrea Bolognani wrote:
> On Sun, Nov 23, 2025 at 10:57:39AM +0100, Bastian Blank wrote:
> > The Debian Kernel team decided to deprecate and remove support for the
> > legacy interfaces used by iptables, arptables and ebtables from the
> > kernel.  The replacement nftables compatibility layer was introduced
> > around 2016.  It is finally time to try and get rid of the legacy
> > interfaces, which are now disabled by default in the kernel.
> >
> > Our plan is to drop usage in all packages and the binaries for forky.
> > We will then go and remove the kernel support itself after the release
> > of forky.  So in forky, using legacy iptables will still work, but
> > Debian will not provide any support and consider it deprecated.
> >
> > 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.
> 
> Bit late to the party, sorry.
> 
> Can you please confirm that it's only iptables-legacy (and the
> underlying kernel code) going away, and that iptables-nft will keep
> working going forward?

Correct.

> libvirt tried to switch to nft a year ago but unfortunately that
> turned out to be unfeasible at the time, so we are currently relying
> on the compatibility interface provided by iptables-nft. Additional
> details in #1090355.

J.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web