[QTS + Nginx Proxy Manager] Source IP address lost

English Networking
1

Hello everyone,

I’m encountering a configuration issue between my QNAP (QTS) and Nginx Proxy Manager (NPM), which is rendering my Fail2ban (or QTS access protection) ineffective against brute-force attacks.

My configuration:
QNAP (QTS): Local IP 192.168.10.10 (I changed it to a standard RFC1918 IP address, but you can use your own)

Nginx Proxy Manager: Local IP 192.168.10.6 (on a Docker container or a separate VM)

Goal: Access QTS via a domain name (e.g., myqnap.domain.com) using NPM for SSL and reverse proxy.

The problem:
Access works perfectly. My domain name points to my router, which forwards ports 80/443 to Nginx Proxy Manager (100.6), and NPM then redirects the traffic to my QNAP (100.10).

The problem is that QTS doesn’t see the true source IP (public IP) of visitors.

When a connection attempt fails (brute-force attack), the QTS security logs indicate that the attempt originated from IP 100.6 (the IP of my Nginx Proxy Manager).

The consequence: If I enable IP access protection or Fail2ban on the QNAP to block IPs after several failed attempts, it blocks the IP of my Nginx Proxy Manager (100.6).

Result:

The attacker is never banned.

My own proxy is banned, which cuts off access to QTS for all legitimate users.

My question: How can I configure Nginx Proxy Manager to correctly forward the source IP address (via the X-Forwarded-For or X-Real-IP headers) AND how can I configure QTS to read and trust this header?

I’ve looked in the NPM options (I’ve checked “Forward Client-IP” and “Forward Hostname”), but QTS still seems to see the proxy’s IP address. Do I need to add a custom configuration in Nginx (via the “Advanced” tab in NPM) or is there a hidden setting in QTS to “trust” a proxy?

Thanks in advance for your help!

2

Sounds like this

Same user ?

3

Yes, that’s right, unfortunately no solution is provided.

Actually, NPM does see the IP address, but when testing users with fake passwords, the failures aren’t visible in NPM. With QNAP, the failed attempts are visible, but they appear with NPM’s internal IP address.

2025-11-04T21:24:51+01:00 NAS-L qulogd[17070]: conn log: Users: Dbd, Source IP: 192.168.10.6, Computer name: —, Connection type: HTTPS, Accessed resources: Administration, Action: Login Fail

4

If you have a firewall in place like opnsense/pfsense you can limit access coming in that way you get less potential attacks.

IDK how to use npm to do what you want, but on the FW you can setup rules to block sets of IP and/or let in a certain set of ip etc.

External attacks are reason why i dont allow internal apps direct access via external IP. I rather vpn into my firewall and access the service that way then expose it to the internet.

The only item that isnt blocked is my game servers and a website.but again the FW blocks like most countries, know spammer ips etc.

5

This solution is too restrictive, which is a shame because QNAP offers solutions, but we hold back for fear of hacking. Adding VPNs to all QNAP clients would be unmanageable. I created a script that correlates the IP addresses in the QNAP logs with the IP address of the device trying to connect via my NPM; it’s the only solution I’ve found.