Firewall4 is now default... is this totally transparent to users?

I saw 08d9f6e302 just now. So images built now will use firewall4 now I guess. Is there anything users need to do rules wise, or changing a .config or anything?

1 Like

Quite a lot, or you will accidentally get iptables related packages.
I tried modifying my own .config recipe, and disabling sqm, qosify, bcp38 and banip helped to keep iptables disabled.

Additionally, minupnpd defaults to the iptables variant. Nftables variant needs to be selected instead.

Looking at diffconfig and also grepping .config for iptables helps to identify problematic packages ( with menuconfig search work...)

I am sure that most of those get straightened out in the next few days, but right now the resulting image may be weird with both Nftables and iptables.

3 Likes

Ouch, this does not sound straight forward. Maybe it is best to wait as you recommended. Is the point that both iptables and nftables should NOT be allowed to get installed?

PR for packages yet to go.

4 Likes

Issue != PR

That is just the discussion / bug report.

Well, it is a PR issue (alright, words matter) to track progress, along with a couple of others to report and track for LuCI and routing.

Well, if the firewall is nftables based, and you then issue iptables commands to modify it, the results may be unwanted.

The one incompatible feature is apparently ipset, which affects lots of packages like banip, mwan3

(And e.g. SQM depends on iptables)

@hnyman - While we wait for dependencies and packages to get updated, is it safe to build from master with a simple revert of 08d9f6e302?

Should be. Firewall3 is still there.
But that sounds like trying to postpone the inevitable change.

Adapting to (also uncomfortable / not perfect) changes is part of using the development master...

Note that as packages get adapted to "nftables as the default", packages will gradually start defaulting to nftables. So, you will start to need patching packages to still require/use the old iptables.

1 Like

Sounds good. My concern isn't for keeping on a legacy firewall so much as not co-mingling iptables and nftables util things get sorted out by people more knowledgeable than I.

I think I am just using the QoS scripts so once that gets sorted and merged, I will just build without reverting that commit.

Seems like firewall4 broke its dependencies in the latest commit?

 * satisfy_dependencies_for: Cannot satisfy the following dependencies for firewall4:
 *      libucode20210730

Just compile also the updated ucode...
If the buildbots have not yet compiled the ucode libs, it can't be found.

If you install manually both the self-built ucode (all components including the lib) and self-built firewall4 .ipk packages, you need to install ucode components first, so that firewall4 installation then finds the needed packages in place.

1 Like

Mmm but this happened during build for some reason, it downloaded the ucode dist files but dumped that error anyway. Perhaps a race condition because of make -j6, I've seen weird things happen before.

So images built now will use firewall4 now I guess. Is there anything users need to do rules wise, or changing a .config or anything?

I experienced issues after upgrading to firewall4 with settings that work fine with firewall 3. After upgrading and using my current settings, I have no internet access with firewall4 installed. I wonder if it's due to having sw + hw flow offloading enabled, or something else?

If anyone has had the same issue and resolved it, I would be interested in knowing.

Thanks.

I'm still using a pre-fw4 build, but I came across this bug report regarding fw4 not starting with flow offloading while looking to see if there was a fix for broken software flow offloading with ipv6:- https://bugs.openwrt.org/index.php?do=details&task_id=4239

Thanks for that link. Yeah, I didn't try turning off flow offloading. I will also stay on firewall 3 until this is fixed.

I have some odd problem now, my port forwards doesn't work if i come from the internal network. Used to work before.
If i access it from external network it works fine.......

EDIT: Reverted back to an fw3 build, everything is normal again.

Nftables are good but they kill large hash:net ipsets on nearly all home routers.
Ipsets allow subnet intersection, nftables dont.
To overcome this limitation nft auto-merges intervals and this require lots of RAM.
To load 100K records even 256 Mb is not enough
I could load 100K into ipset on a 64 Mb system

I also found that log nft target does not work despite nft_log module is loaded
Fortunately its not a problem to use iptables and nftables on single system

I guess further reasons why SBCs like RPi4 or R4S and x86es are the best choice for routing modern connections. If you need to load lists of 100k networks, it seems like targeting something with at least 2GB would be smart.

In case, package "firewall" is explicitly excluded during "make menuconfig", will usage of "private" iptables rules still work ?
There are non-standard packages, which rely on special iptables rules. I.e. intercepting squid, or coova-chilli.
Actually, it works for me, to unselect firewall, and run my own, custom firewall.sh, containing iptables rules.