Add Gluetun VPN Support for Apps

amessinger · February 21, 2025, 12:11pm

Hi I’d be interested in a step by step guide of your setup if you’d be inclined to do it!

More specifically, I think I could manage to setup the wireguard interface but I’m unfamiliar as to how to specify this interface to qBittorrent (not even sure if this would have to be done at the container level or the application one).

Thanks !

WereCatf · February 21, 2025, 12:20pm

Gluetun’s repo has everything you need to set it up, see GitHub - qdm12/gluetun: VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.

dwolsten · February 23, 2025, 4:16am

Sorry, I no longer recommend this technique at all. After fighting a lot with the community apps, I no longer even recommend using any of them, except for Dockge.

What I finally ended up doing was:

Installed Dockge from community apps.
Installed Gluetun using standard docker-compose yml, from ghcr.io. This looks like:

services:
  gluetun:
    image: ghcr.io/qdm12/gluetun
    #image: qmcgaw/gluetun
    container_name: gluetun
    # See https://github.com/qdm12/gluetun-wiki/blob/main/setup/connect-a-container-to-gluetun.md#external-container-to-gluetun
    cap_add:
      - NET_ADMIN
    ports:
      - 8080:8080 #qbittorrent
      - 6881:6881 #qbittorrent
      - 6881:6881/udp #qbittorrent
    volumes:
      - /mnt/pool/apps/gluetun:/gluetun
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      # See https://github.com/qdm12/gluetun-wiki/tree/main/setup#setup
      - TZ=<your TZ>
      - VPN_SERVICE_PROVIDER=<your VPN provider>
      - VPN_TYPE=wireguard
      - SERVER_COUNTRIES=<country/ies you want your traffic to exit through>
      - WIREGUARD_PRIVATE_KEY=<private key>
      - WIREGUARD_ADDRESSES=<address from VPN provider>
    restart: unless-stopped
networks: {}

Installed Qbittorrent using standard docker-compose yml, from linuxserver.io. This looks like:

services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=<user ID for qbittorrent>
      - PGID=<group ID for qbittorrent>
      - TZ=<your TZ>
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - /mnt/pool/apps/qbittorrent:/config
      - /mnt/pool/apps/qbittorrent/downloads:/downloads
    restart: unless-stopped
    network_mode: container:gluetun
    # Note that all ports were moved to the gluetun app.
networks: {}

After that, everything should work, with traffic funneled through the VPN in the “gluetun” container.

amessinger · February 28, 2025, 4:25pm

Thanks for the update!

I guess I’ll go the same route even though, from what I understand reading your new setup, the Web UI appears to be available through the VPN connection which is not a behavior I’m looking for: I’d like it to be accessible only through my local network.

Also, could the next Truenas version (Fangtooth) get us better access to docker’s network stack from it’s Web UI?

Improvements to the TrueNAS apps service

from Fangtooth version notes
Can’t wait to get more info about those.

dan · February 28, 2025, 4:53pm

This looks very helpful; thanks. Would you have any ideas on how to integrate ingress via Traefik for the qbittorrent web UI? Ordinarily I do it with labels and a proxy network, but I’m suspecting the network mode you’re setting would conflict with that method.

Edit: With thanks to Gluetun+Qbittorrent+Flood Docker-Compose file with traefik labels · jesec/flood · Discussion #793 · GitHub, here’s how I did it:
Gluetun:

version: "3"
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    expose:
      - 6881
      - 6881/udp
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=surfshark
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=
      - WIREGUARD_ADDRESSES=
      - SERVER_HOSTNAMES=
      - TZ=America/New_York
    networks:
      - proxy
networks:
  proxy:
    external: true

qBittorrent:

services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=568
      - PGID=568
      - TZ=America/New_York
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    volumes:
      - ./config:/config
      - /mnt/torrents/qbittorrent:/mnt/torrents/qbittorrent
    restart: unless-stopped
    network_mode: container:gluetun
    labels:
      - traefik.enable=true
      - traefik.http.routers.qbt.rule=Host(`qbt.domain`)
      - traefik.http.routers.qbt.entrypoints=https
      - traefik.http.routers.qbt.tls=true
      - traefik.http.services.qbt.loadbalancer.server.port=8080
      - homepage.group=Media
      - homepage.name=qBittorrent
      - homepage.icon=qbittorrent
      - homepage.href=https://qbt.domain
      - homepage.description=Bittorrent client
      - homepage.widget.type=qbittorrent
      - homepage.widget.url=https://qbt.domain
      - homepage.widget.username=admin
      - homepage.widget.password=
      - homepage.widget.enableLeechProgress=true
      - com.centurylinklabs.watchtower.enable='true'
networks: {}

dwolsten · March 1, 2025, 7:42am

from what I understand reading your new setup, the Web UI appears to be available through the VPN connection which is not a behavior I’m looking for: I’d like it to be accessible only through my local network.

AFAICT, the web UI is only accessible on the local network here. The Gluetun container sets up a new VPN interface called “tun0”, so (I’m sorry, I left out this step before) inside qBitTorrent, you need to go to the Advanced setup menu and bind qb to the “tun0” network interface, so all BT traffic goes through it.

Also, could the next Truenas version (Fangtooth) get us better access to docker’s network stack from it’s Web UI?

I wouldn’t bet on it. There’ve been a lot of complaints about this, but they seem to be ignored.

IONIQ6000 · March 1, 2025, 6:50pm

NGL, I’ve had nothing, but trouble with Gluetun. I’ve followed every instruction step from the documentation and I’ve tried multiple VPN providers and one of them will sometimes just not log in and won’t try again properly unless there’s intervention from me and the other two straight up refuse to log into the provider, even after triple checking the password.

If I’m not doing it wrong, which according to the Gluetun docs I’m not, then Gluetun really needs to get it’s s**t together before I would ever feel comfortable baking in support for Gluetun

Gluetun is actually kinda easy to setup in a docker compose file where you can combine it with other apps that need the VPN tunnel, but the VPN provider log-in process is a F***ing PITA.

It’s so weird that the Binhex images don’t have this issue

Craig_L · March 4, 2025, 6:48pm

You might want to post your compose file, lots of people are using Gluetun without issues. Use the binhex image if that makes life easier. Well until your VPN provider makes a change to the exit node you are using! (had that happen with truecharts/opvn Qbit).

IONIQ6000 · March 5, 2025, 12:11am

Of course there are a people don’t have issues, but I’ve double-checked my compose with the official documentation and it doesn’t work. But for some reason, it works with a different VPN. There are absolutely bugs in Gluetun that shouldn’t be there.

Craig_L · March 5, 2025, 12:38am

Have you checked the Gluetun container logs? If you have, did you go through the checklist they mention in the logs when the container’s built in health check fails and restarts the VPN connection?

github.com/qdm12/gluetun-wiki

faq/healthcheck.md

main

# Healthcheck

## Unhealthy

You might see from time to time

```log
INFO [healthcheck] program has been unhealthy for 6s: restarting VPN
```

This is the [VPN auto-healing](#internal-auto-healing) because the healthcheck kept on failing for the last 6 seconds. This is NOT the Docker healthcheck, but the [internal healthcheck built-in the program](#internal-healthcheck).

If you see it repeating and increasing in time (6s, then 12s, etc.), it means the VPN keeps on not working even after reconnecting. In this case, this usually means by order of likeliness:

1. The VPN server IP address you are trying to connect to is no longer valid 🔌 [**Update your server information**](../setup/servers.md#update-the-vpn-servers-list)
1. The VPN server crashed 💥, try changing your VPN servers filtering options such as `SERVER_REGIONS`
1. Maybe the Docker image you are running runs wrong, try [a previous tag](../setup/docker-image-tags.md).
1. Your host firewall is blocking outbound connections
1. Your Internet connection is not working 🤯, ensure it works
1. Lower your MTU with `WIREGUARD_MTU` or `OPENVPN_MSSFIX` (see [`--mssfix`](https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/)) environment variables

This file has been truncated. show original

And maybe post your compose with the creds redacted, someone might see an issue with it.

Stampe · March 15, 2025, 11:00pm

I think people misunderstand the intention. The feature request here is just: “Give us the option to change network_mode in IX apps, so we don’t have to use custom docker-compose apps if we want to use gluetun” This is my biggest problem with TrueNAS atm. I would love to see this implemented.