.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
I've locked myself out of a production firewall twice in my career, both times self-inflicted, which is why my CrowdSec rollouts now look paranoid to anyone watching. CrowdSec is the rare security tool that will cheerfully ban the person who installed it. What follows is the exact order I use on every new server, with the reasoning, most of it learned the annoying way.
Why CrowdSec lockouts happen (even to careful people)
Two properties combine badly. Remediation is instant and unforgiving: the moment a bouncer attaches, every decision becomes a dropped packet with no grace period and no dry run. And decisions arrive from four origins at once, local scenarios reading your logs, the community blocklist (CAPI), any third-party lists you subscribe to and manual cscli entries.
You directly control one of the four. The others can ban an address you depend on without a single suspicious line in your own logs. Stack on top of that the fact that your uptime checker, your backup agent, your dashboard polling and your API scripts all look exactly like attack traffic to a scenario, and an admin ban becomes a matter of time.
What consistently amazes me is how confident everyone feels right before it happens. A Pangolin user's "CrowdSec almost bricked my setup" thread from February 2026 is the canonical read here: a reasonable person running a standard reverse proxy stack, one bad evening away from rebuilding it.
Week one: Engine only, no bouncer
Install the Security Engine alone and attach nothing to it. Detection without remediation can't hurt you, and it produces the single most valuable artifact of the whole rollout, a week of evidence about what would have been banned:
sudo cscli alerts listRead it daily. You'll find your own monitoring in that list more often than you'd like, and every entry you find in week one is a lockout you didn't have in week three. I run this observation phase on a throwaway box first when I can; LumaDock's Ubuntu 24.04 + CrowdSec one-click template exists for exactly this kind of staging run, picked at order time and deployed in seconds.
Allowlists before the first bouncer exists
This is the step people do third that must happen second. Before any enforcement is possible, tell LAPI which addresses are yours:
sudo cscli allowlists create admins -d "never ban these"
sudo cscli allowlists add admins 198.51.100.7 203.0.113.0/29Centralized allowlists drop matching alerts as they happen and strip matching IPs out of blocklist pulls, so they cover community and third-party bans too. Private RFC1918 ranges are whitelisted by default since 1.6.3, so your LAN is already safe; it's the public addresses, the office egress and the VPN endpoint that need entries. Firewall appliance in front? The same thinking applies with different mechanics, covered in allowlisting an IP in CrowdSec on OPNsense.
Remediation on one service, then wait
When the bouncer finally arrives, it guards one service. I start with the reverse proxy rather than the firewall, on the theory that a wrong HTTP ban costs me a dashboard while a wrong firewall ban costs me SSH. Run that single enforcement point for a few days, watch cscli decisions list and only then widen the blast radius. Rolling out enforcement everywhere on day one is how people end up starring in Reddit threads.
A second path in: Provider console + WireGuard
Assume the ban will happen anyway, because eventually it does. The out-of-band console or VNC from your provider is the parachute no IP ban can touch, and it's worth logging into once now, since discovering a broken console password mid-incident is its own special misery. My preferred second path is a WireGuard tunnel whose subnet is allowlisted: admin traffic arrives inside the tunnel from a private address the default whitelist already trusts, so a ban on my public IP stops mattering entirely. A small WireGuard VPS sitting outside the protected network makes a fine permanent side door.
Dynamic home IP tactics
Home connections reshuffle addresses, which quietly rots any allowlist entry pointing at one. Two approaches work. Check what your current IP is and add it with an expiry, cscli allowlists add admins YOUR_IP -e 7d, so stale entries clean themselves up instead of accumulating as permanent holes. Or skip the moving target altogether and make the WireGuard tunnel your only admin identity, which is what I actually do; the tunnel's address never changes and my ISP's dynamic pool stops being my problem.
Test bans and a written rollback
Never test enforcement against your own address. Documentation ranges exist for this:
sudo cscli decisions add -i 203.0.113.50 --duration 2m
sudo ipset list crowdsec-blacklists | grep 203.0.113.50And before enforcement touches production, the rollback gets written down somewhere readable from a phone, because during an incident you will not remember flag syntax:
sudo systemctl stop crowdsec-firewall-bouncer
sudo cscli decisions delete -i BANNED_IPStopping the bouncer removes enforcement while detection keeps running, which beats uninstalling in every scenario I've met. The full locked-out recovery path, console access included, is in fixing the CrowdSec Access Forbidden page.
Blocklist subscriptions come last
Last, never first, and I'll die on this hill. Every subscription imports thousands of addresses you didn't vet and can't audit, and if your VPN exit or your office NAT appears on one of them, you've outsourced your own lockout to a stranger's false positive. Subscribe after weeks of clean running, one list at a time, with your allowlists already standing guard. Honestly, most single-VPS setups don't need third-party lists at all; local detection plus the community blocklist covers the realistic threat picture.
If your edge runs OPNsense or pfSense, I've written up how blocklists behave on those firewalls separately, and the CrowdSec troubleshooting reference catalogues what it looks like when any of this goes sideways.
The whole order costs about two weeks of patience. The author of that Pangolin thread can tell you what the fast version costs.
