gluetun: Bug: QBittorrent loses internet connectivity after running for some time

Is this urgent?

None

Host OS

Latest version of OpenMediaVault

CPU arch

x86_64

VPN service provider

Mullvad

What are you using to run the container

docker-compose

What is the version of Gluetun

I don’t see this line in my logs

What’s the problem 🤔

I recently switched from using an old deprecated docker container for qBittorrent with OVPN support built in. I am now running the latest qBittorrent docker from linuxserver along with gluetun using Mullvad/Wireguard. My issue is that qBittorrent will connect to torrents and work just fine for awhile but it will eventually become unable to connect to any peers. I do not know if this is a qBittorrent issue or a gluetun issue. Restarting the qBittorrent container solves the issue temporarily.

Share your logs

|   ├── VPN provider settings:
|   |   ├── Name: mullvad
|   |   └── Server selection settings:
|   |       ├── VPN type: wireguard
|   |       ├── Cities: atlanta ga
|   |       └── Wireguard selection settings:
|   └── Wireguard settings:
|       ├── Private key: oO...WA=
|       ├── Interface addresses:
|       |   └── 10.66.214.103/32
|       └── Network interface: tun0
├── DNS settings:
|   ├── DNS server address to use: 127.0.0.1
|   ├── Keep existing nameserver(s): no
|   └── DNS over TLS settings:
|       ├── Enabled: yes
|       ├── Update period: every 24h0m0s
|       ├── Unbound settings:
|       |   ├── Authoritative servers:
|       |   |   └── cloudflare
|       |   ├── Caching: yes
|       |   ├── IPv6: no
|       |   ├── Verbosity level: 1
|       |   ├── Verbosity details level: 0
|       |   ├── Validation log level: 0
|       |   ├── System user: root
|       |   └── Allowed networks:
|       |       ├── 0.0.0.0/0
|       |       └── ::/0
|       └── DNS filtering settings:
|           ├── Block malicious: yes
|           ├── Block ads: no
|           ├── Block surveillance: no
|           └── Blocked IP networks:
|               ├── 127.0.0.1/8
|               ├── 10.0.0.0/8
|               ├── 172.16.0.0/12
|               ├── 192.168.0.0/16
|               ├── 169.254.0.0/16
|               ├── ::1/128
|               ├── fc00::/7
|               ├── fe80::/10
|               ├── ::ffff:7f00:1/104
|               ├── ::ffff:a00:0/104
|               ├── ::ffff:a9fe:0/112
|               ├── ::ffff:ac10:0/108
|               └── ::ffff:c0a8:0/112
├── Firewall settings:
|   ├── Enabled: yes
|   └── VPN input ports:
|       └── 56595
├── Log settings:
|   └── Log level: INFO
├── Health settings:
|   ├── Server listening address: 127.0.0.1:9999
|   ├── Target address: cloudflare.com:443
|   ├── Read header timeout: 100ms
|   ├── Read timeout: 500ms
|   └── VPN wait durations:
|       ├── Initial duration: 6s
|       └── Additional duration: 5s
├── Shadowsocks server settings:
|   └── Enabled: no
├── HTTP proxy settings:
|   └── Enabled: no
├── Control server settings:
|   ├── Listening address: :8000
|   └── Logging: yes
├── OS Alpine settings:
|   ├── Process UID: 1000
|   ├── Process GID: 100
|   └── Timezone: US/Eastern
├── Public IP settings:
|   ├── Fetching: every 12h0m0s
|   └── IP file path: /tmp/gluetun/ip
└── Version settings:
    └── Enabled: yes
2022-12-08T17:50:48-05:00 INFO IPv6 is not supported
2022-12-08T17:50:48-05:00 INFO [routing] default route found: interface eth0, gateway 172.27.0.1 and assigned IP 172.27.0.2
2022-12-08T17:50:48-05:00 INFO [routing] adding route for 0.0.0.0/0
2022-12-08T17:50:48-05:00 INFO [firewall] setting allowed subnets...
2022-12-08T17:50:48-05:00 INFO [routing] default route found: interface eth0, gateway 172.27.0.1 and assigned IP 172.27.0.2
2022-12-08T17:50:48-05:00 INFO [dns over tls] using plaintext DNS at address 1.1.1.1
2022-12-08T17:50:48-05:00 INFO [http server] http server listening on [::]:8000
2022-12-08T17:50:48-05:00 INFO [healthcheck] listening on 127.0.0.1:9999
2022-12-08T17:50:48-05:00 INFO [firewall] allowing VPN connection...
2022-12-08T17:50:48-05:00 INFO [wireguard] Using available kernelspace implementation
2022-12-08T17:50:48-05:00 INFO [wireguard] Connecting to 45.134.140.130:51820
2022-12-08T17:50:48-05:00 INFO [wireguard] Wireguard is up
2022-12-08T17:50:48-05:00 INFO [firewall] setting allowed input port 56595 through interface tun0...
2022-12-08T17:50:48-05:00 INFO [dns over tls] downloading DNS over TLS cryptographic files
2022-12-08T17:50:48-05:00 INFO [dns over tls] downloading hostnames and IP block lists
2022-12-08T17:50:49-05:00 INFO [healthcheck] healthy!
2022-12-08T17:50:52-05:00 INFO [dns over tls] init module 0: validator
2022-12-08T17:50:52-05:00 INFO [dns over tls] init module 1: iterator
2022-12-08T17:50:52-05:00 INFO [dns over tls] start of service (unbound 1.15.0).
2022-12-08T17:50:52-05:00 INFO [dns over tls] generate keytag query _ta-4a5c-4f66. NULL IN
2022-12-08T17:50:52-05:00 INFO [dns over tls] ready
2022-12-08T17:50:53-05:00 INFO [vpn] You are running 1 commit behind the most recent latest
2022-12-08T17:50:53-05:00 INFO [ip getter] Public IP address is 45.134.140.139 (United States, Georgia, Atlanta)

Share your configuration

version: "3"
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    # line above must be uncommented to allow external containers to connect. See https://github.com/qdm12/gluetun/wiki/Connect-a-container-to-gluetun#external-container-to-gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8080:8080     # webgui
      - 56595:56595   # mullvad
      - 56595:56595/udp #mullvad
    volumes:
      - /srv/dev-disk-by-uuid-137ab035-ce9c-4366-b522-fd21bd139153/appdata/gluetun:/gluetun
    environment:
      # See https://github.com/qdm12/gluetun/wiki
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - FIREWALL_VPN_INPUT_PORTS=redacted
      - WIREGUARD_PRIVATE_KEY=redacted
      - WIREGUARD_ADDRESSES=redacted
      - SERVER_CITIES=Atlanta GA
      - PUID=1000
      - PGID=100
      - TZ=US/Eastern
    restart: unless-stopped
    
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=100
      - TZ=US/Eastern
      - WEBUI_PORT=8080
    volumes:
      - /srv/dev-disk-by-uuid-137ab035-ce9c-4366-b522-fd21bd139153/appdata/qbittorrent:/config
      - /srv/mergerfs/pool/data/torrents/:/data/torrents
    #ports:
      #- 8005:8005
      #- 56595:56595
      #- 56595:56595/udp
    depends_on:
      - gluetun      
    restart: unless-stopped

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 3
Comments: 38 (4 by maintainers)

Most upvoted comments

@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?

Yes, it does.

@jdoe29103 Although, it doesn’t really solve the issue as I just noticed that qBittorrent isn’t working (i.e. it can’t connect to trackers, fails the ipleak torrent test etc.) but I manually checked that I can ping from inside the container. I’ll try out the address binding method that you suggested.

Update: I bound it to the network tun0 instead of a specific IP, and that seems to be working well (it has the advantage that qBittorrent binds to both IPV4 and IPV6, and some of my private trackers seem to perform better with one or the other). My guess it that whenever the network from gluetun went down, qBittorrent bound itself to another network (which isn’t really connected to the internet) and for some reason refused to bind to tun0 when it came back on. So, restricting it to the proper network works.

SinTan1729 on Dec 19, 2022

Thats what I need to do. Bind tun0 in qbit settings and use libtorrentv1 image. Works like a dream

capsel22 on Apr 22, 2023

binding tun0 and ipv4 does not resolve for me on the latest gluetun (v3.33.0) and qb (lscr.io/linuxserver/qbittorrent) release

ksurl on Apr 22, 2023

@SinTan1729 I have been poking around with it the past week and I may have found a somewhat “better” fix. The other day I installed some updates on my OPNsense router which required a reboot. While the router rebooted I watched qBittorrent to see if it would recover once the router came back online and sure enough it did not and all torrents were stalled. However, after some trial and error it seems that binding the local IP address in qBittorrent’s advanced settings resolved this issue. It can survive a router reboot and come back online after I changed this. It has been going strong for a few days now so we shall see.

@qdm12 It could be. I have had this issue in the past with much older versions of qbittorrent in combination with OpenVPN. I have not tested an older version of qbittorrent with gluetun yet so that could also be a potential fix. I am going to poke around with it a bit more sometime this week and see what I can find.

A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:
healthcheck:
    test: ping 1.1.1.1 -nqc 1 > /dev/null 2>&1 || exit 1
    interval: 60s
    retries: 5
    start_period: 20s
    timeout: 10s
depends_on:
    gluetun:
        condition: service_healthy

@SinTan1729 does this cause qbittorrent to reboot if the gluetun container is restarted?

jdoe29103 on Dec 14, 2022

I’m also facing this issue. Looks like it might be a qBittorrent issue since gluetun seems to maintain the connection.

SinTan1729 on Dec 13, 2022

You’ve both said you’re using linuxserver/qbittorrent, have you tried linuxserver/qbittorrent:libtorrentv1 with these settings? Curious to see if it helps you too

EZ64cool on Apr 22, 2023

I’ve also been running into this issue and I’ve been bound to the tun0 adapter from the beginning. I have found a 100% repro rate with AirVpn, if you manually disconnect the session gluten is using through their website this issue will occur upon reconnection. Hopefully this will help someone more experienced find what’s happening as I haven’t been able to find out why yet 😁

EZ64cool on Dec 27, 2022

So it seems the issue is not completely resolved. I noticed this morning that many torrents were unable to connect to trackers and adding new torrents just stalled. It seems the issue still persists sadly.

jdoe29103 on Dec 23, 2022

A (not nice) solution that I ended up using it adding this in the docker-compose for qbittorrent:

healthcheck:
    test: ping 1.1.1.1 -nqc 1 -W 4 > /dev/null 2>&1 || exit 1
    interval: 60s
    retries: 5
    start_period: 20s
    timeout: 10s
depends_on:
    gluetun:
        condition: service_healthy

SinTan1729 on Dec 15, 2022

@jdoe29103

You’re probably ahead of me on this one, but I see in the linuxserver/qbittorrent Github page that they have the “temp” directory set to /downloads in the qbittorrent configuration file. I don’t see where that path is exposed in the WebUI, so is it possible you’re using up whatever free space is available in the container and a restart clears it out?

bnhf on Dec 9, 2022

@jdoe29103

My apologies then, I always thought those volume mappings mattered. 😃

bnhf on Dec 8, 2022