I'm watching this banip with interest and I'd like to thank the developer in passing. It is installed on OpenWrt 23.05.0 with its luci interface.
I'd just like to limit incoming IPs to a single country (France) without limiting outgoing IPs in any way. I understand that “Default Block Policy” must be set to “WAN-Input-Chain”. However, testing via a Tor browser whose exit node is not in France, I get the login screen of my haos server. What's wrong?
Hi everyone,
with the latest update of banip with its UDP flood protection, I am no more able to watch multicast fluxes from my ISP, I suppose I have to rise the limit of ban_udplimit which is set by default at 100/s, how should I set the limit knowing I have some fluxes at around 24 mbits/s ?
EDIT: as a side note, the upper limit of 500 packets/s proposed in luci is far too low which means the value will have to be modified manually in the configuration file.
Maybe we allow a lower Limit of "0" to disable such safeguards at all? Anyway, please provide a suitable range for such Services (I have No experience with that). Thanks!
To be honest, I do not know which value to recommend as it depends on:
the number of connected clients
the stream bitrate
presence or absence of quickleave
possible impacts of quick zapping (how the client is behaving)
Values between 5000 and 7000 seem to do the trick in my case.
From my perspective, I would recommend to:
update the wiki page with the new options added in banip 0.9.5 and the possible impact in multicast streams
add an option (a bit more development) for not counting packets going to addresses included in the range 224.0.0.0/4 in IPv4 or coming from the addresses included in the range ff00::/8 in IPv6 in banip luci web page
Just point the backup directory to a mounted drive and directory on the router.
AdBlock and BanIP has very different use case. They are not the same and should be used independently of each other. BanIP is not a replacement for adblocking, and AdBlock is not a replacement for IP blocking.
What exactly do you mean? Blocking incoming IPs from a certain country but your network/router will still be able to access those IPs?? You don't need a VPN for that. That can work out of the box with BanIP if properly configured.
That seems to have fixed the Firewall Log tab, but the Processing Log tab is still broken as shown above. I've tried deleting browser cache, deleting cookies, deleting the Luci index on the router and restarting uhttpd, but none of it has helped
The error appears to be caused by the fact that this file doesn't exist:
/luci-static/resources/tools/views.js
But I don't know why it's even looking for this file. Can anyone help me to work out what I've broken?
Is anyone actually able to enable all of the blocklists without completely destroying the performance of their router?
I'm running OpenWrt on an x86 mini PC, so no shortage of CPU power or memory, but when I add some of the larger sets the performance of the firewall for forwarded traffic completely tanks, packets are lossed left right and centre, and the internet connection basically becomes unusable. Here's a Thinkbroadband monitor plot, with the problem shown very obviously during a period where the total number of IPs in my sets was around 300,000:
If I disable some of the larger sets (e.g. becyber and pallebone) to keep the number of IPs below 100K, performance returns to normal.
This seems to be an nftables issue, and I originally reported problems in this area here, but I've never seen anyone else complain about it so I'm wondering if it's something that's specific to x86, or even specific to my particular router.
I'm wondering if it's actually other things on my router that are triggering the slowdown when these large sets are present, because it's certainly true that nft commands (listing tables/chains, adding elements to other sets etc.) slow to a crawl when these large sets are present. I have dnsmasq configured to populate several sets automatically, so maybe it's that?
It looks like at least one other person has noticed the poor performance that I described in my other thread, and they also were able to get the netfilter developers to fix at least some of the issues:
I think I'll just have to wait for the next version of OpenWrt before testing again to see if things have improved.
Edit: Just as proof that I'm not imagining things , when the performance tanked yesterday there were errors like this in my syslog:
Thu May 2 16:01:03 2024 kern.err kernel: [605087.575869] rcu: INFO: rcu_sched self-detected stall on CPU
Thu May 2 16:01:03 2024 kern.err kernel: [605087.581663] rcu: 0-....: (5999 ticks this GP) idle=235/1/0x4000000000000000 softirq=11246206/11246206 fqs=2999
I'm not sure the symptoms here match the ones I observed and reported. The slowness i saw was in the nft userspace component. There was also an issue with memory consumption spikes when loading sets. You are describing slowness in actual filtering which i haven't seen. My best guess is that you have too much processing in the forwarding chain which your CPU cannot handle.
Yeah, it's quite possible I'm seeing two separate problems at the same time.
As you say, the poor routing/filtering/forwarding performance isn't something I've seen anyone else report. If it were simply a lack of CPU power I'd expect loads of people to be hitting similar issues - my x86 box has bags of CPU resources compared to the more common types of units OpenWrt runs on. Unless this is in fact something specific to x86.
I do have quite a lot of rules, but I'm pretty sure I tried removing all my custom rules last time I looked at this and it made no difference at all
Unfortunately I can't do any testing right now because doing so kills the connection and my family will complain. I might be able to do some testing on Monday when I'm here on my own.
Is there a reason that the Luci UI only allows negative values for chain priority ?
I prefer to run with priority set to "filter +10" ( e.g. 10 since filter is 0 ) so that IP filtering happens AFTER the fw4 rules. This skips the set filtering for new connections that are just going to be blocked anyway. Performance wise there is not much difference since I am not flooded with blocked traffic but it greatly reduces log noise. For instance I have IOT cruft that constantly phones home to blocked servers -- rather than see this every 10 minutes I would rather just block WAN access for the POS devices.
That works great but any time I use the GUI it wipes out my config setting and restores default priority of -100.
BTW: Great work. Really like the per chain list selection and the fact that you can load the sets in a couple minutes without patching the kernel to fix the @#$ OOM bugs. Only thing I miss from loading my own tables is lack of output chain but I suppose if router itself is compromised it would be easy enough to disable firewall.
