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 !
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.
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: {}
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.
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.
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: {}
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.
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
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).
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.
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?
And maybe post your compose with the creds redacted, someone might see an issue with it.
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.
I quite literally scrolled through this whole post with the same thought. I’m in the middle of converting all of my apps over to TrueNAS, and my gluetun application stack utilizing it is one of the last stacks left to migrate.
The standard qBitTorrent (and other apps) available by iX do NOT give the ability to choose utilizing another container (or docker network) during deployment. This is the real feature request at the heart of this whole conversation.
+1 for exposing network_mode. This would save so many people a headache.
When having a native VPN integration, like Gluetun, right into an app chart, users could easily decide if they want to relay the specific app traffic over a VPN.
As useful as Gluetun is to most users, I wouldn’t call it a native VPN integration. It can’t even do basic things like handle port forwarding with providers such as TorGuard. I’m stuck with having to use the builtin wireguard (Scale 25.04) in order to make use of port forwarding.
My prediction is an actual native WG integration will poke its head and everyone will be using that instead.
I wish I had some useful information to post here, but that’s all I have.
Wouldn’t this be an example of where it makes more sense to just install Dockge and make things that way. TorGuard has posted a compose file for Gluetun+qBittorrent with their service.
Following review, we will not be accepting the request to include a VPN option during app configuration at this time. There are some community solutions provided on this thread that some are choosing to use. Closing and releasing votes.