After almost 3 major releases and four years of nftables being the standard for OpenWrt, in my opinion, it is well overdue time to drop iptables-zz-legacy et-al, or at the very least make iptables-nft the default.
There are two common packages that have iptables as a dependency, mwan3 and sqm-scripts and there is no visibility of any effort whatsoever to migrate these to native nftables. Both these packages currently force the install of iptables-zz-legacy unless pre-empted with a manual install of iptables-nft. This can and often does cause all sorts of issues.
There are also numerous less popular packages also with iptables, xtables, ebtables etc as a dependency. eg nodogsplash, coova-chilli, again with no visible effort to migrate. I am sure there are more.
Four years of waiting is enough!
Serious and urgent consideration should be given to either dropping the kludge of -zz-legacy altogether or at the very least change the default to -nft versions.
What do we do with unmigrated packages? Drop them until migrated?
Are they unmigrated because they are no longer maintained? This is certainly the case for some.
You can do whatever you like with your own fork(s).
Sorry, I'm not meaning to chase per se, but you have had three major releases and four years......
Will your packages work with iptables-nft? I am not aware of any that won't....
The whole point of iptables-nft is to give a "breathing space" for migration to occur.
A bit off topic, but apk is a trivial change for everyone other than the poor devs implementing it on OpenWrt. I routinely build both ipk and apk versions of packages for package development purposes, with nothing special to do and no particular problems.
And we do indeed do as we wish, but it carries a burden of back porting things and maintaining patches.
Yes, this is a selfish ask but I don’t see a great need to drop these legacy options unless they are causing a real problem.
The first time they present a CVE I have no problem with the treatment being to drop them instead of patch.
However until they cause a problem…?
Yes we have had time, but as the solo developer (1 or 2 transients aside) it’s a big enough burden keeping up with main releases.
We carry custom kernel modules for iptables that must be rewritten for nftables. I actually started this last month and have almost finished the first one, but it’s not been straight forward and has required a lot of learning about nftnl etc.
No we can’t use the nft versions of the utilities due to those custom modules (without writing support, at which point you just go the whole way).
Again, apk is a burden as we carry gpkg forked from opkg.
I’ll reiterate, I totally get this is a selfish position to take to ask these things of the project, but if it’s not causing any current issues, why do it?
Drop the unmaintained packages by all means. Leave iptables legacy, please.
I feel for you on that one, but none of the standard ipt kmods needed any rewriting to use iptables-nft... Some bad design choices biting you in the as* I guess. Made some of those types of choices myself in the past
They can and do. It is even possible to end up with both iptables-zz-legacy and iptables-nft installed at the same time and have things firewall related randomly breaking all over the place.
Maybe the simplest and quickest "temporary" compromise would be to change the default to iptables-nft.
Then, for edge cases like yours, the onus would be on you to pre-install iptables-zz-legacy, pending proper migration, rather than the other way round.
The key being standard ipt kmods.
If you introduce new match modules that come with their own syntax (obviously), then iptables-nft needs to know how to interpret this. My understanding also is that the corresponding nft modules need to be present underneath as well.
This is the cost of having accurate and flexible bandwidth monitoring, quotas, web url monitoring and filtering, and time based rules with multiple windows that don’t worry about kernel tz issues.
It needs lots of care to make it certain no nft- (as opposed to nf-) kmods are blacklisted/not installed, at present they pull in huge pile as dependencies.
It has been since the release of 21.02.0, that's three major releases and four years ago.
iptables-nft et al are provided for backward compatibility but inevitably are a compromise intended only as a stop-gap to give more time for migration to nftables.
Most reported instances of compatibility failure were found to be due to the default installation by opkg of the -zz-legacy version when "iptables" is a dependency with iptables-nft being loaded manually on top of the legacy version.
There is one reported unofficial fork of OpenWrt that uses -zz-legacy with custom kmods written in such a way that iptables-nft apparently does not work as expected. Although it is of general technical interest, it should not influence this discussion which is exclusively about mainstream OpenWrt.
Some existing packages continue to have iptables et al as a dependency. After four years, none of these appear to have any signs of migration effort. This either means these packages are unmaintained or the developers have ignored the package's outdated status for whatever reason.
Many of the recurring issues can be temporarily mitigated by changing the default install to iptables-nft when "iptables" is a package dependency, from the current "iptables-zz-legacy" (this applies also to xtables and ebtables dependencies).
As far as I can tell, this is sufficient for sqm-scripts use cases. However sqm-scripts is not an OpenWrt exclusive project so has different desires about supporting both ip- an nf-tables. That might not be a popular position here in the OpenWrt forum, but that is the current state as I see it (but that might change and is not set in stone forever, but the constraints are not only OpenWrt).
Yes, see above why I believe sqm-scripts is "different" here.
Or there are different constraints... but the work around for sqm-scripts is to first install iptables-nft IIRC.
It needs much more staging, there was no visual notification mixed frameworks, eg mwan3 on a clean system pulls both iptables worlds unless you preinstall -nft (4)
(5) uses "mark" target which has to be tested by whether it is the only problem holding them back...
(6) it transparently forwards to xt/ipt frameworks and nobody ever sees anything wrong with "legacy" approach
It is really down to depsolver not doing enough to modernize developers.
First step (maybe 24.10) might be conflicting -zz- vs -nft to make problem more visible?
I agree that any discussion should focus on what is the correct approach for OpenWRT to take. The impact on another firmware project (which is what Gargoyle is) shouldn't be a reason to make appropriate changes to OpenWRT.
It does. Also for nodogsplash and mwan3 (although ipset is broken by fw4 driven changes to dnsmasq).
At the very least, the change of default to iptables-nft etc. should be implemented.
Then the default will not be a potentially broken state.
If anyone really needed the legacy versions they can remove -nft and install -zz-legacy at their own risk, rather than the other way round with everyone being at risk of problems.
I hear what you say about sqm.
But all Linux distros (at least the ones I have looked at) have nftables as default and iptables-nft as either an option or default, so even sqm devs should at least be seriously considering migration, otherwise it smells of "we cannot be bothered until -legacy is finally deprecated". That is not really a justifiable constraint.
As an exercise, a Grok search gave the following result:
Based on the available information, here's an overview of the plans and timeline regarding the deprecation of iptables:
General Deprecation Status: Iptables is considered deprecated in favor of nftables by major Linux distributions like Red Hat, Debian, and others. This shift has been ongoing for several years, with nftables being introduced in the Linux kernel with version 3.13 in 2014.
In RHEL 9, the iptables framework, including the iptables backend in firewalld and direct interface, is deprecated. However, there is no specific end date provided for the complete removal. Instead, it's suggested to migrate to nftables for new deployments or configurations.
Debian:
Debian's transition to nftables started with Debian 10 (Buster), where nftables became the default backend for iptables. The iptables package in Debian now essentially translates to nftables commands under the hood. There's no explicit timeline for when iptables might be removed entirely, but the move towards nftables is clear.
While not explicitly stated in the referenced material, the trend across distributions mirrors that of Debian and RHEL, with nftables becoming more prominent. Ubuntu, for example, uses ufw as a front-end, which in newer versions interacts with nftables.
Specific Cases:
DAppNode on Debian has highlighted the issue of Docker not supporting nftables, indicating a potential critical issue for systems relying on Docker if iptables support were to be completely removed.
Void Linux discusses deprecation in terms of transitioning smoothly to nftables but acknowledges that iptables will not be removed from repositories due to the need for backward compatibility.
Timeline Considerations:
While there's no universal timeline for complete deprecation across all Linux distributions, the trend suggests:
Short to Medium Term: Expect continued support for iptables for backward compatibility, especially in server environments where stability is key.
Long Term: Over the next few years, iptables might see reduced maintenance or updates, with new features and development focused on nftables.
Migration Tools:
Tools like iptables-translate and ip6tables-translate are available to assist in the transition from iptables to nftables, indicating an active encouragement towards migration.
In summary, while iptables is deprecated, there's no definitive end date for its complete removal across all distributions. The transition to nftables is ongoing, with varying levels of urgency depending on the distribution and specific use cases. For users and system administrators, the advice is to start familiarizing themselves with nftables and preparing for or executing migrations where necessary.
Yes. The simplest way when there is a dependency for "iptables" is to change the default package to be installed to iptables-nft.
ie the preferred answer to "what provides iptables" should be iptables-nft.
Currently it stands as iptables-zz-legacy.
