Bug: Torrent still working when Gluetun is paused

[Bubble2191]

Is this urgent?

No

Host OS

Debian 12

CPU arch

x86_64

VPN service provider

Surfshark

What are you using to run the container

docker-compose

What is the version of Gluetun

Running version latest built on 2024-11-18T09:49:16.711Z (commit 68ddbfc)

What's the problem 🤔

I am unsure if this issue is caused by qBittorrent or Gluetun, but I would like to share my observations. I have noticed that if I pause Gluetun, the qBittorrent container remains accessible and can continue downloading torrents as usual. Since pausing Gluetun changes its status to "unhealthy," this behavior should not be possible.
However, stopping or killing the container works correctly.
I am using the latest versions of both Gluetun and qBittorrent, and the issue occurs with both Portainer and Docker compose.

Share your logs (at least 10 lines)

2024-12-13T18:12:52Z INFO [routing] default route found: interface eth0, gateway 172.21.0.1, assigned IP 172.21.0.2 and family v4
2024-12-13T18:12:52Z INFO [routing] local ethernet link found: eth0
2024-12-13T18:12:52Z INFO [routing] local ipnet found: 172.21.0.0/16
2024-12-13T18:12:53Z INFO [firewall] enabling...
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --policy INPUT DROP
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --policy OUTPUT DROP
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --policy FORWARD DROP
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --policy INPUT DROP
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --policy OUTPUT DROP
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --policy FORWARD DROP
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append INPUT -i lo -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i lo -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o lo -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o lo -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o eth0 -s 172.21.0.2 -d 172.21.0.0/16 -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -d ff02::1:ff00:0/104 -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append INPUT -i eth0 -d 172.21.0.0/16 -j ACCEPT
2024-12-13T18:12:53Z INFO [firewall] enabled successfully
2024-12-13T18:12:53Z INFO [storage] creating /gluetun/servers.json with 20776 hardcoded servers
2024-12-13T18:12:53Z DEBUG [netlink] IPv6 is not supported after searching 0 routes
2024-12-13T18:12:53Z INFO Alpine version: 3.20.3
2024-12-13T18:12:53Z INFO OpenVPN 2.5 version: 2.5.10
2024-12-13T18:12:53Z INFO OpenVPN 2.6 version: 2.6.11
2024-12-13T18:12:53Z INFO IPtables version: v1.8.10
2024-12-13T18:12:53Z INFO Settings summary:
├── VPN settings:
|   ├── VPN provider settings:
|   |   ├── Name: surfshark
|   |   └── Server selection settings:
|   |       ├── VPN type: wireguard
|   |       ├── Countries: netherlands
|   |       └── Wireguard selection settings:
|   └── Wireguard settings:
|       ├── Private key: MG4...lI=
|       ├── Interface addresses:
|       |   └── 10.14.0.2/16
|       ├── Allowed IPs:
|       |   ├── 0.0.0.0/0
|       |   └── ::/0
|       └── Network interface: tun0
|           └── MTU: 1320
├── DNS settings:
|   ├── Keep existing nameserver(s): no
|   ├── DNS server address to use: 127.0.0.1
|   └── DNS over TLS settings:
|       ├── Enabled: yes
|       ├── Update period: every 24h0m0s
|       ├── Upstream resolvers:
|       |   └── cloudflare
|       ├── Caching: yes
|       ├── IPv6: no
|       └── 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:127.0.0.1/104
|               ├── ::ffff:10.0.0.0/104
|               ├── ::ffff:169.254.0.0/112
|               ├── ::ffff:172.16.0.0/108
|               └── ::ffff:192.168.0.0/112
├── Firewall settings:
|   └── Enabled: yes
├── Log settings:
|   └── Log level: debug
├── Health settings:
|   ├── Server listening address: 127.0.0.1:9999
|   ├── Target address: cloudflare.com:443
|   ├── Duration to wait after success: 5s
|   ├── 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
|   └── Authentication file path: /gluetun/auth/config.toml
├── Storage settings:
|   └── Filepath: /gluetun/servers.json
├── OS Alpine settings:
|   ├── Process UID: 1000
|   └── Process GID: 1000
├── Public IP settings:
|   ├── IP file path: /tmp/gluetun/ip
|   ├── Public IP data base API: ipinfo
|   └── Public IP data backup APIs:
|       ├── ifconfigco
|       ├── ip2location
|       └── cloudflare
└── Version settings:
    └── Enabled: yes
2024-12-13T18:12:53Z INFO [routing] default route found: interface eth0, gateway 172.21.0.1, assigned IP 172.21.0.2 and family v4
2024-12-13T18:12:53Z DEBUG [netlink] ip -4 rule list
2024-12-13T18:12:53Z DEBUG [netlink] ip -6 rule list
2024-12-13T18:12:53Z DEBUG [netlink] ip -f 0 rule add from 172.21.0.2/32 lookup 200 pref 100
2024-12-13T18:12:53Z INFO [routing] adding route for 0.0.0.0/0
2024-12-13T18:12:53Z DEBUG [routing] ip route replace 0.0.0.0/0 via 172.21.0.1 dev eth0 table 200
2024-12-13T18:12:53Z INFO [firewall] setting allowed subnets...
2024-12-13T18:12:53Z INFO [routing] default route found: interface eth0, gateway 172.21.0.1, assigned IP 172.21.0.2 and family v4
2024-12-13T18:12:53Z DEBUG [netlink] ip -4 rule list
2024-12-13T18:12:53Z DEBUG [netlink] ip -6 rule list
2024-12-13T18:12:53Z DEBUG [netlink] ip -f 0 rule add to 172.21.0.0/16 lookup 254 pref 98
2024-12-13T18:12:53Z INFO TUN device is not available: open /dev/net/tun: no such file or directory; creating it...
2024-12-13T18:12:53Z INFO [dns] using plaintext DNS at address 1.1.1.1
2024-12-13T18:12:53Z INFO [http server] http server listening on [::]:8000
2024-12-13T18:12:53Z INFO [healthcheck] listening on 127.0.0.1:9999
2024-12-13T18:12:53Z DEBUG [wireguard] Wireguard server public key: LxXXXig=
2024-12-13T18:12:53Z DEBUG [wireguard] Wireguard client private key: MG4...lI=
2024-12-13T18:12:53Z DEBUG [wireguard] Wireguard pre-shared key: [not set]
2024-12-13T18:12:53Z INFO [firewall] allowing VPN connection...
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append OUTPUT -d 212.102.35.204 -o eth0 -p udp -m udp --dport 51820 -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o tun0 -j ACCEPT
2024-12-13T18:12:53Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o tun0 -j ACCEPT
2024-12-13T18:12:53Z INFO [wireguard] Using available kernelspace implementation
2024-12-13T18:12:53Z INFO [wireguard] Connecting to 212.102.35.204:51820
2024-12-13T18:12:53Z DEBUG [netlink] ip -f inet rule add lookup 51820 pref 101
2024-12-13T18:12:53Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-12-13T18:12:53Z INFO [dns] downloading hostnames and IP block lists
2024-12-13T18:12:54Z INFO [healthcheck] healthy!
2024-12-13T18:12:54Z INFO [dns] DNS server listening on [::]:53
2024-12-13T18:12:54Z INFO [dns] ready
2024-12-13T18:12:55Z INFO [ip getter] Public IP address is 212.102.35.205 (Netherlands, North Holland, Amsterdam - source: ipinfo)
2024-12-13T18:12:55Z INFO [vpn] You are running on the bleeding edge of latest!

Share your configuration

services:
  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    environment:
      - VPN_SERVICE_PROVIDER=surfshark
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=XXX
      - WIREGUARD_ADDRESSES=10.14.0.2/16
      - SERVER_COUNTRIES=Netherlands
    volumes:
      - /docker/appdata/gluetun:/config
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
    restart: always

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - WEBUI_PORT=8080
    volumes:
      - /docker/appdata/qbittorrent:/config
      - /mnt/storage/data/torrents:/data/torrents
    depends_on:
      gluetun:
        condition: service_healthy

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[qdm12]

What do you mean by pausing gluetun?

[pietroballarin]

What do you mean by pausing gluetun?

I am using Portainer to pause the gluetun container, but I guess it would be the same as using the docker pause command.

[qdm12]

Interesting, indeed pausing the container other containers use as their network stack does not kill their network. This is even more odd since stopping a container does kill the network of connected containers.

However, there is nothing Gluetun can do, especially since it's unaware it's being frozen. This is more of container runtime oddity. However, what I can do is checkpoint every second the time to a temporary file (deleted at shutdown) and, if there is more than 1.5 second between the last checkpoint, it means gluetun was paused and so log a warning about the traffic being able to flow. There is no way to stop the traffic since the whole firewall/routing seems to be ignored if the container is paused.