No, I've never used it like that, but it sound reasonable. I'll add a positive "10" with the next LuCI update.
1 Like
Fantastic. Thank you.
In preparation for banIP version 1.0, I would like to improve the readme to make it easier for users to get started with banIP. It would be great if other banIP users could support me here.
For this purpose, I have put the current readme in a separate repository:
Please have a look at what we could improve.
Contributions in the form of Issues or pull requests to improve the readme are very welcome!
Thank you very much for your support!
Dirk
5 Likes
Hi there,
Sometimes banip cease to work or the blocklist are not well loaded... I don't think it happens often but I realize it always when I look into Luci for something else.
Is there a watchdog or something to alert us if banip is not well running?
Or may-be a way to reboot/reload it every week or so?
thanks
System > Scheduled Tasks,
You can enter the following:
00 12 * * 6 /etc/init.d/banip start
01 12 * * 6 /etc/init.d/banip reload
2 Likes
I did some more testing this morning and I'm pretty sure it's the slow userspace nft commands that are causing my problems when these large sets are in place.
Basically if these sets are present nft userspace commands that maniupate sets will run incredibly slowly while pegged at 100% CPU, and if enough of these commands end up running concurrently too much CPU resource will be consumed and routing performance nosedives.
I have a couple of scripts which run very simple nft commands to manipulate some sets (totally unrelated to the banIP sets), and they run every minute. When the large banIP sets are present these commands take too long to complete, while each one consumes 100% CPU on one core, and over time the processes start to stack up. When combined with any significant traffic and the resultant CPU usage from SQM (I'm on a symmetric 1GB connection), the elevated CPU usage starts to cause a problem.
I think I made it even worse the other day by repeatedly tinkering with the banIP config at the same time - every change to the settings runs userspace nft commands to manipulate the banIP sets, which take ages to complete and consume 100% of a CPU core while doing so, and this just makes the problem even worse (especially if you change the config again before the last set of nft commands have finished!) until all CPU resource is consumed and the router basically stops working.
Performance seems to be fine in the presence of the large banIP sets as long as I don't run any nft commands to create sets or add/delete elements from them.
1 Like
Some issues with nft userspace can be worked around. Maybe post your custom scripts here and I'll see if a workaround is possible with them.
The script is pretty simple - it looks for upnp ports associated with gaming, and if it finds any it adds them to a set. I then have some other firewall rules that look for packets associated with the ports in the set and set their DSCP tag accordingly.
The script runs every minute via a cron job and uses these nft commands:
# Make sure the set exists (create it if it doesn't already exist, no-op otherwise)
nft add set inet fw4 $set_name { type inet_service\; timeout 120s \; }
# Get the contents of the set
nft list set inet fw4 $set_name
# Delete a port from the set
nft delete element inet fw4 $set_name { $port }
# Add a port to the set
nft add element inet fw4 $set_name { $port }
Annoyingly I have to do the delete/add for existing elements that need to stay in the set, because unlike with ipsets there's no way to just "touch" an entry and reset its timeout.
Do you actually need this command? Listing contents of a set may be slow if it has a lot of elements and may load the CPU.
# Delete a port from the set nft delete element inet fw4 $set_name { $port } # Add a port to the set nft add element inet fw4 $set_name { $port }
It may be faster to remove the set and add a new set rather than manipulating elements.
Also, I'm not sure if banIP stores its sets in the fw4 table or not. If it does then manipulating sets in that table will be slow and you'll be by far better off using another table.
Functionally it doesn't matter whether the port is already in the set or not. It's been a while since I wrote the script, but I think this is only there so I can log when I add a new port to the set that isn't already in it. I guess I could live without that logging.
Interesting. You'd think that would be slower, but nothing surprises me any more with these nft commands!
It doesn't - the banIP sets are in a different table (inet banIP), but this doesn't seem to make any difference to the performance.
@antonk @tievolu these things are unrelated to banIP, please discuss such topics outside of this dedicated support thread - thanks.
2 Likes
I am so glad you brought that up. I had a similar question about the rules priority that this answers.
@dibdot - Will there still be an option to toggle back in case someone wants to have verbosity for testing / rule troubleshooting purposes, etc?
Also, I did have one suggestion for future versions. Having all the FQDNs for the list providers automatically included in the whitelist. I discovered in earlier versions that some of the list providers servers were blocked by my Geo choices because of being hosted in different countries. I started manually adding them to the whitelist, but it would be nice if they were already excepted with fresh installs of BanIP.
Thanks
@dibdot the "Save & Apply" and "Save" is missing somehow.
This is a fresh build (custom build) using all the latest from snapshot (openwrt/main) and all latest packages.
Also this is a fresh config, configuring setup from scratch. Tried it on Edge, Chrome, Firefox and Safari. Cleared caches and tried private/incognito. All giving same result.
Also tried 3 different themes, all same no "Save" buttons.
That's not a bug, it's a feature 
, see ...
... just use the "Reload", "Restart" buttons ... e.g. this saves a needless "Save & Apply"/Reload run after you have changed nft parameters which requires a restart.
2 Likes
Of course, it's just an additional select box entry, the default (-100) doesn't change.
Just limit the feed to wan_input and wan_forward, an allowlist entry is not required.
1 Like
Ohhh.. got it.. it's just confusing when doing it the first time since most peeps are used to the "Save & Apply" buttons.. hahahaha
I’m running banip 0.9.5-3. I’m seeing about 5-10 blocked invalid ct packets per minute on a relatively idle connection with few devices.
I have a 2 port router running OpenWrt with vlans where banip is installed and a dumb AP also with OpenWrt installed.
Any clue as to what might be causing this?
Last Run action: reload, log: logread, fetch: uclient-fetch, duration: 0m 6s, date: 2024-05-08 20:28:13
:::
::: banIP Set Statistics
:::
Timestamp: 2024-05-08 20:44:08
------------------------------
blocked syn-flood packets : 0
blocked udp-flood packets : 0
blocked icmp-flood packets : 0
blocked invalid ct packets : 140
blocked invalid tcp packets: 0
----------
auto-added IPs to allowlist: 0
auto-added IPs to blocklist: 0
Set | Elements | WAN-Input (packets) | WAN-Forward (packets) | LAN-Forward (packets) | Port/Protocol Limit
---------------------+--------------+-----------------------+-----------------------+-----------------------+------------------------
allowlistv4MAC | 0 | - | - | ON: 0 | -
allowlistv6MAC | 0 | - | - | ON: 0 | -
allowlistv4 | 1 | ON: 0 | ON: 0 | ON: 0 | -
allowlistv6 | 1 | ON: 0 | ON: 0 | ON: 0 | -
dohv4 | 1340 | - | - | ON: 0 | tcp: 80, 443
dohv6 | 909 | - | - | ON: 0 | tcp: 80, 443
torv4 | 797 | ON: 0 | ON: 0 | - | -
torv6 | 401 | ON: 0 | ON: 0 | - | -
blocklistv4MAC | 0 | - | - | ON: 0 | -
blocklistv6MAC | 0 | - | - | ON: 0 | -
blocklistv4 | 0 | ON: 0 | ON: 0 | ON: 0 | -
blocklistv6 | 0 | ON: 0 | ON: 0 | ON: 0 | -
---------------------+--------------+-----------------------+-----------------------+-----------------------+------------------------
12 | 3449 | 6 (0) | 6 (0) | 10 (0)
Just enable pre-routing logging and check the firewall logs.
1 Like
Hmm. I doubt this is a banIP issue. My ISP has been “odd” lately. Short and inconsistent DHCP lease times, an outage yesterday and now this.
Looks like a reset every 5-6 seconds primaraly from the same IP block but not always. Anyway, thanks for the quick response!
Wed May 8 21:41:31 2024 kern.warn kernel: [127938.478046] banIP/pre-ct/drop: IN=eth0 OUT= MAC=REDACTED SRC=79.110.XX.XXX DST=REDACTED LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=25407 PROTO=TCP SPT=46919 DPT=6740 WINDOW=1200 RES=0x00 RST URGP=0
Edit:
I banned the entire /24 (owned by the same hosting company) and all is quieter now. If it persists I’ll report it. This feature is a welcome addition. Thank you!
The release notes for 0.9.5-5 say:
it's now possible to disable the icmp/syn/udp safeguards in pre-routing - set the threshold to '0'.
I installed 0.9.5-5 along with the latest luci companion package, but there doesn't seem to be a way to accomplish the above in the GUI, unless I'm missing something?