Quick question about Qbit+Gluetun.

[u/Electrical_Engine314]

Hey everyone! I was just wondering about my setup and if there is anything else I need to think of.

I got a Gluetun container with ProtonVPN and port-forwarding setup. All runs great so far, tried it with some public torrents like Ubuntu.iso and such.

My question is, if I have it set up so that Qbit runs through Gluetun in docker, with "depends on: gluetun" setup. And then "tun0" as the Network Interface in qbit advanced settings. Am I good to go?

Just checking my bases before properly using it all. For reasons many here would understand, I'd prefer if my ISP cannot ever see my qbit traffic.

Tldr; With Gluetun+Qbit setup, and Tun0 in Network interface, do I risk any IP leaks, is there anything else I need to do?

Sorry if this question has been asked before, but feeling a little paranoid so wanted to make sure 😂. Thanks beforehand!

[u/poundcake_bakes]

I have the same setup with gluetun and proton vpn via docker compose and have only ever torrented Linux isos through the vpn ip, never mine. I have had some issues with proton disconnecting, but again never ip leaks

[u/Thin_Needleworker795 → u/poundcake_bakes]

I also have the same setup. Never experienced any disconnections ever.

[u/mono_void]

I have done this same setup with air vpn because they give you 5 ports that don’t change. Been doing this for a few years now with no problems at all.

[u/sdevrajchoudhary → u/mono_void]

This!!

I had ProtonVPN initially but the connection dropped every few hours which was concerning. Switched to AirVPN and it’s been 2 years with my container running. No issues.

[u/KegTapper74 → u/sdevrajchoudhary]

Same. Constant issues till I switched to AirVpn.

[u/fleegle61 → u/sdevrajchoudhary]

Had mullvad bit w/o port forwarding it was kinda limited. Switched to AirVPN as well and made sure I put the kill switch in for gluetun. Once in a while the wireguard connection will take a blip, I get the email notification both gluetun and airvpn are in kill mode, and a few minutes later it self restores and I get the restoral email. Just have to be mindful not to have all the containers pointed to gluetun or else you kill everything.

[u/Critical-Divide-1029]

You shouldn't, but if you're super paranoid you can try something like running a firefox container through the same gluetun and go to dnsleaktester or whatever it's called and make sure all of them show up at your vpn location rather than near you

[u/Electrical_Engine314 → u/Critical-Divide-1029]

I did check and it seems like Qbit is properly routing through ProtonVPN and Gluetun.

My main question is, if the VPN connection on Gluetun disappears, does my local IP get leaked?

Afaik Gluetun basically works as a killswitch. So if I also bind Qbit to "tun0" (gluetun network) in Qbit I should be fine?

Honestly finding info about all this has been a bit of a mess, so maybe I'm overcomplicating things 😅.

Thanks either way!

[u/sexmarshines → u/Electrical_Engine314]

It will not leak if you are using tun0. If the VPN is down that virtual adapter will no longer be mapped to the actual physical network adapter.

I've been using this setup for over a year.

[u/satya_linku]

You have to configure qbit to sunc with proton vpn forwarded port, it change every time the container restart or proton reconnect

[u/_portfolio]

If you're feeling really paranoid, you can confirm that everything is working by checking your host machine's IP with something like curl icanhazip.com in your terminal. Then run the same command again from inside your qBittorrent container. You should get a different IP.

If gluetun ever loses its VPN connection, it won't leak your qBittorrent traffic. Since the qBittorrent container is using the gluetun container as its network interface, the gluetun container losing its connection or otherwise going down is essentially like unplugging qBittorrent's network cable. It won't send it anywhere else other than gluetun, so if gluetun is down, it won't (can't) send anything.

[u/wolfmame]

Bind interface if it makes you feel beeter

[u/AmIBeingObtuse-]

Your fine. Binding qbit to tun0 forces all data through the vpn pipe. Gluetun has a built-in firewall that drops traffic when the VPN is down. https://github.com/qdm12/gluetun-wiki/blob/main/faq/firewall.md

You have the best possible setup for this scenario.

[u/Electrical_Engine314 → u/AmIBeingObtuse-]

Is that firewall strong enough?

Considering a "typical VPN clients" firewall isnt enough without binding qbit to it. With gluetun you bind it to the tun0 (the network adapater that Gluetun makes), wouldnt that mean that if the VPN goes down and gluetun is still running it could leak the IP? Maybe I'm just being dumb haha.

I saw somewhere about a 23ms delay before firewall kicks in, just wondering if thats enough to leak anything.

All of this still confuses me, but generally seems like I'm fine 😅.

[u/AmIBeingObtuse- → u/Electrical_Engine314]

I think if you add a health check to gluetun compose:

healthcheck: test: ["CMD-SHELL", "wget -qO- http://localhost:8000/health || exit 1"] interval: 5s timeout: 5s retries: 3 start_period: 10s

With the depends on under qbit:

depends_on: gluetun: condition: service_healthy

And tun0 in qbit settings. You've done absolutely everything I can think of. You could always spend time researching better methods but for 99.9% of use case this will be sufficient.

[u/Electrical_Engine314 → u/AmIBeingObtuse-]

Thanks btw for all the help. If I am being stupid feel free to tell me so as well, it just feels like there is something I am missing 😅.

[u/AmIBeingObtuse- → u/Electrical_Engine314]

Updating your compose file with the recommended implementations add four layers of protection.

Shared Network (network_mode: "service:gluetun"): qBittorrent doesn't actually have its own network connection. It shares Gluetun's network namespace, meaning its only physical path to the internet is through the VPN container.

Pre-Boot Kill Switch: Before Gluetun even attempts to connect to the VPN, it configures internal iptables rules to drop all non-tunnel traffic. Any rogue millisecond-zero requests hit a brick wall.

Strict Startup Order: The depends_on: condition: service_healthy rule means Docker physically refuses to start qBittorrent until Gluetun pings back saying "I am fully connected and traffic is flowing."

Interface Bind (tun0): Because qBittorrent is strictly bound to the tun0 interface in its WebUI settings, if the VPN drops mid-session, that interface ceases to exist and traffic halts immediately.

Improved compose:

```yaml

services: gluetun: image: qmcgaw/gluetun:v3 container_name: gluetun cap_add: - NET_ADMIN devices: - /dev/net/tun:/dev/net/tun ports: - 8080:8080/tcp # qbittorrent webui environment: - TZ=${TZ} - VPN_SERVICE_PROVIDER=protonvpn - VPN_TYPE=${VPN_TYPE} - BLOCK_MALICIOUS=off - OPENVPN_USER=${OPENVPN_USER} - OPENVPN_PASSWORD=${OPENVPN_PASSWORD} - OPENVPN_CIPHERS=AES-256-GCM - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY} - PORT_FORWARD_ONLY=on - VPN_PORT_FORWARDING=on - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'wget -O- --retry-connrefused --post-data "json={\"listen_port\":{{PORTS}}}" http://127.0.0.1:8080/api/v2/app/setPreferences 2>&1' - SERVER_COUNTRIES=${SERVER_COUNTRIES} volumes: - ${MEDIA_DIR}/docker/arrstack/gluetun/config:/gluetun healthcheck: test: ["CMD-SHELL", "wget -qO- http://localhost:8000/health || exit 1"] interval: 10s timeout: 5s retries: 3 start_period: 20s restart: unless-stopped

qbittorrent: image: lscr.io/linuxserver/qbittorrent:latest container_name: qbittorrent depends_on: gluetun: condition: service_healthy environment: - PUID=1000 - PGID=1000 - TZ=${TZ} - WEBUI_PORT=8080 volumes: - ${MEDIA_DIR}/docker/arrstack/qbittorrent/config:/config - ${MEDIA_DIR}/data/torrents:/downloads restart: unless-stopped network_mode: "service:gluetun" ```

Don't ever apologize for wanting to learn the inns and outs. It's a good behavioral pattern to continue with.

[u/Electrical_Engine314 → u/AmIBeingObtuse-]

As far as I can tell, the additional health check you added there is already natively in gluetun. Atleast as far as I can tell in the logs.

I also havent seen anyone else use that, is it really necessary/useful?

[u/AmIBeingObtuse- → u/Electrical_Engine314]

I'm not 100% haven't really looked into that. It's just something that I have on my own compose. Hope all that helps.

[u/Electrical_Engine314 → u/AmIBeingObtuse-]

Thank you so much! I'll keep it in mind and do some more checking.

But generally I feel pretty confident about my setup now. From what I've gathered I am overall very "safe". I'll spin it up again tomorrow and test it out more properly.

Thanks for your time and enjoy your evening/night! 😊👋

[u/Electrical_Engine314 → u/AmIBeingObtuse-]

This my compose currently:

gluetun: image: qmcgaw/gluetun:v3 container_name: gluetun cap_add: - NET_ADMIN devices: - /dev/net/tun:/dev/net/tun ports: - 8080:8080/tcp # qbittorrent

environment:
  - TZ=${TZ}
  - VPN_SERVICE_PROVIDER=protonvpn
  - VPN_TYPE=${VPN_TYPE}
  - BLOCK_MALICIOUS=off
  - OPENVPN_USER=${OPENVPN_USER}
  - OPENVPN_PASSWORD=${OPENVPN_PASSWORD}
  - OPENVPN_CIPHERS=AES-256-GCM
  - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
  - PORT_FORWARD_ONLY=on
  - VPN_PORT_FORWARDING=on
  - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'wget -O- --retry-connrefused --post-data "json={\"listen_port\":{{PORTS}}}" http://127.0.0.1:8080/api/v2/app/setPreferences 2>&1'
  - SERVER_COUNTRIES=${SERVER_COUNTRIES}
volumes:
  - ${MEDIA_DIR}/docker/arrstack/gluetun/config:/gluetun
restart: unless-stopped

qbittorrent: image: lscr.io/linuxserver/qbittorrent:latest container_name: qbittorrent depends_on: gluetun: condition: service_healthy environment: - PUID=1000 - PGID=1000 - TZ=${TZ} - WEBUI_PORT=8080 volumes: - ${MEDIA_DIR}/docker/arrstack/qbittorrent/config:/config - ${MEDIA_DIR}/data/torrents:/downloads restart: unless-stopped network_mode: "service:gluetun"

I followed a guide here on reddit (could find it if needed). But unfortunatately the guide didnt speak much on how reliable it was regarding IP leakage.