

As you probably know the crowdsec bouncer doesn’t directly parse logs or do checks like F2B filters. It queries the crowdsec LAPI for decisions and applies them. The “allowed” or “whitelisted” IP logic is handled at the Security Engine or LAPI level, not by the bouncer itself.
You can whitelist an ip in /etc/crowdsec/whitelists.yaml
or even whitelist decisions in the whitelist.yaml as such:
name: private-ips
description: Whitelist local and private IPs
whitelist:
reason: "Allow local and private IPs"
ip:
- "127.0.0.1"
- "192.168.1.0/24"
cidr:
- "10.0.0.0/8"
Then issue sudo systemctl reload crowdsec
. Kind of the same concept as F2B’s ignoreip
option. If you are using Tailscale to administer the server, then it’s easier to whitelist. IIRC, you can use cscli decisions add --type whitelist --ip 192.168.1.100 --duration 1y
but it doesn’t add them to the whitelist.yaml. Instead it keeps them in crowdsec’s database managed by LAPI. To undo: cscli decisions delete --ip 192.168.1.100 --type whitelist
https://docs.crowdsec.net/u/getting_started/post_installation/whitelists/
From the guy that has been accused of going overboard on security measures, I use both. It just depends on your setup tho. On a low resource server, I would pick crowdsec as it covers more ground than F2B. Running two log parsers does use more resources. ~ my 2 cents