I have a similar setup to you, but I run caddy instead of npm. I recently added a log analyzer to caddy and noticed a bunch of unauthorized hits I thought I could do something about..

I added a region based firewall rule for the port forward address on my UniFi gateway only allowing incoming traffic from my own country. I couldn't do a global region block as I have some legitimate incoming traffic from the USA, so I went with a rule targeting traffic to the reverse proxy ip specifically. It still managed to let in some random bot traffic, so I also added a block region rule above the allow region rule (both to the reverse proxy) blocking countries like Russia, china, North Korea etc..

If you don’t need to allow most of the world, it is an easy fix to do this at your gateway (I note you have a udm)

Based on a quick read it sounds like the issue will be that the bad actors won't get dropped immediately. Meaning whatever servers and services are in front of the firewall that fail2ban configures, will still receive the performance hits. But your backend services will still be protected.

I have a server specifically set up as the ingress server. That runs fail2ban and Traefik and I have crowdsec set up with a Traefik bouncer plugin. So fail2ban runs in front of everything to catch the worst, most obviously bad stuff and drop the traffic very quickly and efficiently so it doesn't get any further including things trying to access services other than the web services. Then crowdsec is focused on more complex threats as they flow through the reverse proxy. Seems to work the most efficiently for me, but I haven't had a chance tondo any real analysis on how much improvement it might be over any other configuration.

@nibbs

You have already found the core issue: a ban on VM2 is too late.

VM2 does see the real client address in the HTTP logs if NPM passes X-Forwarded-For correctly, but at the network layer every connection to VM2 still originates from NPM on VM1. Therefore an nftables/UFW rule on VM2 can only block NPM — which is not exactly the intended security feature.

For your setup, I would put the actual enforcement at the ingress point:

• Run Fail2Ban on VM1.
• Parse the NPM access/error logs there.
• Let Fail2Ban add/remove bans locally on VM1.
• Ensure NPM logs the real client IP, and only trust forwarded-IP headers from proxies you actually control.
• Keep VM2 restricted so it accepts service traffic only from VM1/NPM where possible.

Having Fail2Ban on VM2 execute remote firewall actions on VM1 via SSH can work, but it is basically building a small, brittle distributed ban system yourself: SSH keys, narrowly scoped sudo rules, reliable unban actions, error handling, and so on.

Alternative:
If you want detection from several VMs/services but enforcement centrally at NPM, CrowdSec is a more natural fit. Run agents where the relevant logs live, use a central LAPI, and run a bouncer at VM1/NPM. Then the components are designed to exchange decisions instead of hoping two independent Fail2Ban installations telepathically coordinate.

Also: do not use set_real_ip_from 0.0.0.0/0 just to make X-Forwarded-For work. That turns a client-supplied header into an IP-spoofing API.

#SelfHosting #ReverseProxy #Fail2Ban #CrowdSec #NginxProxyManager