gluetun: Bug: qBittorrent stops listening to the open port after the gluetun VPN restarts internally

Is this urgent?

Host OS

Ubuntu 22.04

CPU arch

x86_64

VPN service provider

Custom

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2022-12-31T17:50:58.654Z (commit ea40b84)

What’s the problem 🤔

Everything works as expected when qBittorrent and gluetun containers are freshly started. The qBittorrent is listening on the open port and it is reachable via the internet. However, when gluetun runs for a longer period of time and for some reason the VPN stops working for a brief time, trigerring gluetun’s internal VPN restart, the open port in qBittorrent is no longer reachable.

What I found out was that by changing the open listening port in qBittorrent WebUI settings to some random port, saving the configuration and then immediately after that reverting the change to the original port, it starts listening and it is now once again reachable. Or just restarting the qBittorrent container without changing anything also worked.

Is there anything gluetun can do to prevent this? Is this solely qBittorrent’s bug? Unfortunately, I have no idea.

Thanks!

Share your logs

INFO [healthcheck] program has been unhealthy for 36s: restarting VPN
INFO [vpn] stopping
INFO [firewall] removing allowed port xxxxxx...
INFO [vpn] starting
INFO [firewall] allowing VPN connection...
INFO [wireguard] Using available kernelspace implementation
INFO [wireguard] Connecting to yyyyyyyyy:yyyyy
INFO [wireguard] Wireguard is up
INFO [firewall] setting allowed input port xxxxxx through interface tun0...
INFO [healthcheck] healthy!

Share your configuration

No response

About this issue

Original URL
State: open
Created a year ago
Reactions: 13
Comments: 39 (15 by maintainers)

Most upvoted comments

I’ve gone ahead and made a container portcheck purely to monitor the incoming port status and automatically change the port and then back if it’s inaccessible.

Docker Compose example

version: "3"

services:
  gluetun:
    cap_add:
      - "NET_ADMIN"
    container_name: "gluetun"
    devices:
      - "/dev/net/tun:/dev/net/tun"
    environment:
      VPN_SERVICE_PROVIDER: "mullvad"
      VPN_TYPE: "wireguard"
      WIREGUARD_PRIVATE_KEY: "👀"
      WIREGUARD_ADDRESSES: "👀"
      SERVER_CITIES: "Amsterdam"
      OWNED_ONLY: "yes"
      FIREWALL_VPN_INPUT_PORTS: "6881"
    image: "qmcgaw/gluetun:latest"
    ports:
      # qBittorrent
      - "8080:8080"
    restart: "always"
    volumes:
      - "./gluetun:/gluetun"

  qbittorrent:
    container_name: "qbittorrent"
    depends_on:
      - "gluetun"
    environment:
      PUID: "1000"
      PGID: "1000"
      TZ: "Etc/UTC"
      WEBUI_PORT: "8080"
    image: "lscr.io/linuxserver/qbittorrent:latest"
    network_mode: "service:gluetun"
    restart: "always"
    volumes:
      - "./qbittorrent:/config"
      - "./torrents:/downloads"

  portcheck:
    container_name: "portcheck"
    depends_on:
      - "gluetun"
      - "qbittorrent"
    environment:
      QBITTORRENT_PORT: "6881"
      QBITTORRENT_WEBUI_PORT: "8080"
      QBITTORRENT_WEBUI_SCHEME: "http"
      QBITTORRENT_USERNAME: "admin"
      QBITTORRENT_PASSWORD: "adminadmin"
      TIMEOUT: "300"
      DIAL_TIMEOUT: "5"
    image: "eiqnepm/portcheck:latest"
    network_mode: "service:gluetun"
    restart: "always"

Environment variables

Variable	Default	Description
`QBITTORRENT_PORT`	`6881`	qBittorrent incoming connection port
`QBITTORRENT_WEBUI_PORT`	`8080`	Port of the qBittorrent WebUI
`QBITTORRENT_WEBUI_SCHEME`	`http`	Scheme of the qBittorrent WebUI
`QBITTORRENT_USERNAME`	`admin`	qBittorrent WebUI username
`QBITTORRENT_PASSWORD`	`adminadmin`	qBittorrent WebUI password
`TIMEOUT`	`300`	Time in seconds between each port check
`DIAL_TIMEOUT`	`5`	Time in seconds before the port check is considered incomplete

I’ve just updated the container to not rely on the Gluetun HTTP control server for the public IP address of the VPN connection, it now uses the outbound address from within the Gluetun service network to check the qBittorrent incoming port, this also has the added benefit of not needing to query the qBittorrent incoming port from the public IP address of your server.

For anyone that was using this before I made the change, make sure to run the container inside of the Gluetun service network and update the environment variables which have changed.

eiqnepm on Mar 13, 2023

I’ve gone ahead and made a container portcheck purely to monitor the incoming port status and automatically change the port and then back if it’s inaccessible.

Thank you for writing this - works great!

For others experiencing this issue, I’m wondering if it would also help to increase the HEALTH_VPN_DURATION_INITIAL config option. I’m seeing 6 reconnects in the last 12 hours, which seems really high.

Is the default setting of 6 seconds too sensitive?

stvsu on Mar 13, 2023

FYI when the healthcheck fails and the VPN gets restarted, now port forwarding should re-trigger properly (it was bugged) on the latest image + future release v3.36.0 with commit 71201411f47f1f558290444c7921d82edce9c728

Qbittorrent might still fail to see the port changed, see the last few comments in https://github.com/qdm12/gluetun/issues/1797 - essentially it’s not aware of the tunnel being changed and its pool of connections no longer work, that’s why changing the port through its API fixes it.

qdm12 on Sep 23, 2023

@eiqnepm I am having this issue with qbittorrent but also other containers linked to gluetun (radarr, sonarr, bazarr, jackett), all of them become inaccesible after gluetun restarts the connection, could your portcheck container work with other containers apart from qbittorrent?

heisenberg2980 on Aug 9, 2023

@eiqnepm I am bit confused by the portcheck. Does portcheck change the qbt port to a random one and then after sometime change the port back to the original one (the one configured with port forwarding)?

It’s checks if the port is currently accessible using the private address of the tunnel, if it is not accessible it will change the port to zero, basically disabling port forwarding for a brief moment, and then it will set the port back to what is set using the QBITTORRENT_PORT environment variable.

eiqnepm on Jul 18, 2023

and isn’t on the UNRAID app portal

Under apps and then setting, enable additional search results from dockerHub.

The container is very lightweight. It could be implimented into Gluetun, I even made an issue upon request https://github.com/qdm12/gluetun/issues/1441#issue-1612862391, however I don’t currently understand the inner workings of Gluetun and don’t have the ability to implement the feature myself at this time.

If the maintainer decides this is an issue that Gluetun should resolve first hand, it should not be a very daunting task, considering I managed to get it done with just over two-hundred lines of Go.

eiqnepm on May 23, 2023

I’ve gone ahead and made a container portcheck purely to monitor the incoming port status and automatically change the port and then back if it’s inaccessible.

Thank you for writing this - works great!

For others experiencing this issue, I’m wondering if it would also help to increase the HEALTH_VPN_DURATION_INITIAL config option. I’m seeing 6 reconnects in the last 12 hours, which seems really high.

Is the default setting of 6 seconds too sensitive?

I can confirm that this fixed it for me. I set HEALTH_VPN_DURATION_INITIAL=120s about two weeks ago and haven’t had this problem since.

Comcast hiccups often in my area, so 6 seconds was definitely too aggressive for me

kjwill555 on Mar 14, 2023