Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 task done
Prankish8407 opened this issue Apr 2, 2024 · 8 comments
Closed
1 task done

Comments

@Prankish8407
Copy link

Prankish8407 commented Apr 2, 2024

Is there an existing issue for this?

  • 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:
2024-04-02_09-48

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
Copy link

github-actions bot commented Apr 2, 2024

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

@Roxedus
Copy link
Member

Roxedus commented Apr 2, 2024

You need to get the real ip

@Prankish8407
Copy link
Author

You need to get the real ip

Could you elaborate a little bit?

@j0nnymoe
Copy link
Member

j0nnymoe commented Apr 2, 2024

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
Copy link
Author

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
Copy link
Member

Roxedus commented Apr 2, 2024

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
Copy link
Contributor

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.

@LinuxServer-CI LinuxServer-CI closed this as not planned Won't fix, can't repro, duplicate, stale Jul 2, 2024
@LinuxServer-CI LinuxServer-CI moved this from Issues to Done in Issue & PR Tracker Jul 2, 2024
Copy link

github-actions bot commented Aug 1, 2024

This issue is locked due to inactivity

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

4 participants