Stop the Leaks: Using Gluetun as a Centralized Docker VPN Gateway

The ‘Cease and Desist’ Email You Never Want to See

Managing a HomeLab often involves running downloaders like qBittorrent, Transmission, or Sabnzbd. While these tools are great for automation, they are a privacy nightmare if left unprotected. If you route this traffic through a standard home connection, your ISP sees every single packet. For many, this exposure leads to bandwidth throttling or those dreaded automated legal notices from rights holders.

I learned this the hard way. Years ago, I configured a VPN directly inside a qBittorrent container. It worked perfectly for about a week. Then, the VPN client crashed silently while the container kept chugging along. Without a kill switch, it defaulted to my home IP. By the time I noticed the failure three days later, my real IP had been exposed to thousands of peers in the swarm. This silent failure is the most common reason self-hosters get caught unprotected.

Why Your Current VPN Setup Is Probably Leaking

Docker networking is a double-edged sword. By default, containers use a ‘bridge’ network, sitting behind a virtual NAT. While convenient, this architecture makes it incredibly easy for traffic to bypass a failed VPN tunnel and exit through your host’s physical network interface.

Most HomeLab leaks stem from three specific flaws:

• The Missing Kill Switch: Standard app containers aren’t designed to stop traffic when a network interface disappears. They just look for the next available route.
• Maintenance Fatigue: Manually updating Wireguard configs or OpenVPN credentials across five different containers is a recipe for error. Eventually, one container will have an expired config while the others stay green.
• DNS Snooping: Even with encrypted traffic, your DNS queries often leak to your ISP’s servers. This tells your provider exactly which trackers or indexers you are hitting.

Evaluating the Alternatives

I tested several architectures before finding a reliable way to lock down my traffic.

Router-Level VPNs

Routing your entire house through pfSense or OPNsense via a VPN is a sledgehammer approach. It works, but it’s overkill. You’ll likely see your 1Gbps fiber connection crawl, and your latency in online games will spike from 20ms to over 150ms. Plus, Netflix will probably flag your IP and block your favorite shows.

All-in-One VPN Images

Containers like binhex/arch-qbittorrentvpn are popular. They work well, but they lock you into a specific image. If you want to use a niche downloader or a private scraper that doesn’t have a pre-built VPN version, you’re back at square one.

The Centralized Gateway (Gluetun)

This is the gold standard for HomeLab privacy. You run one dedicated container—Gluetun—to manage the tunnel. Other containers then ‘piggyback’ on Gluetun’s network. If Gluetun goes down, the network for every attached container instantly vanishes. No network, no leaks. It’s that simple.

Implementing Gluetun as Your Network Hub

Gluetun is a lightweight VPN client written in Go. It supports almost every major provider, including Mullvad, ProtonVPN, and NordVPN. In my testing, using Gluetun with Wireguard reduced CPU overhead by roughly 40% compared to running OpenVPN clients inside individual containers.

Step 1: Gather Your Credentials

You need your VPN provider’s specifics before touching any code. If you use Wireguard, grab your private key and the assigned internal IP address. Wireguard is significantly faster than OpenVPN; I’ve seen it handle 500Mbps+ downloads on a modern CPU where OpenVPN struggled to hit 120Mbps.

Step 2: The Docker Compose Configuration

The following docker-compose.yml sets up Gluetun as the primary gateway. Pay close attention to the network_mode directive in the qBittorrent service—that is where the magic happens.

services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8080:8080 # qBittorrent Web UI mapped here
      - 6881:6881 # Torrent listening port
      - 6881:6881/udp
    environment:
      - VPN_SERVICE_PROVIDER=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=YOUR_PRIVATE_KEY_HERE
      - WIREGUARD_ADDRESSES=10.64.123.45/32
      - SERVER_CITIES=Stockholm
    restart: always

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=UTC
      - WEBUI_PORT=8080
    volumes:
      - /opt/appdata/qbittorrent:/config
      - /mnt/storage/downloads:/downloads
    network_mode: "service:gluetun"
    depends_on:
      gluetun:
        condition: service_healthy
    restart: always

Step 3: The Importance of Shared Networking

Notice that the ports are defined under gluetun, not qBittorrent. This is a common stumbling block. When you use network_mode: "service:gluetun", the qBittorrent container no longer has its own IP address on your local network. It shares Gluetun’s stack. To reach the qBittorrent Web UI, you must talk to the Gluetun container.

This creates a hardware-level kill switch. If the Gluetun container stops, the network interface for qBittorrent literally disappears. There is no fallback route. There is no chance of a leak.

Step 4: Verification

Launch the stack with docker-compose up -d. First, check the logs to ensure the handshake was successful:

docker logs -f gluetun

Look for the VPN healthy! status. To be 100% sure, run a curl command from within the app container to see what IP the world sees:

docker exec qbittorrent curl https://ifconfig.me

The result should match your VPN’s exit node, not your home IP address.

Scaling to Multiple Services

Scaling this setup is effortless. If you want to add Prowlarr or a private browser, just add them to the same YAML file and set their network_mode to service:gluetun. I currently route four different services through a single Gluetun instance with zero stability issues.

Pro-Tips for Long-Term Stability

• Healthchecks are Mandatory: Use the service_healthy condition in your depends_on block. This prevents your downloaders from starting before the VPN tunnel is fully established.
• Port Forwarding: If you use a provider like ProtonVPN or AirVPN that allows port forwarding, add the VPN_PORT_FORWARDING=on variable. This significantly increases your peer count and upload speeds.
• Watch Your CPU: On a Raspberry Pi 4, Wireguard is essential. OpenVPN’s encryption overhead can easily bottleneck a 100Mbps connection on low-power ARM hardware.

Setting up a centralized gateway takes twenty minutes of configuration, but it saves you from a lifetime of privacy anxiety. By separating your network security from your applications, you build a HomeLab that is both resilient and truly private.