-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Certain upstream switch to firewall4
aka nftables
instead of iptables
#16818
Comments
As the package maintainer of the mwan3, I would also like to know what I have to do to make the mwan3 fit for nftables. |
It's possible, an idea to be discussed. There is no definite decision yet, however ideally maintainer start looking at |
My concern is over 'ipset' equivalent functionality support. dnsmasq v2.87 (not yet released) has immature support. adblock & banip rely heavily on ipsets and will need adjusting. |
Is the plan to ship the iptables-nft compability binary? And is there an overview somewhere of how firewall4 differs in which table names it uses compared with firewall3? Off the top of my head, at least |
Also acme does some iptables command packages/net/acme/files/run.sh Lines 127 to 133 in 6c73457
|
On 6 October 2021 12:31:12 CEST, Florian Eckert ***@***.***> wrote:
Also acme does some iptables command
https://github.com/openwrt/packages/blob/6c73457c09f838279b240bef59730cbff60ae799/net/acme/files/run.sh#L127-L133
Ah yes, so it does - totally forgot about that. Thanks for the reminder!
|
adblock is purely DNS and doesn't use any direct iptables calls. Maybe simple-adblock is affected here - I don't know. |
collectd iptables plugin depends on libiptc as far as I know |
I would expand the list a little further:
Except from shorewall and xtables-addons, which are clearly not compatible with firewall4/nftable, the rest is still open. Anything that depends on iptables or calls iptables(-save/-restore) needs some testing, specially if iptables-nft is in use. Maybe we could edit this issue description mentioning maintainers after the package to ping them all? I doubt that iptables-nft will be installed by default and I think fw3 will still be available as a fallback. It would be interesting to see how we deal with dependencies when both standard iptables and iptables-nft are available and the user could either use fw3 or fw4. Some packages might require iptables/nftables flavors. |
@luizluca the adblock packages mentions
|
@stangri please track those packages here and not at luci.git
|
Sorry, didn't see notification about this issue until after this quote. If there's no compatibility binary to allow iptables calls while using nftables, both Both |
There is |
You can ignore shorewall, it is an ip(6)tables preprocessor, so no need to port it to nftables. |
iptables-nft can use ipset, esp for places where only access list is ipset. nft has own sets, but traditional ipset command does not bridge the gap |
aside from the command-line iptables/ip6tables, do we also need to keep an eye open for all packages which depend on kmod-ipt.*? |
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
@ldir-EDB0 As ex maintainer, would you mind having a look at #17094? |
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
The next OpenWrt stable release aims to use firewall4 by default. As this uses nftables as backend, miniupnpd will no longer work. Create an iptables and nftables variant of the miniupnpd package so that miniupnpd can be used with either firewall variant. See openwrt#16818 for more info. Signed-off-by: Stijn Tintel <[email protected]>
Ok, so apparently I have iptables-zz-legacy 1.8.7 installed not iptables-nft. |
Reflashing and installing correct iptables package over migrated configuration is very likely to work right away. |
The issues with fw4 and nftables are not really related to broken kernel module + userspace choices (it has been long documented everywhere that you need to get rid of the legacy iptables support / modules and use the iptables-nft package to have a nftables-compatible "iptables" command). But even if you have both iptables and nftables in the kernel, things are deterministic: if anything rejects or drops a packet, it gets rejected/dropped. Only if both iptables and nftables agree a packet can be ACCEPTED, will it be ACCEPTED. But even if you are in a system where the kernel was properly configured to be nftables-only, there is a major catch: in nftables, an ACCEPT target is NOT final. It can be turned into a REJECT or something else by a rule that processes that packet later (from another table, connected to the same nftables hook but with a different priority). So, everything works if you're just using iptables-nft everywhere, and no custom tables. But fw4 uses its own table, at which point things can break. You really need to "fw4-erize" everything because of this, it needs to use the fw4 table, and the correct "chains" for fw4. |
You dont know in which order filtering applies, especially if you put up accept rules as final. |
omcproxy needs updating. still using fw3 omcproxy is nicer than igmproxy because it has a luci app. |
Try @aparcar seems that calling fw3 command should be accounted for too. |
Note that fw4 ships an |
the sed thing didn't work, or, better explained, it does work in the sense that it does not throw an error when running omcproxy but the thing is, upgrading my openwrt distro ( turris omnia ) from a november master build ( fw3 ) to yesterday's master build ( fw4 ) made my IPTV stop working ( keeping configuration between the upgrade ). I will troubleshoot this further this weekend and report back. If I believe it is fw3 to 4 related I will post here, if not on the appropriate place. |
Thanks for your reply, this is the output of those commands, it looks like the firewall is completely open?!! Am I at risk or is it the nft tables which is the truth? Very confusing to me with the coexistence. My version of iptables seems to be compatible atleast, but not working well.
|
You have rules in nft |
Ok, thanks, that clarifies the relation between iptables-nft and nft a bit. I still don't get why the rules from fknopd is not properly translated even after installing kmod-ipt-nat kmod-ipt-nat-extra |
no need for any |
so, cant get igmp to work with the latest master for some reason that I am unable to figure out. if I try to use igmproxy instead the state is always unresolved. I have image for 10s and then it stops and this is a sign of multicast traffic not reaching the device. |
so I am sorry for jumping the gun. The issue with igmp traffic has nothing to do with fw3/4 and all to do with this commit: |
The suspicion is that something related might have something to do with it. =======================================
|
I'll unpin this since it happened. For further issues please open individual issues. |
https://github.com/openwrt/packages/blob/openwrt-22.03/net/sqm-scripts/Makefile#L27 Trying to remove those packages does indeed fail:
|
Hello all, Any help would be greatly appreciated. |
Check this: https://forum.openwrt.org/t/nftables-vs-dockerd/132588 |
Like docker corp. |
UP, can I help to resolve the incompatibility with coova-chilli? |
Just link this issue in PR.
|
Hi all, especially @openwrt/packages-write,
for the next OpenWrt release
firewall4
is considered as a replacement of the currentiptables
basedfirewall
package. While the configuration stays within/etc/config/firewall
, packages usingiptables
directly may see trouble.This is a heads up for everyone maintaining such packages but also please post packages here that would be affected so a smother migration is possible.
Compatible with
firewall4
:ppposshshorewallshorewall6shorewall6-liteshorewall-liteHeads up for routing.git: openwrt/routing#731
Heads up for luci.git: openwrt/luci#5409
The text was updated successfully, but these errors were encountered: