Can you post the /etc/config/banip here?
I have the same one since a. Month, works great and works still great.
Thank you @dibdot for the link
However I to respond to @slh 's claim that
CPU is good for around 200 MBit/s
I have to disagree, here is a speedtest that I've just done right now on a Archer C7 V2
I don't know if it would make it to gigabit, would iperf3 testing be conclusive or too artificial ?
There was another reply that is no longer visible in this thread which suggested googling NFTABLE BENCHMARK
And I found this informative link
Also on the broader subject of router for gigabit WAN, I found this topic
My takeaway from this topic are
CPU time required per packet increase roughly linearly with the number of rules up to the point that the CPU can no longer keep up, drops packets and cause throttling at the source
Nftables requires more CPU time per packet per rule than iptables when filtering by IP address
About 15% worse for the same computer capable of 2.1GPBS throughput, falls to 1.6GBPS at 1000 rules with iptables and 1.4GPBS with nftable
However for port number based filtering the story is very different. Iptables shows significant performance degradation with more ports blocked while nftable shows no such degradation
As an Archer C7 users, I think my solution to be optimal will be to keep as few IPs in the ban list as possible, perhaps I will splice my wan port with a sniffer wiretap, duplicate all traffic to a second router, look for traffic to bad IP addresses and remotely add those IPs to the main router's ban list only when packets from those are being exchanged (sort of like a tripwire arrangement, a few packets may get throught but it should cut off before any transaction is actually completed and will fail)
Also, I think an arrangement to preserve performance will but to place a second archer c7 router in series with my wan port, in bridge mode, and only do IP filtering on that first device, just dropping packets on the ban list and nothing else.
When evaluating throughput estimates, I only look at a device's own performance - NOT at what they might achieve with (software) flow-offloading enabled (as that is at odds with more advanced features (e.g. sqm), has its quirks (e.g. traffic accounting not working) and plain bugs/ instabilities).
My performance claims about ath79 (and extension the c7) are based on my own experiences with the tl-wdr4300/ tl-wdr3600, the immediate predecessor of the archer c7 (802.11n and 8/128, but neither of these affect routing performance), same mips cores (same expected throughput per MHz), but clocked at only 560 MHz, instead of 720 MHz as in the c7-v2. On this (tl-wdr4300) hardware, I can see (plain ethernet routing, no sqm, no software flow-offloading, no PPPoE, no special/ costly settings) a peak performance (at 100% CPU utilization) of around 170-175 MBit/s, however very choppy - you see a distinct saw-tooth patterns in throughput graphs (and lag is noticable!), showing that this is beyond the ar9344's abilities. Based on these experiences, I postulate that the tl-wdr4300 can do around up to 150 MBit/s in practice (just before hitting contention and responding in a saw-tooth fashion), noticably less if PPPoE is needed (120-130 MBit/s), significantly less (~ half) with sqm/cake. Be aware that real-world usage is more complex than dedicated speedtest (which could be offloaded effectively, while 'random' real-world traffic is harder to offload).
Based on this, I extrapolate a throughput potential of 175-195 MBit/s tops for the ~30% higher clocked archer c7 (v2=720 MHz, v3=750 MHz, everything else comparable). These would be the fastest ath79 SOCs we've seen so far, defining the upper ceiling of this target.
Now if you enable software flow-offloading, you can push these figures (for the tl-wdr4300) to roughly 400 MBit/s - but that would be 'cheating'. As mentioned above, flow-offloading comes at a cost (quirks/ bugs), but -more importantly- speedtests (handful of static traffic rules to one/ two remote destinations) are much easier to offload than the much more diverse real-world traffic - and that's before even looking at complications such as complex firewall rules, like banip.
My performance estimates might be a bit conservative or pessimistic, but they are based on real-world testing (not just synthetic speedtests) and relatively close to the truth.
Even with software flow-offloading, 1 GBit/s is faaar beyond the c7's abilities (even half of that would be).
1 Like
Note that this is if you are using multiple rules, like each ip is checked by a separate rule, but with nftables banning a thousand ips should take one rule.
ip saddr @banned drop
1 Like
Thank you for the clarification
My initial question was mainly about how to use banip but maintain my current performance levels by judiciously crafts the firewall rules.
I don't know how SQM and other cpu offloading works in the archer c7. I don't know if any are present, if any are enabled or how to turn them on or off.
I think, to get the maximum performance out of these weak routers we need to develop a way to create variable and controllable real-world traffic loading in both directions and a way to measure performance, throughput, latency, packet mangling and packet loss with high temporal accuracy.
Only then can we find a way to fine tune rules for the absolute minimum and most efficient CPU and other ressources consumption
There should be clear indicators to know when memory, cpu and network resources are exhausted and latency/packet drops and bufferbloat is happenning and send a notification to the administrator that it is happenning.
That way we can attend to the problem and know how often it happens and to what severity.
Else we are flying blind and that can be very frustrating.
Thanks you for clarifying that, I was under the impression that each IP was one rule and each rule increased the cpu load proportionally.
So, does a 1000 IP ban rule evaluates in the same CPU time that a 1 IP ban rule does ?
Does that means there is no performance penalty to leaving enormous amounts of IP address in the ban list even if they're not talking to us ?
provided that the way it's being done is to add addresses to a ban set in nftables, which is the correct way to do it, then yes, it should take O(1) time no matter how big the set, however it takes O(n) space for the n addresses.
Sorry for the late response.
Certainly! The log (as seen in the LuCI interface) after updating to version 0.8.2-6 is rather unspectacular:
Sun Apr 2 11:00:20 2023 user.info banIP-0.8.2-6[26818]: start banIP processing (start)
Sun Apr 2 11:00:20 2023 user.info banIP-0.8.2-6[26818]: nft namespace initialized
Sun Apr 2 11:00:20 2023 user.info banIP-0.8.2-6[26818]: start banIP download processes
Sun Apr 2 11:00:46 2023 user.info banIP-0.8.2-6[26818]: start detached banIP domain lookup
Sun Apr 2 11:00:55 2023 user.info banIP-0.8.2-6[26818]: finished banIP download processes
Sun Apr 2 11:00:55 2023 user.info banIP-0.8.2-6[26818]: start detached banIP log service
Here the output of /etc/init.d/banip status:
::: banIP runtime information
+ status : active (nft: ✔, monitor: ✔)
+ version : 0.8.2-6
+ element_count : 85808
+ active_feeds : allowlistvMAC, allowlistv4, allowlistv6, adawayv4, adawayv6, adguardv4, adguardtrackersv4, adguardv6, adguardtrackersv
6, antipopadsv4, antipopadsv6, darklistv4, deblv4, deblv6, dohv4, dropv4, dohv6, dshieldv4, dropv6, feodov4, firehol1v
4, greensnowv4, firehol2v4, iblockspyv4, iblockadsv4, sslblv4, threatv4, yoyov6, yoyov4, blocklistvMAC, blocklistv4, b
locklistv6
+ active_devices : wan, wan_6 ::: wan, wan_6
+ active_subnets : $subnets
+ nft_info : priority: -200, policy: memory, loglevel: warn, expiry: -
+ run_info : base: /tmp, backup: /tmp/banIP-backup, report: /tmp/banIP-report, feed: /etc/banip/banip.feeds
+ run_flags : auto: ✔, proto (4/6): ✔/✔, log (wan-inp/wan-fwd/lan-fwd): ✔/✔/✔, dedup: ✔, split: ✘, allowed only: ✘
+ last_run : action: start, duration: 0m 27s, date: 2023-04-02 11:00:55
+ system_info : cores: 2, memory: 346, device: Netgear Nighthawk X4S R7800, OpenWrt 22.03.3 r20028-43d71ad93e
And for good measure, here the file /etc/config/banip:
config banip 'global'
option ban_debug '0'
option ban_autodetect '1'
list ban_logterm 'Exit before auth from'
list ban_logterm 'luci: failed login'
list ban_logterm 'error: maximum authentication attempts exceeded'
list ban_logterm 'sshd.*Connection closed by.*\[preauth\]'
list ban_logterm 'SecurityEvent=\"InvalidAccountID\".*RemoteAddress='
option ban_enabled '1'
list ban_trigger 'wan'
list ban_trigger 'wan_6'
option ban_triggerdelay '15'
option ban_deduplicate '1'
option ban_loginput '1'
option ban_logforwardwan '1'
option ban_logforwardlan '1'
list ban_feed 'adaway'
list ban_feed 'adguard'
list ban_feed 'adguardtrackers'
list ban_feed 'antipopads'
list ban_feed 'darklist'
list ban_feed 'debl'
list ban_feed 'doh'
list ban_feed 'drop'
list ban_feed 'dshield'
list ban_feed 'feodo'
list ban_feed 'firehol1'
list ban_feed 'firehol2'
list ban_feed 'greensnow'
list ban_feed 'iblockads'
list ban_feed 'iblockspy'
list ban_feed 'sslbl'
list ban_feed 'threat'
list ban_feed 'yoyo'
list ban_country 'cn'
list ban_country 'ru'
option ban_autoallowlist '1'
option ban_autoblocklist '1'
option ban_allowlistonly '0'
option ban_fetchcmd 'uclient-fetch'
option ban_protov4 '1'
list ban_ifv4 'wan'
option ban_protov6 '1'
list ban_ifv6 'wan_6'
list ban_dev 'wan'
list ban_dev 'wan_6'
Is your issue still persisting?
Unfortunately yes. Checking with the initially reported IP 222.255.27.195, it even shows up in a nft list ruleset | grep 222.255.27.195, so it is present in the set adguardv4 in this case. Said set is present in the chain lan-forward with the entry ip daddr @adguardv4 log prefix "banIP/fwd-lan/rej/adguardv4: " counter packets 0 bytes 0 reject with icmp admin-prohibited, which I interpret as rejecting ICMPv4 packets. This chain again is part of the banIP table, so everything looks fine in that regard.
I haven't changed anything to the the default firewall settings, aside from some port forwards and traffic rules, none of which impact ICMP packets.
Checking the Status/Firewall page, I can see that all traffic in filter chain lan-forward flows through the following two rules:
ct state established,related counter packets 4504 bytes 1383047 acceptoifname != { "wan", "wan_6" } counter packets 213 bytes 16996 accept
Similar for the other two chains wan-{input, forward}.
So I'm guessing it's a misconfiguration of the firewall? Unfortunately I'm basically lost there 
Yup, i'm not sure the issue with your setup. Tried it on my test network and it works on mine.
# /etc/init.d/banip search 222.255.27.195
:::
::: banIP Search
:::
Looking for IP '222.255.27.195' on 2023-04-03 18:19:09
---
IP found in Set 'adguardv4'
Since this is LAN-FWD, router was able to ping the IP 222.255.27.195
# ping 222.255.27.195
PING 222.255.27.195 (222.255.27.195): 56 data bytes
64 bytes from 222.255.27.195: seq=0 ttl=52 time=60.285 ms
64 bytes from 222.255.27.195: seq=1 ttl=52 time=58.887 ms
64 bytes from 222.255.27.195: seq=2 ttl=52 time=59.236 ms
64 bytes from 222.255.27.195: seq=3 ttl=52 time=59.285 ms
64 bytes from 222.255.27.195: seq=4 ttl=52 time=59.407 ms
64 bytes from 222.255.27.195: seq=5 ttl=52 time=59.306 ms
64 bytes from 222.255.27.195: seq=6 ttl=52 time=59.126 ms
^C
--- 222.255.27.195 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 58.887/59.361/60.285 ms
But doing a PING in the LAN side (client), it is being blocked.
ping 222.255.27.195
Pinging 222.255.27.195 with 32 bytes of data:
Reply from 10.10.10.1: Destination net unreachable.
Reply from 10.10.10.1: Destination net unreachable.
Reply from 10.10.10.1: Destination net unreachable.
Reply from 10.10.10.1: Destination net unreachable.
Ping statistics for 222.255.27.195:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
And below is logs generated (with Log LAN-Forward enabled)
Mon Apr 3 18:16:40 2023 kern.warn kernel: [ 68.282147] banIP/fwd-lan/rej/adguardv4: IN=br-lan OUT=eth1 MAC=00:1c:42:bd:13:18:00:1c:42:3c:d0:60:08:00 SRC=10.10.10.190 DST=222.255.27.195 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=57784 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=19
Mon Apr 3 18:16:41 2023 kern.warn kernel: [ 69.300689] banIP/fwd-lan/rej/adguardv4: IN=br-lan OUT=eth1 MAC=00:1c:42:bd:13:18:00:1c:42:3c:d0:60:08:00 SRC=10.10.10.190 DST=222.255.27.195 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=57785 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=20
Mon Apr 3 18:16:42 2023 kern.warn kernel: [ 70.315859] banIP/fwd-lan/rej/adguardv4: IN=br-lan OUT=eth1 MAC=00:1c:42:bd:13:18:00:1c:42:3c:d0:60:08:00 SRC=10.10.10.190 DST=222.255.27.195 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=57786 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=21
Mon Apr 3 18:16:43 2023 kern.warn kernel: [ 71.334733] banIP/fwd-lan/rej/adguardv4: IN=br-lan OUT=eth1 MAC=00:1c:42:bd:13:18:00:1c:42:3c:d0:60:08:00 SRC=10.10.10.190 DST=222.255.27.195 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=57787 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=22
I was having the exact same issue.
Uninstall the banip package and reinstall it back again and everything should work.
Cheers.
Hi,
I'm a recent banIP user, so not much experience from what to expect regarding memory usage and lists sizes.
I'm having a OOM issue when searching for IPs in banip.
I'm running latest openwrt snapshot in Dynalink DL-WRX36 (4x2.2Ghz A53 arm 1GB ram) with banip and addblock.
This is my system idle just after boot and after banip/addblock loads the lists:
(All 4 cores have the same load, so I only posted core#0. Memory and cpu load are normal for banip/addblock loading lists just after boot)
root@D1:~# /etc/init.d/banip status
::: banIP runtime information
+ status : active (nft: ✔, monitor: ✔)
+ version : 0.8.2-6
+ element_count : 309308
+ active_feeds : allowlistvMAC, allowlistv6, allowlistv4, adawayv4, adguardtrackersv4, antipopadsv4, adguardv4, backscattererv4, bogonv
4, darklistv4, deblv4, cinsscorev4, dohv4, edropv4, dropv4, feodov4, dshieldv4, firehol1v4, greensnowv4, iblockspyv4,
iblockadsv4, myipv4, sslblv4, proxyv4, talosv4, nixspamv4, threatviewv4, torv4, threatv4, urlhausv4, uceprotect1v4, ur
lvirv4, yoyov4, webclientv4, voipv4, blocklistvMAC, blocklistv4, blocklistv6
+ active_devices : wan ::: wan
+ active_subnets : xx.xx.xx.xx/xx
+ nft_info : priority: -200, policy: memory, loglevel: warn, expiry: -
+ run_info : base: /tmp, backup: /tmp/banIP-backup, report: /tmp/banIP-report, feed: /etc/banip/banip.feeds
+ run_flags : auto: ✘, proto (4/6): ✔/✘, log (wan-inp/wan-fwd/lan-fwd): ✔/✔/✔, dedup: ✔, split: ✘, allowed only: ✘
+ last_run : action: boot, duration: 2m 53s, date: 2023-04-03 12:24:58
+ system_info : cores: 4, memory: 722, device: Dynalink DL-WRX36, OpenWrt SNAPSHOT r22489-3c3614cec4
All works normal, but just after I do a IP search I get the bellow cpu/ram load and I have to power off the router to get it back:
root@D1:~# /etc/init.d/banip search 1.1.1.1
:::
::: banIP Search
:::
Looking for IP '1.1.1.1' on 2023-04-03 12:45:29
---
Then after some time:
[ 1690.329164] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=nft,pid=30971,uid=0
[ 1690.337333] Out of memory: Killed process 30971 (nft) total-vm:144944kB, anon-rss:142864kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:312kB oom_score_adj:0
[ 1692.436618] oom_reaper: reaped process 30971 (nft), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Lists and their sizes:
root@D1:/tmp/banIP-backup# ls -laS
-rw-r--r-- 1 root root 426371 Apr 3 12:52 banIP.uceprotect1v4.gz
-rw-r--r-- 1 root root 408226 Apr 3 12:52 banIP.urlhausv4.gz
-rw-r--r-- 1 root root 321151 Apr 3 12:51 banIP.adguardv4.gz
-rw-r--r-- 1 root root 303174 Apr 3 12:52 banIP.nixspamv4.gz
-rw-r--r-- 1 root root 242186 Apr 3 12:52 banIP.voipv4.gz
-rw-r--r-- 1 root root 130065 Apr 3 12:51 banIP.antipopadsv4.gz
-rw-r--r-- 1 root root 116211 Apr 3 12:51 banIP.adawayv4.gz
-rw-r--r-- 1 root root 90834 Apr 3 12:51 banIP.backscattererv4.gz
-rw-r--r-- 1 root root 61223 Apr 3 12:51 banIP.deblv4.gz
-rw-r--r-- 1 root root 61050 Apr 3 12:51 banIP.cinsscorev4.gz
-rw-r--r-- 1 root root 43714 Apr 3 12:52 banIP.yoyov4.gz
-rw-r--r-- 1 root root 38936 Apr 3 12:51 banIP.greensnowv4.gz
-rw-r--r-- 1 root root 27467 Apr 3 12:51 banIP.darklistv4.gz
-rw-r--r-- 1 root root 17871 Apr 3 12:51 banIP.adguardtrackersv4.gz
-rw-r--r-- 1 root root 16987 Apr 3 12:52 banIP.iblockspyv4.gz
-rw-r--r-- 1 root root 16919 Apr 3 12:52 banIP.iblockadsv4.gz
-rw-r--r-- 1 root root 13594 Apr 3 12:52 banIP.proxyv4.gz
-rw-r--r-- 1 root root 10164 Apr 3 12:52 banIP.torv4.gz
-rw-r--r-- 1 root root 9282 Apr 3 12:52 banIP.threatv4.gz
-rw-r--r-- 1 root root 9083 Apr 3 12:52 banIP.myipv4.gz
-rw-r--r-- 1 root root 8698 Apr 3 12:51 banIP.firehol1v4.gz
-rw-r--r-- 1 root root 8038 Apr 3 12:52 banIP.webclientv4.gz
-rw-r--r-- 1 root root 8019 Apr 3 12:51 banIP.dohv4.gz
-rw-r--r-- 1 root root 7084 Apr 3 12:51 banIP.dropv4.gz
-rw-r--r-- 1 root root 5929 Apr 3 12:52 banIP.talosv4.gz
-rw-r--r-- 1 root root 4267 Apr 3 12:51 banIP.feodov4.gz
-rw-r--r-- 1 root root 3519 Apr 3 12:51 banIP.bogonv4.gz
-rw-r--r-- 1 root root 2972 Apr 3 12:52 banIP.threatviewv4.gz
-rw-r--r-- 1 root root 2021 Apr 3 12:51 banIP.edropv4.gz
-rw-r--r-- 1 root root 1676 Apr 3 12:52 banIP.urlvirv4.gz
-rw-r--r-- 1 root root 1179 Apr 3 12:51 banIP.dshieldv4.gz
-rw-r--r-- 1 root root 1010 Apr 3 12:52 banIP.sslblv4.gz
drwxr-xr-x 2 root root 680 Apr 3 12:52 .
drwxrwxrwt 21 root root 580 Apr 3 12:55 ..
nft requires a lot of main memory for certain actions ... to limit the search requirements you should limit the used cores by banIP/nft, e.g. set the ban_cores to '2' and try again ...
1 Like
hello, I just switched from release 21 to 22 and installed banip new. I tried to set it up, but it doesn't block any incoming lists, what am I doing wrong?
also when I try to use
root@OpenWrt:/etc/init.d# banip search xxx.xxx.xxx.xxx
it just says: -ash: banip: not found
thx in advance!
so long
edit: config file:
root@OpenWrt:/etc/config# cat banip
config banip 'global'
option ban_debug '0'
option ban_autodetect '1'
list ban_logterm 'Exit before auth from'
list ban_logterm 'luci: failed login'
list ban_logterm 'error: maximum authentication attempts exceeded'
list ban_logterm 'sshd.*Connection closed by.*\[preauth\]'
list ban_logterm 'SecurityEvent=\"InvalidAccountID\".*RemoteAddress='
option ban_enabled '1'
option ban_deduplicate '1'
option ban_loginput '1'
option ban_logforwardwan '1'
option ban_logforwardlan '0'
list ban_country 'af'
list ban_country 'ax'
list ban_country 'al'
list ban_country 'dz'
list ban_country 'as'
list ban_country 'ad'
list ban_country 'ao'
list ban_country 'ai'
list ban_country 'aq'
list ban_country 'ag'
list ban_country 'ar'
list ban_country 'am'
list ban_country 'aw'
list ban_country 'au'
list ban_country 'az'
list ban_country 'bs'
list ban_country 'bh'
list ban_country 'bd'
list ban_country 'bb'
list ban_country 'by'
list ban_country 'be'
list ban_country 'bz'
list ban_country 'bj'
list ban_country 'bm'
list ban_country 'bt'
list ban_country 'bo'
list ban_country 'ba'
list ban_country 'bw'
list ban_country 'bv'
list ban_country 'br'
list ban_country 'io'
list ban_country 'vg'
list ban_country 'bn'
*just shortened here*
option ban_autoblocklist '1'
option ban_allowlistonly '0'
option ban_fetchcmd 'wget'
option ban_protov4 '1'
list ban_ifv4 'wan_indoor'
list ban_ifv4 'wan_outdoor'
list ban_dev 'br-lan.xx'
list ban_trigger 'wan_indoor'
list ban_trigger 'wan_outdoor'
list ban_feed 'backscatterer'
list ban_feed 'bogon'
list ban_feed 'cinsscore'
list ban_feed 'country'
list ban_feed 'darklist'
list ban_feed 'debl'
list ban_feed 'doh'
list ban_feed 'drop'
list ban_feed 'dshield'
list ban_feed 'edrop'
list ban_feed 'feodo'
list ban_feed 'firehol1'
list ban_feed 'firehol2'
list ban_feed 'firehol3'
list ban_feed 'firehol4'
list ban_feed 'greensnow'
list ban_feed 'iblockads'
list ban_feed 'iblockspy'
list ban_feed 'myip'
list ban_feed 'nixspam'
list ban_feed 'proxy'
list ban_feed 'sslbl'
list ban_feed 'stevenblack'
list ban_feed 'talos'
list ban_feed 'threat'
list ban_feed 'threatview'
list ban_feed 'tor'
list ban_feed 'urlhaus'
list ban_feed 'urlvir'
list ban_blockinput 'allowlist'
list ban_blockinput 'blocklist'
list ban_blockinput 'backscatterer'
list ban_blockinput 'bogon'
list ban_blockinput 'cinsscore'
list ban_blockinput 'country'
list ban_blockinput 'darklist'
list ban_blockinput 'debl'
list ban_blockinput 'drop'
list ban_blockinput 'dshield'
list ban_blockinput 'edrop'
list ban_blockinput 'feodo'
list ban_blockinput 'firehol1'
list ban_blockinput 'firehol2'
list ban_blockinput 'firehol3'
list ban_blockinput 'firehol4'
list ban_blockinput 'myip'
list ban_blockinput 'nixspam'
list ban_blockinput 'proxy'
list ban_blockinput 'sslbl'
list ban_blockinput 'talos'
list ban_blockinput 'threat'
list ban_blockinput 'threatview'
list ban_blockinput 'tor'
list ban_blockinput 'urlhaus'
list ban_blockinput 'urlvir'
list ban_blockforwardwan 'allowlist'
list ban_blockforwardwan 'blocklist'
list ban_blockforwardwan 'backscatterer'
list ban_blockforwardwan 'bogon'
list ban_blockforwardwan 'cinsscore'
list ban_blockforwardwan 'drop'
list ban_blockforwardwan 'dshield'
list ban_blockforwardwan 'greensnow'
list ban_blockforwardwan 'iblockspy'
list ban_blockforwardwan 'sslbl'
list ban_blockforwardwan 'urlvir'
option ban_autoallowlist '0'
edit2: active (nft: ✘, monitor: 
) is that normal?
I don't know what router is in place, but it makes no sense to simply activate all sources and start from there ... most probably you run in an OOM condition. Start with a few sources, enable debug logging, consult the readme and check the local logs.
1 Like
ok thx, I already try to.
its a virtual openwrt installation done with qemu. running on a raspberry pi 4.
oom is not possible 
update: installed banip again, and status is: active (nft: , monitor: )
but still the website is reachable from blocked countries... any ideas?
thx!
edit: in the logs I can see like:
banIP/inp-wan/drp/countryv4:
reject wan in:
with the blocked source ip address, but the website is still shown.
edit: seems to be solved, must be a misunderstanding, wan-forward chain has to be set, not input.
1 Like
I setup option ban_cores '2' in luci, rebooted and waited for the system to be idle.
Then when searching for IP 1.1.1.1, I still have the same OOM issue.
Looking at htop we see 4 processes related to 1.1.1.1 search using 100% of all 4 cores:
banip config
`root@D1:/etc/config# cat banip
config banip 'global'
option ban_enabled '1'
option ban_debug '1'
option ban_autodetect '0'
list ban_logterm 'Exit before auth from'
list ban_logterm 'luci: failed login'
list ban_logterm 'error: maximum authentication attempts exceeded'
list ban_logterm 'sshd.Connection closed by.[preauth]'
list ban_logterm 'SecurityEvent="InvalidAccountID".*RemoteAddress='
option ban_deduplicate '1'
option ban_loginput '1'
option ban_logforwardwan '1'
option ban_logforwardlan '1'
option ban_autoallowlist '1'
option ban_autoblocklist '1'
option ban_allowlistonly '0'
option ban_fetchcmd 'uclient-fetch'
option ban_protov4 '1'
list ban_ifv4 'wan'
list ban_dev 'wan'
option ban_logcount '10'
option ban_nftpolicy 'memory'
option ban_filelimit '1024'
list ban_feed 'adaway'
list ban_feed 'adguard'
list ban_feed 'adguardtrackers'
list ban_feed 'antipopads'
list ban_feed 'backscatterer'
list ban_feed 'bogon'
list ban_feed 'cinsscore'
list ban_feed 'darklist'
list ban_feed 'debl'
list ban_feed 'doh'
list ban_feed 'drop'
list ban_feed 'dshield'
list ban_feed 'edrop'
list ban_feed 'feodo'
list ban_feed 'firehol1'
list ban_feed 'greensnow'
list ban_feed 'iblockads'
list ban_feed 'iblockspy'
list ban_feed 'myip'
list ban_feed 'nixspam'
list ban_feed 'proxy'
list ban_feed 'sslbl'
list ban_feed 'talos'
list ban_feed 'threat'
list ban_feed 'threatview'
list ban_feed 'tor'
list ban_feed 'uceprotect1'
list ban_feed 'urlhaus'
list ban_feed 'urlvir'
list ban_feed 'voip'
list ban_feed 'webclient'
list ban_feed 'yoyo'
option ban_cores '2'
`
Note:
1.1.1.1 is not in my allow list and is not my DNS server, but is in the doh list I'm using.
Than it might be a bug, I'll take a look and come back to you.
edit: confirmed: it's a search bug to not respect the ban_cores setting. Will be fixed in the next update.
3 Likes