@Nick,

Hi there,

Thanks for the detailed explanation, your setup sounds solid overall, and it’s great that you’re thinking carefully about security!

Regarding your issue with Fail2ban banning your local IP (192.168.x.x) instead of the actual external IP during a failed login attempt: this usually happens when your server is behind a reverse proxy, in your case, Cloudflare.

By default, Nextcloud (and many web services) will log the IP address of the reverse proxy (Cloudflare) or even your internal gateway, instead of the real external visitor’s IP. This causes Fail2ban to see and ban the wrong IP, often your own local address.

I’d like to share a small concern regarding my cloud setup.

I currently have a Nextcloud instance running on my home lab. None of my router’s ports are open, so I assume it’s not directly accessible from the outside. My server is tunneled through Cloudflare, and my domain is properly pointed to Cloudflare as well. I’ve also installed Fail2ban to add an extra layer of security, and as far as I can tell, it’s working, but I noticed something strange.

From an external network (outside my home), I intentionally failed several login attempts on Nextcloud to test Fail2ban. As expected, the login was blocked after three failed tries. However, when I checked the status using the fail2ban-client status command, I was surprised to see that the banned IP was from my local network (e.g., 192.168.1.xx).

This seems wrong. If someone tries a brute-force attack from the outside, my internal IP ends up getting banned. That doesn’t sound right, and I’m concerned that this could leave me locked out too often.

Do you have any advice or suggestions on how to fix or improve this setup?

Thanks in advance!

@Cybernard,

Great points, thanks for sharing!

You’re absolutely right: using ipset or nftables sets can make IP blocking much more efficient, especially when dealing with a large number of addresses. The ability to save and restore sets, and even automate them with systemd, is super handy for production environments.

Fail2Ban’s integration with ipset or nftables (especially when paired with SQLite) does simplify rule reloading a lot, assuming it’s all properly configured.

That said, the script approach in the article is meant as a beginner-friendly intro, something simple and quick to get people started. For anyone scaling up or looking for performance and automation, your suggestions are definitely the way to go.

Appreciate the detailed input!

@Bruce,

Thanks for the tip!

You’re right, using ip route add blackhole is a neat and lightweight way to drop traffic without the overhead of iptables. It’s especially handy for blocking IPs at the routing level, and can be a great fit for high-traffic environments or minimal setups.

That said, iptables (along with tools like Fail2Ban) shines when you need more dynamic, rule-based filtering, like detecting repeated failed logins and acting on them automatically. Both approaches have their place depending on the use case.

Appreciate the input!

iproute2 instead of iptables

For example:

ip route add blackhole $IP_ADDRESS

Where $IP_ADDRESS is either the specific IP address or the entire netblock.

It’s lighter on the system than using iptables.