Skip to content
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

Open
25 of 39 tasks
aparcar opened this issue Oct 6, 2021 · 182 comments
Open
25 of 39 tasks

Certain upstream switch to firewall4 aka nftables instead of iptables #16818

aparcar opened this issue Oct 6, 2021 · 182 comments

Comments

@aparcar
Copy link
Member

aparcar commented Oct 6, 2021

Hi all, especially @openwrt/packages-write,

for the next OpenWrt release firewall4 is considered as a replacement of the current iptables based firewall package. While the configuration stays within /etc/config/firewall, packages using iptables 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:

Heads up for routing.git: openwrt/routing#731
Heads up for luci.git: openwrt/luci#5409

@feckert
Copy link
Member

feckert commented Oct 6, 2021

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.
I did see that there was a firewall4, but I wasn't aware that it should already include as default firewall backend in the next release!

@aparcar
Copy link
Member Author

aparcar commented Oct 6, 2021

It's possible, an idea to be discussed. There is no definite decision yet, however ideally maintainer start looking at firewall4 to have an idea what could change. Long term there might be a firewall5 package using eBPF things are moving :)

@ldir-EDB0
Copy link
Contributor

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.
miniupnpd has nftables support, the integration into fw4 will need looking it.

@tohojo
Copy link
Contributor

tohojo commented Oct 6, 2021

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 sqm-scripts and bcp38 contain iptables invocations.

@feckert
Copy link
Member

feckert commented Oct 6, 2021

Also acme does some iptables command

done
iptables -I input_rule -p tcp --dport 80 -j ACCEPT -m comment --comment "ACME" || return 1
ip6tables -I input_rule -p tcp --dport 80 -j ACCEPT -m comment --comment "ACME" || return 1
debug "v4 input_rule: $(iptables -nvL input_rule)"
debug "v6 input_rule: $(ip6tables -nvL input_rule)"
return 0

@tohojo
Copy link
Contributor

tohojo commented Oct 6, 2021 via email

@dibdot
Copy link
Contributor

dibdot commented Oct 6, 2021

adblock is purely DNS and doesn't use any direct iptables calls. Maybe simple-adblock is affected here - I don't know.

@alexeys85
Copy link
Contributor

collectd iptables plugin depends on libiptc as far as I know

@luizluca
Copy link
Contributor

luizluca commented Oct 6, 2021

I would expand the list a little further:

feeds/packages $ grep -E "(ip6?tables(-save|-restore)?( |$|\"|'|\))|lib/iptables|\+iptables)" -R */ | cut -d/ -f2 | sort -u
acme
adblock
apfree-wifidog
banip
bcp38
collectd
coova-chilli
dockerd
etherwake-nfqueue
fail2ban
frr
fwknop
gnunet
https-dns-proxy
jool
keepalived
libreswan
miniupnpd
mwan3
podman
pppossh
redsocks
shadowsocks-libev
shorewall
shorewall6
shorewall6-lite
shorewall-lite
simple-adblock
sqm-scripts
strongswan
trafficshaper
uacme
v2raya
vpnbypass
vpnc-scripts
vpn-policy-routing
wifidog
xtables-addons

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.

@aparcar
Copy link
Member Author

aparcar commented Oct 6, 2021

@luizluca the adblock packages mentions iptables in it's readme

adblock does not use error prone external iptables rulesets

@aparcar
Copy link
Member Author

aparcar commented Oct 6, 2021

@stangri please track those packages here and not at luci.git

https://github.com/openwrt/packages/tree/master/net/vpn-policy-routing
https://github.com/openwrt/packages/tree/master/net/vpnbypass

I've also started working on a fork of the former called pbr and it's also iptables-dependent.

@stangri
Copy link
Member

stangri commented Oct 6, 2021

@stangri please track those packages here and not at luci.git

https://github.com/openwrt/packages/tree/master/net/vpn-policy-routing
https://github.com/openwrt/packages/tree/master/net/vpnbypass
I've also started working on a fork of the former called pbr and it's also iptables-dependent.

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 vpn-policy-routing and vpnbypass are in trouble. They are heavily iptables dependent and it may take me a while to find the time to figure out the switch to nftables.

Both https-dns-proxy and simple-adblock are good to go.

@aparcar
Copy link
Member Author

aparcar commented Oct 6, 2021

There is iptables-nft which is however not available upstream at this point. I'm currently trying to run a CI to offer binaries including it, will post on updates.

@jow-
Copy link
Contributor

jow- commented Oct 7, 2021

You can ignore shorewall, it is an ip(6)tables preprocessor, so no need to port it to nftables.

@brada4
Copy link

brada4 commented Oct 10, 2021

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

@pmelange
Copy link
Contributor

aside from the command-line iptables/ip6tables, do we also need to keep an eye open for all packages which depend on kmod-ipt.*?

@aparcar aparcar pinned this issue Oct 20, 2021
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 7, 2021
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]>
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 7, 2021
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]>
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 7, 2021
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]>
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 7, 2021
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]>
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 7, 2021
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]>
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 8, 2021
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]>
@stintel
Copy link
Member

stintel commented Nov 8, 2021

miniupnpd has nftables support, the integration into fw4 will need looking it.

@ldir-EDB0 As ex maintainer, would you mind having a look at #17094?

stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 8, 2021
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]>
stintel added a commit to stintel/openwrt-packages that referenced this issue Nov 8, 2021
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]>
@shikasta-net
Copy link

Ok, so apparently I have iptables-zz-legacy 1.8.7 installed not iptables-nft.

@brada4
Copy link

brada4 commented Mar 20, 2023

Reflashing and installing correct iptables package over migrated configuration is very likely to work right away.

@hmh
Copy link
Contributor

hmh commented Mar 20, 2023

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.

@brada4
Copy link

brada4 commented Mar 21, 2023

You dont know in which order filtering applies, especially if you put up accept rules as final.

@PedroM4
Copy link

PedroM4 commented Mar 22, 2023

omcproxy needs updating. still using fw3
https://github.com/openwrt/openwrt/blob/ec6293febc244d187e71a6e54f44920be679cde4/package/network/services/omcproxy/files/omcproxy.init

omcproxy is nicer than igmproxy because it has a luci app.

@brada4
Copy link

brada4 commented Mar 22, 2023

Try sed -iBAK "s/(fw3/(fw4/g" /etc/init.d/omcproxy and tell if it works

@aparcar seems that calling fw3 command should be accounted for too.

@jow-
Copy link
Contributor

jow- commented Mar 22, 2023

Note that fw4 ships an fw3 compatibility symlink. The omcproxy init script should work as-is with both fw3 and fw4.

@PedroM4
Copy link

PedroM4 commented Mar 22, 2023

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 ).
It may be because of mwan3. I was/am diverting igmp traffic using mwan3 so it may be because of that.

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.

@sum32
Copy link

sum32 commented Mar 25, 2023

iptables-nft-save -t nat

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.

root@r1:~# iptables --version
iptables v1.8.7 (nf_tables)
root@r1:~# iptables-nft-save -t filter
# Generated by iptables-nft-save v1.8.7 on Sat Mar 25 18:39:33 2023
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Sat Mar 25 18:39:33 2023
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them
root@r1:~# iptables-nft-save -t nat
# Generated by iptables-nft-save v1.8.7 on Sat Mar 25 18:39:57 2023
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Sat Mar 25 18:39:57 2023
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them
root@r1:~#
root@r1:~# iptables --version
iptables v1.8.7 (nf_tables)

@brada4
Copy link

brada4 commented Mar 25, 2023

You have rules in nft nft list ruleset, and you can observe renderings of iptables rules there.
iptables-nft will add rules with stats counter in a way they can be read back via same legacy-looking interface, but native rules will be invisible there.
Most linux distros took the path of shipping -nft wrappers in place of legacy thing, none has solid nft-based framework so far. OpenWRT took a bit more radical flag in hands.

@sum32
Copy link

sum32 commented Mar 25, 2023

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

@brada4
Copy link

brada4 commented Mar 25, 2023

no need for any kmod-ipt-* at all.
if you do iptables-nft-save - do you se fwknop tables?

@PedroM4
Copy link

PedroM4 commented Mar 25, 2023

so, cant get igmp to work with the latest master for some reason that I am unable to figure out.
mwan3 is not installed. configuration has not changed from end last year fw3 master.
omcproxy results in this:
root@gateway:~# ip mroute
(192.168.89.100,239.255.255.250) Iif: lan3 State: resolved

if I try to use igmproxy instead the state is always unresolved.
going to open a thread on the forum regarding this.

I have image for 10s and then it stops and this is a sign of multicast traffic not reaching the device.

@PedroM4
Copy link

PedroM4 commented Mar 27, 2023

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:
openwrt/openwrt@738b04c
I was able to track it down to it. Already posted a message there.

@57382
Copy link

57382 commented Apr 20, 2023

The suspicion is that something related might have something to do with it.
openwrt/openwrt#12429
400
iptables/firewall3

=======================================

200
nftables/firewall4
Seems to have serious performance flaws. For IPQ40XX

@aparcar
Copy link
Member Author

aparcar commented Apr 21, 2023

I'll unpin this since it happened. For further issues please open individual issues.

@aparcar aparcar unpinned this issue Apr 21, 2023
@baldurmen
Copy link

baldurmen commented May 7, 2023

sqm-scripts has been marked as OK in the tracking list in this issue, but as of 22.03.5 it still depends on some iptables packages:

https://github.com/openwrt/packages/blob/openwrt-22.03/net/sqm-scripts/Makefile#L27

Trying to remove those packages does indeed fail:

$ opkg remove iptables-mod-ipopt iptables-zz-legacy
No packages removed.
Collected errors:
 * print_dependents_warning: Package iptables-mod-ipopt is depended upon by packages:
 * print_dependents_warning: 	sqm-scripts
 * print_dependents_warning: These might cease to work if package iptables-mod-ipopt is removed.

 * print_dependents_warning: Force removal of this package with --force-depends.
 * print_dependents_warning: Force removal of this package and its dependents
 * print_dependents_warning: with --force-removal-of-dependent-packages.
 * print_dependents_warning: Package iptables-zz-legacy is depended upon by packages:
 * print_dependents_warning: 	sqm-scripts
 * print_dependents_warning: These might cease to work if package iptables-zz-legacy is removed.

 * print_dependents_warning: Force removal of this package with --force-depends.
 * print_dependents_warning: Force removal of this package and its dependents
 * print_dependents_warning: with --force-removal-of-dependent-packages.

@tam481
Copy link

tam481 commented May 10, 2023

Hello all,
I suspect I misunderstood but I installed iptables-nft and ip6tables-nft, removed iptables-zzz-legacy and reinstalled dockerd on my OpenWrt x86 system but I still can't access any of the containers (I'm using FW4 of course). I read somewhere that adding "iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 443" fixes the issue for the specified port(s) but this is a blanket redirecting which with my limited knowledge doesn't make sense because it's forwarding traffic on port 443 to port 443 and does not specify the interface but at least it works for a container that listens on 443 but I can't run the same rule for port 80 because it ends up in an endless redirect to the container.

Any help would be greatly appreciated.

@terrytw
Copy link

terrytw commented May 20, 2023

Hello all, I suspect I misunderstood but I installed iptables-nft and ip6tables-nft, removed iptables-zzz-legacy and reinstalled dockerd on my OpenWrt x86 system but I still can't access any of the containers (I'm using FW4 of course). I read somewhere that adding "iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 443" fixes the issue for the specified port(s) but this is a blanket redirecting which with my limited knowledge doesn't make sense because it's forwarding traffic on port 443 to port 443 and does not specify the interface but at least it works for a container that listens on 443 but I can't run the same rule for port 80 because it ends up in an endless redirect to the container.

Any help would be greatly appreciated.

Check this: https://forum.openwrt.org/t/nftables-vs-dockerd/132588
Also it seems to me that making dockerd use nftables is not terribly complicated, since there are already some people doing it:
https://gist.github.com/goll/bdd6b43c2023f82d15729e9b0067de60
Hope someone got the time to implement it.

@brada4
Copy link

brada4 commented May 20, 2023

Like docker corp.

@tiaomail
Copy link

UP, can I help to resolve the incompatibility with coova-chilli?

@brada4
Copy link

brada4 commented Jan 26, 2024

Just link this issue in PR.
One coova issue: #23092

  • xt_coova will not wotk with iptables-nft or nft
  • do you plan to adjust dependency to iptabled-nft or port iptables ruleset to new nftables chains?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests