[BUG] Cloudflare zerotrust tunnels bans container IP instead of external IP

[Prankish8407]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

This is going to be a long read and ill try to provide as many details as possible:

Here is the docker-compose file i use fail2ban (seperate stack)

`--- services: fail2ban: image: lscr.io/linuxserver/fail2ban:latest container_name: fail2ban cap_add:

• NET_ADMIN
• NET_RAW network_mode: host environment:
• PUID=1000
• PGID=1000
• TZ=Europe/Amsterdam
• VERBOSITY=-vv volumes:
• /volumes/fail2ban-config:/config
• /volumes/fail2ban-log:/var/log:ro
• /volumes/prowlarr-config/logs:/remotelogs/prowlarr:ro #optional
• /volumes/vaultwarden-data/log:/remotelogs/vaultwarden:ro #optional restart: unless-stopped`

Next i have nginx proxy manager running, and it grabs the SSL certificate correctly from cloudflare. Note that i do NOT have any ports forwarded in my router (80 / 443 are closed).

Next to that i have adguard running with DNS rewrites to my nginx server so i can reach all containers trough *.domainname.com locally with the SSL certificate grabbed from cloudflare to make it a valid certificate.

so that all works perfectly as expected.

so to summarize itif i go to adguard.domainname.com or vaultwarden.domainname.com i can reach this locally but not externally (perfect, just how i want it).

Now the tricky part: In cloudflare you have something called zerotrust, this allows you to run a docker container that creates a tunnel to cloudflare to expose your services directly without the portforwarding.

In this tunnel i've forwarded "https://vaultwarden.domainname.com" and this allows me to visit the website externally. I've put some firewall rules inside of cloudflare WAF to only allow connections from the NL and UK as my users are from those country's

All of this works perfectly fine as well.

Now when i setup fail2ban as described above with the following jail.local edits:

the rest of the jail.local is the same as jail.conf (its a copy + the above lines for testing)

Now when i check the logs of fail2ban it states it baned the ip adres of my vaultwarden container:

2024-04-02 09:27:18,064 7F92D5AD0B08 INFO Jail 'vaultwarden-auth' started 2024-04-02 09:27:18,260 7F92D374DB38 NOTIC [vaultwarden-auth] Restore Ban 192.168.80.13 2024-04-02 09:31:48,351 7F92D374DB38 NOTIC [vaultwarden-auth] Unban 192.168.80.13

The 192.168.80.xxx is the vlan of my docker network not my local lan, so 192.168.80.13 is the IP adres of the docker container itself.

when i go to vaultwarden.domainname.com and spam wrong passwords the ip adres of the docker container is banned not the actual ip of the client connecting.

Expected Behavior

ban client ip not the internal docker ip

Steps To Reproduce

see above comment

Environment

- OS:
- How docker service was installed:

CPU architecture

x86-64

Docker creation

see above comment

Container logs

root@homelab:/volumes/fail2ban-config/log/fail2ban# tail -f fail2ban.log 
 2024-04-02 09:27:18,059 7F92D5AD0B08 INFO    findtime: 600
 2024-04-02 09:27:18,059 7F92D5AD0B08 INFO    banTime: 600
 2024-04-02 09:27:18,059 7F92D5AD0B08 INFO    encoding: UTF-8
 2024-04-02 09:27:18,059 7F92D5AD0B08 INFO  Added logfile: '/remotelogs/vaultwarden/vaultwarden.log' (pos = 65995, hash = 3d8aff85ad51dd0019c7a5cf214b27e7d3c0acaa)
 2024-04-02 09:27:18,060 7F92D5AD0B08 INFO  Jail 'prowlarr-auth' started
 2024-04-02 09:27:18,064 7F92D5AD0B08 INFO  Jail 'vaultwarden-auth' started
 2024-04-02 09:27:18,260 7F92D374DB38 NOTIC [vaultwarden-auth] Restore Ban 192.168.80.13
 2024-04-02 09:31:48,351 7F92D374DB38 NOTIC [vaultwarden-auth] Unban 192.168.80.13
 2024-04-02 09:43:28,428 7F92D3950B38 WARNI [vaultwarden-auth] Detected a log entry 2h before the current time in operation mode. This looks like a timezone problem. Treating such entries as if they just happened.
 2024-04-02 09:43:28,428 7F92D3950B38 WARNI [vaultwarden-auth] Please check a jail for a timing issue. Line with odd timestamp: [2024-04-02 07:43:28.157][vaultwarden::api::notifications][INFO] Closing WS connection from 192.168.80.13

[github-actions[bot]]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[Roxedus]

You need to get the real ip

[Prankish8407]

You need to get the real ip

Could you elaborate a little bit?

[j0nnymoe]

This isn't a bug, Fail2ban is just reading the contents of your logs. You need to figure out how to expose real ip's with your reverse proxy solution.

[Prankish8407]

This isn't a bug, Fail2ban is just reading the contents of your logs. You need to figure out how to expose real ip's with your reverse proxy solution.

do you have an article or anything so i can test this out? even if i take out the nginx proxy in between and forward the container directly to cloudflare as http it still only bans the IP of the container.

so nginx running or not the IP adresses shown are only from the container trough the zerotrust tunnel.

Again i dont have any ports exposed at all.

[Roxedus]

You still need to get the real-ip, also when using tunnels. I have linked the relevant cloudflare article. You probably also need to set the tunnel as an allowed real-ip source, with the same set_real_ip_from method the cloudflare article mentions.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.