Trying to concentrate firewall4 discussion in one point.
Currently it is scattered around github commits/issues, some device threads.
2 Likes
Incomplete list of issues/technical debts
A improve soft offload device list heuristics (add pppoe-wan)
B improve hard offload device list heuristics (add docker0)
C offload glitch - losing hardware offload states without trail seems fixed in 24.10.1
D offload glitch - hardware offload UDP re-ordering (might be MTK related) PR#64
E conntrack flushing at firewall start in empty ruleset from fw3 is missing PR61
F implement nftrace somehow like a checkbox PR 60
G some BSD fugitives are not impressed about CT lasting when original rule is gone - we need similar tracking.
H add proper vmap and goto parsing to luci status
I show unparsed nft list ruleset from nftables-nojson saving X00kB uncompressed for small devices
J do not emit empty base chains, hooks take little but CPU time, probably adapting Gargoye FW patch parts. Lets talk about firewall4 (default nftables firewall) - #5 by lantis1008
K from gh issues - add usermode conntrackd nat helpers support
L adjust package dependencies to enforce nftables xor ip/eb/arptables-zzz-legacy (xtables nl socket in general)
M implementation gap - no filtering on ttl/hoplimit necessary to keep ip6 nd in house
N deleting flowtable flushes offloaded states, either kernel must keep them or we avoid buggy statement if possible
O flushing ruleset on service stop is confusing. Is it meant to flush ct only? added to PR61
P gap - absent ipsec/policy instrumentation (as the time flows - wg mark neither)
I will edit this post as new issues are found or old ones solved.
7 Likes
thank you @brada4
following this thread for
offload glitch - hardware offload UDP re-ordering (might be MTK related)
as @brada4 highlighted it may be due to firewall4 or it may the mtk ppe offload itself. I wonder if there is a way to narrow it down.
1 Like
A visual issue in LuCI Status / Firewall is that the newer vmap statements cannot be interpreted yet by the page.
3 Likes
Two nice to have from me, although I doubt desirable to the project, is always emitting the dstnat/srcnat chains even if no rules are present, and bringing back the user rules chains.
This makes the firewall a bit uglier with lots of empty chains but it does make things more clear for an idiot like me.
I know the advice is to make my own chains with priority-1 however this causes weird interactions with verdicts.
No this is not (easily) implementable via the rule pre/post-pend options as I then have to dynamically find all the chains, zones, devices etc.
Don’t know if it meets what you were looking for to add to the list.
Both options are defaulted off and available via firewall.defaults options always_emit_nat_zones and emit_user_rule_chains
1 Like
My three pet gripes:
-
Make iptables-nft the default instead of the ludicrous iptables-zzz-legacy for when a package has iptables as a dependency. The current situation breaks all sorts of things. It is almost as if the legacy version was made the default just out of spite for all the people in favour of the migration to nftables.
-
Sort out the silly situation with "ipsets". The ipset package was an extension to iptables to support sets of ip addresses.
Nftables has its own native handling of sets (nftsets) that is more powerful as it supports generalised sets and not just ip addresses.
But fw4 has pretend ipsets to emulate the legacy ipset package and hide nftsets, even going to the lengths of messing with compile and config options of dnsmasq to make the deception work. It is a mess! Even worse, if a package wants to set up dnsmasq to populate an nftset, it has to go with the convoluted ipsets emulation, whereas on every other Linux distro it just sets up a standard dnsmasq nftset support..... So, once again it is almost as if this was done to spite those in favour of the migration to nftables.... A cynical view I know, but it is born out of frustration. -
All packages that use iptables should be deprecated and the maintainers put on notice that the packages will be removed on the next major release unless migrated. It has been years now and there has been little or no migration effort done on these old legacy packages.
8 Likes
1 is here.
-- Time to to drop iptables-zz-legacy et-al
Absolutely welcome if there is solution preventing xt / nft iptables mixing together
2 nftsets are still slow to add/remove elements when they grow,
3. For redhat it took 8 years between introducing iptables-nft only to add warning about xt_bridge deprecation. We are slightly behind industry to put it mildly
Yes that could be so, but my point is that fw4 pretends it is using ipsets when it is actually using nftsets. On top of this, Dnsmasq has been bodged about with to make the pretend ipsets work.
The ipset package is independent of iptables, it is very simple and provides a fast database of ip addresses. Potentially it could be made to work with nftables to speed things up with very large dynamic lists of ip addresses, but this is not even worth looking at with the current state of Dnsmasq in OpenWrt.
I derived item L from your post, to make sure we dont get broken installations and make legacy table install hopefully unbearably complex.
nftrace example, i could not think better way to have default survive serial console.
feedback welcome.
@brada4 any intention to PR this?
https://github.com/brada4/firewall4/commit/aec0dc5606ad84efb2b31dd7c0b797f6cc513828
1 Like
It is layered on top of https://github.com/openwrt/firewall4/pull/59
I am trying to split earlier massive patch into few incremental patches.
It helps to work around offload glitches, i know
Please test if possible item E based on semidocumented upstream feature illitrate reader.
would be great if
Could be backported to 6.12, I tried it on a standard linux install and it did improve performance after running the commands. eg...
nft add table bridge filter
nft add flowtable bridge filter fb \ { hook ingress priority 0\; devices = { lan1,lan2,lan3,lan4 }\; }
nft 'add chain bridge filter forward { type filter hook forward priority filter; policy accept; }'
nft add rule bridge filter forward ct state established flow add @fb
Thats slightly different, a substitute for bridger package.
btw ct state & (6) ^ (6) ne 0 flow add @zzz accept
Might be a red herring, but seems mss fixup unnecessarily checks ?ifname 2x on udp packet initiating offload.
Can somebody with wan mtu 1500 check that disabling mtu fixup eases udp reordering issue?
Any thoughts on why the firewall fully reloads on interface ifupdate compared to fw3? That is just painful 
I know the code is just doing what it’s doing, but why the change?
1 Like
ct kinda stays? flowtable not 
this line kills the states
Would this be a good place to note that altering TTL in fw3 was easier than with fw4?
It was a LuCI/UCI config before in fw3, now it's an obscure method to add an NFT rule to a folder in fw4.
Well, include edit box is absent.
Sub-topic of item N - ttl/hl was never instrumented.