112 lines
4.4 KiB
Markdown
112 lines
4.4 KiB
Markdown
# F2B Control Center — FAQ
|
|
|
|
---
|
|
|
|
### Why do I keep seeing Cloudflare IPs attacking me?
|
|
|
|
You're not — those are Cloudflare's proxy servers, not attackers.
|
|
|
|
When your domain is proxied through Cloudflare, all traffic reaches your server *from* Cloudflare's IP ranges, not from the real visitor. Without extra configuration, Nginx logs the Cloudflare IP as the client — which means fail2ban would ban Cloudflare instead of the actual bad actor, and you'd eventually block yourself.
|
|
|
|
The fix is telling Nginx to trust Cloudflare as a proxy and extract the real visitor IP from the `X-Forwarded-For` header instead. When this is set up correctly, NPM logs show a `[Client X.X.X.X]` field with the real IP — which is exactly what F2B Control Center reads for scanning and banning.
|
|
|
|
**How to fix it — NPM custom Nginx config:**
|
|
|
|
In Nginx Proxy Manager, open the proxy host for your domain → **Advanced** tab → paste this into the **Custom Nginx Configuration** box:
|
|
|
|
```nginx
|
|
# Trust Cloudflare proxy IPs and extract the real visitor IP
|
|
set_real_ip_from 103.21.244.0/22;
|
|
set_real_ip_from 103.22.200.0/22;
|
|
set_real_ip_from 103.31.4.0/22;
|
|
set_real_ip_from 104.16.0.0/12;
|
|
set_real_ip_from 108.162.192.0/18;
|
|
set_real_ip_from 131.0.72.0/22;
|
|
set_real_ip_from 141.101.64.0/18;
|
|
set_real_ip_from 162.158.0.0/15;
|
|
set_real_ip_from 172.64.0.0/13;
|
|
set_real_ip_from 173.245.48.0/20;
|
|
set_real_ip_from 188.114.96.0/20;
|
|
set_real_ip_from 190.93.240.0/20;
|
|
set_real_ip_from 197.234.240.0/22;
|
|
set_real_ip_from 198.41.128.0/17;
|
|
set_real_ip_from 2400:cb00::/32;
|
|
set_real_ip_from 2606:4700::/32;
|
|
set_real_ip_from 2803:f800::/32;
|
|
set_real_ip_from 2405:b500::/32;
|
|
set_real_ip_from 2405:8100::/32;
|
|
set_real_ip_from 2a06:98c0::/29;
|
|
set_real_ip_from 2c0f:f248::/32;
|
|
real_ip_recursive on;
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
|
proxy_set_header CF-Connecting-IP $remote_addr;
|
|
```
|
|
|
|
Save and reload. Your NPM access logs will now show the real client IP in the `[Client X.X.X.X]` field, and F2B Control Center will ban the actual offender instead of Cloudflare.
|
|
|
|
> **Note:** Cloudflare occasionally updates their IP ranges. The current full list is always at [cloudflare.com/ips](https://www.cloudflare.com/ips/).
|
|
|
|
---
|
|
|
|
### Do I need to whitelist Cloudflare IPs?
|
|
|
|
No — once the `set_real_ip_from` config above is in place, Nginx transparently rewrites the client IP before fail2ban ever sees the log line. Cloudflare's IPs won't appear in your ban lists at all.
|
|
|
|
If you set this up *after* already accumulating bans against Cloudflare IPs, check your whitelist and manually remove any Cloudflare ranges that snuck in.
|
|
|
|
---
|
|
|
|
### Will this work without Cloudflare?
|
|
|
|
Yes. If your server is exposed directly (no CDN), the `[Client X.X.X.X]` field will just show the connecting IP as-is. No special config needed — everything works out of the box.
|
|
|
|
If you use a different CDN or reverse proxy upstream of NPM, add that proxy's IP ranges to `set_real_ip_from` instead of Cloudflare's.
|
|
|
|
---
|
|
|
|
### Bans aren't blocking traffic — what's wrong?
|
|
|
|
The most common cause is a missing kernel module. Check that `xt_string` is loaded on the host:
|
|
|
|
```bash
|
|
lsmod | grep xt_string
|
|
```
|
|
|
|
If it's not listed:
|
|
|
|
```bash
|
|
modprobe xt_string
|
|
echo xt_string >> /etc/modules # persist across reboots
|
|
```
|
|
|
|
Then restart the container. The `xt_string` module is required for the `X-Forwarded-For` header matching rule in the DOCKER-USER chain.
|
|
|
|
---
|
|
|
|
### New proxy hosts aren't being monitored — why?
|
|
|
|
Fail2ban only picks up log files that exist when it starts. If you add a new proxy host in NPM after the container is already running, its log file won't be watched automatically.
|
|
|
|
F2B Control Center includes a `logwatch` process that polls for new `proxy-host-*_access.log` files every 30 seconds and reloads fail2ban automatically when it finds one. This handles the common case, but there may be a short delay before a brand-new host is monitored.
|
|
|
|
If you want to force it immediately:
|
|
|
|
```bash
|
|
docker exec f2b-control-center fail2ban-client reload
|
|
```
|
|
|
|
---
|
|
|
|
### How do I reset everything back to defaults?
|
|
|
|
Remove the persistent config volume — the container will repopulate it from the bundled defaults on next start:
|
|
|
|
```bash
|
|
docker compose down
|
|
docker volume rm f2b-control-center_f2b-config
|
|
docker compose up -d
|
|
```
|
|
|
|
This resets jail settings and filters only. Ban history and exemptions (stored in the `f2b-data` volume) are unaffected. To wipe those too, also remove `f2b-control-center_f2b-data`.
|