Docker deploy of Gluetun+Qbittorrent has no connection on Dietpi (but works on X86 machine)

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version |
    G_DIETPI_VERSION_CORE=9
    G_DIETPI_VERSION_SUB=14
    G_DIETPI_VERSION_RC=2
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’
    G_LIVE_PATCH_STATUS[0]=‘not applied’

  • Distro version | bookwork 0

  • Kernel version | Linux DietPi 6.12.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux

  • Architecture | arm64

  • SBC model | RPi 5 Model B (aarch64)

  • Power supply used | RaspPi official power supply

  • SD card used | NVME drive via Hat

Additional Information (if applicable)

  • Software title | Docker
  • Was the software title installed freshly or updated/migrated? Freshly

Steps to reproduce

I’m having an issue deploying a VPN + Qbittorrent stack via Docker on my DietPi device. The setup uses Docker Compose with Gluetun (NordVPN) and Qbittorrent. It works fine on my x86_64 VM, but on DietPi, while Gluetun connects successfully, Qbittorrent can’t connect to the internet. This is tested via ipleak.net where I cannot get any connection, nor with test torrents.

I’ve tested with different torrent clients (e.g., Deluge) and VPN containers (e.g. separate dedicated NordVPN and Nordlynx container builds), but the result is the same: works on x86_64, fails on DietPi. I’ve also tried various different port combinations. Without the VPN, Qbittorrent connects fine. Gluetun also works with other containers. Inside the Qbittorrent container, I can resolve and ping domains, yet no actual connectivity in Qbittorrent itself. In Qbittorrent I get no change with specifying the network device (eth0, tun0 etc)

Both systems are behind the same Pi-hole DNS setup (hosted on the same RaspPi I’m running docker), and the device has no other VPN software installed. I have no firewall installed on the device. I’ve seen forum mentions of Docker bridge issues on DietPi, especially when a VPN server runs directly on the host, but that doesn’t apply here—just Pi-hole is installed.

I’m aware of alternative approaches (e.g. running a VPN + torrent client natively instead), but I want to understand why this setup fails on DietPi but not on x86_64. Is this a DietPi/Docker bug or a misconfiguration I’m overlooking?

Expected behaviour

Deploying the docker compose file on Dietpi should set up Gluetun and Qbittorrent in the same way as deploying it on x86 machine. I have tried various mixes of VPNs and Torrent clients to try to exclude bugs specifically within the ARM versions of the docker services with the same result. That is still possible though (e.g. maybe a common library in the docker builds for arm devices rather than a dietpi issue?).

Actual behaviour

Gluetun and Qbittorrent launch without issue in Docker, and Gluetun connects to my VPN provider. I can ping addresses from within the Qbittorrent container and I can also reach ipleak and it shows my VPN IP. But in Qbittorrent itself I get no connection - on announce of the Ipleak magnet it times out and Qbittorrent shows no connection (red globe icon etc).

Extra details

This is the docker compose file I’ve been using.
docker-compose.yml

services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: vpn
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun # I've added this most recently but no change
    ports:
      - 22836:22836  
      - 22836:22836/udp
      - 8080:8080
    environment:
      - VPN_SERVICE_PROVIDER=nordvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=[REDACTED]
      - SERVER_CATEGORIES=p2p
    volumes:
      - /home/dietpi/torrent:/gluetun
    restart: unless-stopped
  qbittorrent:
    image: ghcr.io/linuxserver/qbittorrent
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - WEBUI_PORT=8080
      - TORRENTING_PORT=22836
    volumes:
      - /home/dietpi/torrent/qbt/config:/config
      - /home/dietpi/torrent/downloads:/downloads
    network_mode: "container:vpn"
    restart: unless-stopped
    depends_on:
      gluetun:
        condition: service_healthy

Any insight would be much appreciated! As I say, I’m interested in fixing this specifically out of curiosity rather than alternative approaches (such as abandoning Docker). I’m interested in understanding why it isn’t working on my Dietpi install.

Many thanks!

It’s pretty hard to help without a log or error message. Next, where have you seen comments related to a DietPi / Docker issue? I am not aware of any issues on this site. Some references would be helpful.

In such cases, it would be a good idea to contact the Docker container developer to find out from them what the problem might be and how to troubleshoot it. They should know their container best.

Ok thanks.

As I said it is multiple different containers tried in combination with the same result each time. I’ve tried 3 different VPN containers combined with 2 different Bittorrent containers and am getting the same result each time, but only on Dietpi. They work each time on an X86 VM. In all cases, there is no bittorrent connectivity.

I can share the qbittorrent logs but they’re from inside the container; but essentially the connections keep timing out and there are no specific errors that I can find. As you say that’s probably more relevant to the container maker (s). But the common denominator as fas as I can see currently is docker on dietpi.

In terms of the bug I mentioned; this is it on the tracker and it has been open since 2019: DietPi-Software | Docker: Inter-container bridge broken by VPN · Issue #2863 · MichaIng/DietPi · GitHub Maybe it’s been fixed and never closed but as I said it’s the only thing I could find that seemed relevant.

I’ve been thinking about it today and I’m going to try making a custom docker bridge network (rather than rely on the automated set up), and if that doesn’t work then try the same stack with Raspbian OS and a fresh DietPi image on SD cards. I’m just curious to find the cause. :man_shrugging:

Ok so I’ve found out the potential problem thanks to Reddit: Docker v28.0.0 up appears to have a potential bug on Arm builds which breaks the network security set up. The bug seems to not be on X86_64 builds or systems. I don’t know exactly what the nature of the bug is.

The details of a temporary workaround (downgrading Docker) are available here: https://www.reddit.com/r/gluetun/comments/1l5hrbt/fix_gluetun_containers_not_working_with_raspberry/

Obviously downgrading packages is far from ideal for numerous reasons but I share it incase people need it until this is fixed. I’ll probably move to native hosting my VPN and QBittorent servers as a better work around.

I’ve tested their workaround though - as suggested I rolled my docker back to v27.5.1 using this command:

sudo apt install docker-compose-plugin=2.32.4-1~debian.12~bookworm docker-ce-cli=5:27.5.1-1~debian.12~bookworm docker-buildx-plugin=0.20.0-1~debian.12~bookworm docker-ce=5:27.5.1-1~debian.12~bookworm docker-ce-rootless-extras=5:27.5.1-1~debian.12~bookworm

And a hold can be put on upgrading the affected packages using this command (With sudo apt-mark unhold… to undo):

sudo apt-mark hold docker-compose-plugin=2.32.4-1~debian.12~bookworm docker-ce-cli=5:27.5.1-1~debian.12~bookworm docker-buildx-plugin=0.20.0-1~debian.12~bookworm docker-ce=5:27.5.1-1~debian.12~bookworm docker-ce-rootless-extras=5:27.5.1-1~debian.12~bookworm

I composed up my docker-compose.yml and my stack is working exactly as expected now, and exactly as it was on on my X86_64 machine. It instantly connects to trackers.

At face value this appears to be a Docker bug but I suppose it could also be some other configuration issue on Pi devices conflicting with Docker that needs correcting since Docker updates? I have no idea but this is relevant for Dietpi as it may be having other unintended consequences when people deploy Docker stacks.

And to reiterate, while this fix and issue has specifically come from a Gluetun container and community, I have tested with 3 different VPN tools released in totally separate containers (Gluetun, Nordvpn and Nordlynx stacks) all working on X86 and all with the exact same issue on Dietpi, and I have also tested using NordVPN and ProtonVPN as the actual VPN service.

Unfortunately, this is not the first time that Docker as an application itself has caused problems without the underlying operating system such as RPI OS or DietPi being able to do anything about it. Personally, I would always try to install applications natively if possible. Especially on DietPi we have ready to use workflows for VPN and Qbit.

I had this issue and was able to solve it.

In QBitorrent settings → advanced

I set network interface from “auto” to “tun0”
I set “optional IP address to bind to” to match my VPN server IP.

Started working. Didn’t see this solution anywhere so registered just to share it.

1 Like