But I still see an number of modules for iptables where I suspect that those came in by installing legacy packages:
bcp38: I rewrote the script to only use nftables, but I assume it is still installing unnecessary iptables modules
crowdsec-firewall-bouncer: I suspect this package to install more than needed dependencies as the bouncer can be configured to use either iptables or nftables and I think it installs iptables in any way.
Those are the suspected modules:
At the moment the router is rock stable, but I assume with updates og the two packages I should get rid of the six suspicios modules?
Is there any impact in still having the modules loaded?
My guess is that neither of these packages have been updated for 22.3.
Bp38 has ipset as a dependency so you would need to install iptables-nft before installing bp38.
No rewriting would be needed.
The other package will be similar.
thanks for the answer
I'll do a deinstall on those two packages and check if the iptables dependencies go away this evening.
Then after installing iptables-nft I assume the rules from bcp38 shall pop up inside nftables chain.
Actually I'm unsure about bcp38 as it uses custom rule chains in fw3 but I already have a new nft based version made myself which is creating a seperate table (which works fine for me).
The Crowdsec seems to be a bit more complex but as I just want to get the dependencies away, iptables-nft may work.
I did try to do as advised but it does not really solve the problems.
for bcp38 ipset is defined as a dependency and is always installed. Using iptables-nft did not prevent installation of ipset. Also, bcp38 makes use of ipset nomatch feature which is not supported by nftables sets.
As a solution I wrote an updated script using nft commands. I'm willing to do a pull request but I have a few answers about what is expected by Openwrt developers, e.g.: must the packes still be compatible with fw3/iptables?
Digging deeper into bcp38 rules I realized that this filtering may also be done with a standard uci firewall rule as long as someone is not using private subnet on wan (e.g. double nat). Doing so is even more efficient. I'm also willing to update documentation (if I figure out how to do that).
Crowdsec boucer seems to be a bit more complicated. I did my solution with manuall updates on nftables and its working.
As I like the idea of Crowdsec, I'm willing to take part and create a lightweight bouncer package for use with nftables.
@bluewavenet: where can I get some help and questions answered so I do start volunteering the right way?
Yes, that is correct. In turn ipset has "iptables" as a dependency. By default, this means iptables-zz-legacy will be installed (This is a known issue in 22.03 and above - but that is another story).
So for full nft support you must pre-empt the iptables dependency by pre-installing iptables-nft.
If you do not do this you will end up with a hybrid mashup of independent iptables and nftables rules with unpredictable results.
Once iptables-nft is installed, any packages with iptables dependencies will work fine.
For example ipset uses kmod-ipt-ipset and libipset13, both of which happily work with iptables-nft.
That is going to rule out a significant number of installations. Double nat is very common and not an issue in the slightest. Only those obsessively concerned with eliminating every microsecond of latency (eg online gamers, bitcoin miners etc) will even notice double nat from the end user point of view, so it is not a good idea to depend upon not having double nat.
Basically I meant that this might be a topic for documentation. For those not using/having private ip on wan, defining bcp38 filter by standard rules might by an alternate solution (instead of adding the bcp38 package).
I just submitted my first pull request for an updated bcp38 package based on just nftables. Awaiting feedback now.