Arch Linux stuck on legacy iptables by default
Arch Linux still uses the legacy iptables backend, as opposed to the nft backend that every other distribution uses. This has been reported since 2021 with no response: https://gitlab.archlinux.org/archlinux/packaging/packages/iptables/-/issues/... To me it looks like a direct, simple migration, and it just needs someone with the needed perms to look at it, but I could be wrong. It's assigned to the notoriously overburdened Felix, is there anything a non-core member can do, other than wait? It's not a *large* issue, it's just mildly annoying to have workarounds in my deploys, as it is installed on any system due to iproute2 needing an iptables backend, and some things just outright don't work with that, requiring the nft one. Thanks, Martin
On 10/14/24 8:49 AM, Martin Rys wrote:
Arch Linux still uses the legacy iptables backend, as opposed to the nft backend that every other distribution uses.
I always thought the iptables default was the result if Arch's KISS philosophy and I really appreciate it. I use iptables, ipset and fail2ban and like being able to put those base pieces together and tailor them for my server use without bringing in the whole nftables pre-defined sets. I appreciate Arch providing the basic tools by default, while also making nftables available if you want to go that route. I wouldn't change the default. -- David C. Rankin, J.D.,P.E.
nftables is able to respond to iptables commands through the compatibility layer. iptables-nft is the packet for you. Le jeu. 17 oct. 2024 à 09:16, David C. Rankin <drankinatty@gmail.com> a écrit :
On 10/14/24 8:49 AM, Martin Rys wrote:
Arch Linux still uses the legacy iptables backend, as opposed to the nft backend that every other distribution uses.
I always thought the iptables default was the result if Arch's KISS philosophy and I really appreciate it. I use iptables, ipset and fail2ban and like being able to put those base pieces together and tailor them for my server use without bringing in the whole nftables pre-defined sets.
I appreciate Arch providing the basic tools by default, while also making nftables available if you want to go that route. I wouldn't change the default.
-- David C. Rankin, J.D.,P.E.
On 10/17/24 3:35 AM, gerard.bigot@gmail.com wrote:
nftables is able to respond to iptables commands through the compatibility layer.
iptables-nft is the packet for you.
Thank you, I'm glad that's there, but then I have to ask myself, why would I want to run iptables via nftables through a compatibility layer when I can just run iptables itself? The other issue I see there is if a bug or issue pops up. Then is it due to iptables or the nft compatibility layer? Either way, I'm glad to know I can still use the tailored setup regardless of the default. But I do see a downside troubleshooting if a compatibility layer is involved. So long as both are packages are offered, it doesn't really matter. You can install or remove either to your liking. I've been meaning to try the nftables setup, but haven't had a day or so to set aside to go through everything. I've got no complaints about the defaults Arch chooses. They always work out okay. -- David C. Rankin, J.D.,P.E.
With the iptables-nft packet, you'll use nftables backend, not the iptables one. Look up the difference featurewise between the two, you'll be convicted. Your legacy script, software can still talk iptables to your system, but it's the nftables that answer. If you switch to nftables compatible software, you'll also get new features, only available through nftables. Le jeu. 17 oct. 2024 à 11:31, David C. Rankin <drankinatty@gmail.com> a écrit :
On 10/17/24 3:35 AM, gerard.bigot@gmail.com wrote:
nftables is able to respond to iptables commands through the compatibility layer.
iptables-nft is the packet for you.
Thank you,
I'm glad that's there, but then I have to ask myself, why would I want to run iptables via nftables through a compatibility layer when I can just run iptables itself?
The other issue I see there is if a bug or issue pops up. Then is it due to iptables or the nft compatibility layer?
Either way, I'm glad to know I can still use the tailored setup regardless of the default. But I do see a downside troubleshooting if a compatibility layer is involved.
So long as both are packages are offered, it doesn't really matter. You can install or remove either to your liking. I've been meaning to try the nftables setup, but haven't had a day or so to set aside to go through everything.
I've got no complaints about the defaults Arch chooses. They always work out okay.
-- David C. Rankin, J.D.,P.E.
On Thursday, 17 October 2024 at 04:31 (-0500), David C. Rankin wrote:
On 10/17/24 3:35 AM, gerard.bigot@gmail.com wrote:
nftables is able to respond to iptables commands through the compatibility layer.
iptables-nft is the packet for you.
I'm glad that's there, but then I have to ask myself, why would I want to run iptables via nftables through a compatibility layer when I can just run iptables itself?
The other issue I see there is if a bug or issue pops up. Then is it due to iptables or the nft compatibility layer?
It's worth noting that nftables is not a newfangled piece of external software – it's been mainlined in the Linux kernel since 2013, and was intended to be the successor to legacy iptables. Jaron
On 10/17/24 6:44 AM, Jaron Kent-Dobias wrote:
On Thursday, 17 October 2024 at 04:31 (-0500), David C. Rankin wrote:
On 10/17/24 3:35 AM, gerard.bigot@gmail.com wrote:
nftables is able to respond to iptables commands through the compatibility layer.
iptables-nft is the packet for you.
I'm glad that's there, but then I have to ask myself, why would I want to run iptables via nftables through a compatibility layer when I can just run iptables itself?
The other issue I see there is if a bug or issue pops up. Then is it due to iptables or the nft compatibility layer?
It's worth noting that nftables is not a newfangled piece of external software – it's been mainlined in the Linux kernel since 2013, and was intended to be the successor to legacy iptables.
If nftables automatically uninstalls iptables as an indirect dependency, then no, the default should not change. That would seem to break every Arch system currently using iptables. Other than "it's newer", I can't see what is driving the push for a change in defaults. The package is there if you prefer it, just like if you prefer nginx over apache or clang over gcc. From reading, it seems nftables is just larger and more complex netfilter project (and yes it does more -- if you need it). Both iptables and nftables are actively developed, so it's not like one is deprecated. Why push for a change in default where iptables fits Arch's KISS philosophy and nftables is there if you need something more? Has there been any testing to ensure iptables-nft works with all combinations of iptables, ipset and fail2ban setups? How would the change work anyway. Would pacman -Syu fail if you answered "No" to replace iptables with nftables? Just the thoughts I had considering the change. -- David C. Rankin, J.D.,P.E.
On 18/10/24 7:46 am, David C. Rankin wrote:
From reading, it seems nftables is just larger and more complex netfilter project (and yes it does more -- if you need it). Both iptables and nftables are actively developed, so it's not like one is deprecated.
No. Iptables (legacy) that Arch uses by default has been deprecated in 2018 (almost 6 and half years back) and not recommended anymore. We are pushing that Arch switch to iptables with nftables as backend, by default. This is what many major distros have done too. So old scripts (using iptables) still continue to work but with better and newer framework. For more details, see: [1] Two variants of iptables https://developers.redhat.com/blog/2020/08/18/iptables-the-two-variants-and-... [2] Netfilter workshop 2018 https://ral-arturo.org/2018/06/16/nfws2018.html Amish
On Thursday, 17 October 2024 at 21:16 (-0500), David C. Rankin wrote:
On 10/17/24 6:44 AM, Jaron Kent-Dobias wrote:
It's worth noting that nftables is not a newfangled piece of external software – it's been mainlined in the Linux kernel since 2013, and was intended to be the successor to legacy iptables.
If nftables automatically uninstalls iptables as an indirect dependency, then no, the default should not change. That would seem to break every Arch system currently using iptables.
It doesn't.
# pacman -Si nftables Name : nftables [...] Conflicts With : None Replaces : None [...]
Jaron
On 18-10-2024 08:35, Jaron Kent-Dobias wrote:
On Thursday, 17 October 2024 at 21:16 (-0500), David C. Rankin wrote:
On 10/17/24 6:44 AM, Jaron Kent-Dobias wrote:
If nftables automatically uninstalls iptables as an indirect dependency, then no, the default should not change. That would seem to break every Arch system currently using iptables.
It doesn't.
# pacman -Si nftables Name : nftables [...] Conflicts With : None Replaces : None [...]
Jaron
It's iptables-nft that would likely become the new default, existing iptables installs should not be affected.
$ pacman -Qi iptables-nft
Name :iptables-nft
Provides :libip4tc.so=2-64 libip6tc.so=2-64 libipq.so=0-64 libxtables.so=12-64 iptables arptables ebtables Conflicts With :iptables arptables ebtables
Replaces :None
LW
participants (6)
-
Amish
-
David C. Rankin
-
gerard.bigot＠gmail.com
-
Jaron Kent-Dobias
-
Lone_Wolf
-
Martin Rys