Hello everyone, I recently tried switching my docker torrent client setup from haugene/transmission-openvpn to linuxserver/qbittorrent with gluetun for my VPN.

I have gluetun set up to use port forwarding with ProtonVPN which assigns a random port on every connection. Gluetun provides a VPN_PORT_FORWARDING_UP_COMMAND which can be used in this scenario to update the port used by qbittorrent. While I had issues with the example command in the gluetun wiki to do this, I eventually managed using a bash script I found in another forum.

My issue now is that my server shuts down for the night to reduce noise and after restarting, even though I have the container startup order set up, qbittorrent is no longer reachable on its webinterface. The logs do not indicate any issue though.

As far as I can tell, the stack as I have set it up is extremely finnicky in terms of startup order and time. If I start gluetun first and then wait too long before starting qbit, the port update script will fail because there is obviously no target for it. If qbit is up and running before gluetun is done, I typically can’t access its webinterface for some reason and the network interface used by gluetun will set itself to loopback.

The result of this is that basically every morning I have to start and restart the containers in the stack a couple of times until I can access the interface and ensure that the port and network interface of qbit are configured correctly.

If anyone has a similar setup working that they could share or maybe another solution to my current issue that would be great. Thanks.

This is my docker-compose stack for the new setup

version: '3'
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - 8080:8080 # qbittorrent webinterface
      # - 6881:6881 # qbittorrent, only needed without port-forwarding
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - OPENVPN_USER=${OPENVPN_USERNAME}
      - OPENVPN_PASSWORD=${OPENVPN_PW}
      - SERVER_COUNTRIES=Switzerland
      - VPN_PORT_FORWARDING=on
      - PORT_FORWARD_ONLY=on
      - TZ=Europe/Berlin
      # From gluetun wiki: https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md
      - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'sh /gluetun/update-port.sh "{{PORTS}}"'
      - VPN_PORT_FORWARDING_DOWN_COMMAND=/bin/sh -c 'echo "Execution port forwarding down command" && wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences'
      - QBIT_ADDRESS=http://localhost:8080/
      - QBIT_USERNAME=${QBIT_USER}
      - QBIT_PASSWORD=${QBIT_PW}
    volumes:
      - /mnt/truenas/qbittorrent/update_port.sh:/gluetun/update-port.sh
    labels:
      - "com.centurylinklabs.watchtower.enable=true" # Auto update using watchtower

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
    network_mode: "service:gluetun"
    depends_on:
      - gluetun
        # condition: service_healthy
        # restart: true
    volumes:
      - /home/poseidon/qbittorrent:/config
      - /mnt/truenas/qbittorrent:/downloads
    # ports:
    #   - 8080:8080
    #   - 6881:6881
    #   - 6881:6881/udp
    restart: unless-stopped

And this is the script I use for updating the qbittorrent ports

#!/bin/sh
# update-port.sh
port="$1"
retries="${UPDATE_PORT_RETRIES:-5}"
interval="${UPDATE_PORT_RETRY_INTERVAL:-10}"

echo "Attempting to update qBittorrent port to $port..."

for i in $(seq 1 "$retries"); do
  response=$(wget --quiet --save-cookies=/tmp/cookies.txt --keep-session-cookies \
                  --post-data="username=$QBIT_USERNAME&password=$QBIT_PASSWORD" \
                  --header="Referer: $QBIT_ADDRESS" \
                  "$QBIT_ADDRESS/api/v2/auth/login" -O -)

  if [ "$response" = "Ok." ]; then
    break
  fi

  echo "Login attempt $i/$retries failed. Retrying in $interval seconds..."

  sleep "$interval"
done

set -e

if [ "$response" != "Ok." ]; then
    echo "Unable to log in to qBittorrent."
    rm -f /tmp/cookies.txt

    exit 1
fi

wget --quiet --load-cookies=/tmp/cookies.txt \
     --post-data="json={\"listen_port\": $port, \"current_network_interface\":\"$VPN_INTERFACE\", ,\"random_port\":false,\"upnp\":false}" \
     "$QBIT_ADDRESS/api/v2/app/setPreferences" -O /dev/null

rm -f /tmp/cookies.txt

echo "qBittorrent port updated successfully to $port."
  • polakkenak@feddit.dk
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    23 hours ago

    Gluetun has an example for qbt port forwarding integration on the wiki. I’ve been using this for about a year and some without problem (to my knowledge at least). I’ve seen that gluetun will retry setting the port in qbt for a while to work around the timing issues.

    They also mention a bug in qbt when changing the port, which is also covered in the example.

    Edit: I see you’re already using the port down script. Not sure what else could be the root cause if you’re running on an up to date container version :/

    • Scrath@lemmy.dbzer0.comOP
      link
      fedilink
      English
      arrow-up
      7
      ·
      24 hours ago

      As far as I am aware, Mullvad has removed port forwarding support a while ago. While I am not sure which VPN providers except proton still support it, I kind of remember seeing a small list of them some time ago which listed Proton among one of the few trustworthy ones left.

      • Ferrous@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        24 hours ago

        This doesn’t help your specific problem, but for what it’s worth: airvpn allows you to set a port # which is retained when the VPN hops to a new server, or is reset. In other words, I set the port # in airvpn a year ago, and i have kept the same port since. I haven’t kept super up to date on VPN trustworthiness, so maybe airvpn is no longer recommended.

  • hyphen612@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    2
    ·
    23 hours ago

    Ive been successfully using that exact stack for a few months. I’d recommend using wireguard instead of openvpn.

    Also, add a the gluetun health check and add condition: service_healthy to your qbittorrent dependency.

    You can also simplify your port forwarding quite a bit. Here’s a link to how I have it setup. Qbittorrent won’t start until gluetun has a healthy connection. Then it repeatedly runs your port forwarding command until it gets an OK exit.

    Port forwarding for torrenting shouldn’t affect your webui accessibility so it’s also possible your qbittorrent is failing before gluetun comes in.

    • Scrath@lemmy.dbzer0.comOP
      link
      fedilink
      English
      arrow-up
      4
      ·
      23 hours ago

      I know that the port forwarding command can be simplified. In my case its this complex because the way it is listed in the gluetun wiki did not work even though I disabled authentication for my local network. The largest part of the script is authenticating with the username and password before actually sending the port forwarding command.

      I’ll definitely try adjusting my stack to your variant though. I’ve also tried the healthcheck option before but I must have configured it wrong because that caused my gluetun container to get stuck.

      One question regarding your stack though, is there a specific reason for binding /dev/net/tun to gluetun?