I'd like to install the CrowdSec bouncer on my OpenWRT router. I don't want to install CrowdSec within OpenWRT itself, as there isn't enough storage space on my NanoPi R5S eMMC. CrowdSec itself runs as an add-in for Caddy in a Docker Compose container for my web services, which CrowdSec protects.
Unfortunately, the installation in OpenWRT isn't working at all. No further option is added in the LuCI web GUI, and I can't configure the CrowdSec bouncer via the command line either. The necessary files are simply missing.
Is this a known bug? Or am I doing something wrong? Is it even possible to use the CrowdSec Bouncer on its own in OpenWRT?
I think you've hit the nail on the head. I'm using the latest release of OpenWRT 25.12, which has switched to the new APK package manager. I'm worried that the CrowdSec bouncer packages haven't been migrated to the new release yet, and what I see are just placeholders.
I can't find anything in the package list either:
Perhaps the developers or providers of the packages can help here.
Could you possibly show me a screenshot of the menu item where you found it? Did you also install just the bouncer without the full CrowdSec package?
Thanks for the screenshot. That all looks pretty standard – just like mine. I assume you only have one LAN port on your OpenWRT router, to which you've connected your devices (and the web service you want to protect). Is that correct? You haven't included the WAN port either. So that seems to be correct.
You've disabled logging. How can you see if the bouncer has done anything?
May I ask why you're using port :8081 for CrowdSec and not the standard port :8080?
I also have the banIP add-in installed on my OpenWRT. Are you using that as well?
You might be right, but the CrowdSec Bouncer is an additional layer of protection for free. I already have CrowdSec running in my Caddy reverse proxy. That way, I can also use its detection capabilities in my firewall router. I haven't installed CrowdSec itself on OpenWRT. The eMMC storage of my NanoPi R5S wouldn't be sufficient for that anyway.
Both are IP-based layer 3/4 blockers that ultimately write into the same nftables infrastructure.
Duplicated effort with overlapping protection. Large parts of banIP's feeds (Spamhaus, Firehol Level 1, etc.) cover the same IPs as CrowdSec's CTI. You're doubling memory usage, download traffic, and nft set sizes for barely measurable security gain.
Two separate log-monitor pipelines parsing the same auth log and drawing the same conclusion ("this IP tried 10 wrong passwords"). Both independently install a block. Worst case with different expiry times, which makes debugging painful "why is this IP gone — was it banIP or CrowdSec?"
Conflicts around nftables hook priorities. Usually they pass each other because each uses its own table, but if both hang off prerouting with similar priorities, you get subtle ordering effects.
Allowlist maintenance gets duplicated. If you don't want to block your own server or an uplink subnet, you have to maintain that in both systems. Forget one, the other blocks it.
Bottomline, running both in parallel is redundancy without added value.
Hello @dibdot
Thank you very much for your feedback. However, your assessment is not entirely correct. banIP and CrowdSec work differently. banIP is a static blocker that simply checks against blacklists. It doesn't recognize any login attempts or log files from my web services. It will never block if someone enters the wrong password 10 times. But CrowdSec knows exactly this and can react dynamically to suspicious events. So the scope is different and that's why I see it useful. And since CrowdSec in Caddy can only block access via GUI ports :80 and :443 directly in Caddy, not other ports whose servers communicate past Caddy (e.g. email server ports), I see it makes sense to use the knowledge about attempted attacks on GUIs via OpenWRT for this purpose.
Greetings Mic.
That’s completely wrong – banIP includes a powerful log monitor … at the very least, check the readme.
e.g.:
[17/04/2026-19:48:13] banIP-1.8.6-r1[3868]: add IP '85.217.140.52' (cnt: 1, expiry: 2h) to blocklist.v4 Set
[17/04/2026-19:48:23] banIP-1.8.6-r1[3868]: add IP range '85.217.140.0/24' (source: FR, RIPE ::: expiry: 2h) to blocklist.v4 set
[17/04/2026-20:59:03] banIP-1.8.6-r1[3868]: f_monitor ::: block request for IP '10.168.1.20' (protocol: IP.v4)
[17/04/2026-20:59:03] banIP-1.8.6-r1[3868]: f_monitor ::: refreshed monitor cache at 2026-04-17 20:59:03
[17/04/2026-20:59:22] banIP-1.8.6-r1[3868]: add IP '10.168.1.20' (cnt: 1, expiry: 2h) to blocklist.v4 Set
[17/04/2026-21:11:16] banIP-1.8.6-r1[3868]: f_monitor ::: block request for IP '45.148.10.121' (protocol: IP.v4)
[17/04/2026-21:11:16] banIP-1.8.6-r1[3868]: f_monitor ::: refreshed monitor cache at 2026-04-17 21:11:16
[17/04/2026-21:11:35] banIP-1.8.6-r1[3868]: add IP '45.148.10.121' (cnt: 1, expiry: 2h) to blocklist.v4 Set
[17/04/2026-21:11:45] banIP-1.8.6-r1[3868]: add IP range '45.148.10.0/24' (source: AD, RIPE ::: expiry: 2h) to blocklist.v4 set
banIP has no access to the log files on my PC behind the OpenWRT router. It cannot react on events there and in my case it shall also not because CrowdSec handles it.
That’s not true either, just search for " receive remote logging events" in the readme.
Don't get me wrong if you're happy with crowdsec just use it ... but than don't use banIP in parallel.
CrowdSec cannot handle lange Blacklists. This is what banIP does in my network. And it only protets ports 80 and 443.
Where is the readme you are referring to? In the GitHub readme of banIP I cannot find anything.
But it seems (and makes sense) banIP has no access to log files on another computer. You would need to transfer them to The OpenWRT computer. This may be not sufficient or too complicated from the Docker environment on the other computer in my setup.
So, in my case banIP handles the static blocking and CrowdSec handlses the rest. This is fine for me.
And it needs remote logging via curl or wget. But the log files are just files in my Docker environment. No IP address to easiely "curl" them. CrowdSec is inside the Docker directly.
You mean you're simulating an attack with your mobile phone and seeing if CrowdSec reacts. Okay, then you know it works. But how do you see if real attacks from the internet have an effect on the CrowdSec Bouncer? When I look at my CrowdSec decission logs directly on the server PC, there are always attack attempts from botnets.
