Help Debugging Wireguard/TorGuard with QBitTorrent

Apps and Virtualization
1

I have been pulling my hair out for three days trying to migrate from my TrueCharts (24.04) setup to Docker Compose (25.04).

Previously I had QBitTorrent running with a Wireguard VPN to TorGuard. I was able to login to the web UI locally, and my torrent traffic went through the VPN.

I have read several posts here today and have made a little progress, but still cannot get it to work completely.

Here’s where I am now:

  • With the Table, PostUp, and PostDown settings in my Wireguard config, I am able to access the web UI
  • The wg0 interface shows in the web UI advanced settings tab
  • Torrents will not start, and it indicates it is disconnected from the Internet
  • If I switch to “any” interface in the advanced settings tab, torrents work, but not through the VPN
  • If I remove the Table, PostUp, and PostDown settings in the Wireguard config, I am unable to access the web UI (and it still doesn’t seem that torrent traffic is going through the VPN)
  • The Wireguard config file is the same I was using in TrueCharts, except that I commented out the DNS entry as I read that can cause problems
  • I am using TorGuard’s Torrent IP Detector magnet link and service to check the origin IP
  • I am also using Debian and Ubuntu ISO torrents (which connect, but error out; but that’s a different problem to work out later)
  • Yes, I use some 172.16 subnets for my network, and I have Docker changed in TrueNAS to use 10.32/16. This is working fine with other services.

Compose:

services:
  wireguard:
    image: lscr.io/linuxserver/wireguard:latest
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - PUID=568
      - PGID=568
      - TZ=America/Chicago
    volumes:
      - /mnt/vol1/crypt/home/yottabit/wireguard/92.conf:/config/wg_confs/wg0.conf
      - /lib/modules:/lib/modules
    ports:
      - 10009:8080
      - 54583:6861/tcp
      - 54583:6861/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: service:wireguard
    environment:
      - PUID=568
      - PGID=568
      - TZ=America/Chicago
      - WEBUI_PORT=8080
      - LAN_NETWORK=172.16.42.0/24
    volumes:
      - /mnt/vol1/docker/config/qbittorrent:/config
      - /mnt/ssd_scratch/incoming_media:/incoming_media
      - /mnt/vol1/movies:/mnt/movies
      - /mnt/vol1/tv:/mnt/tv
      - /mnt/vol1/audio_books:/mnt/audio_books
    #    tmpfs:
    #      - /incoming_media:mode=1777
    #    ports:
    #      - 10009:8080
    #      - 54583:6861/tcp
    #      - 54583:6861/udp
    depends_on:
      - wireguard
    restart: unless-stopped
networks: {}

Wireguard:

# TorGuard WireGuard Config
[Interface]
PrivateKey = ...
ListenPort = 57062
MTU = 1420
#DNS = 1.1.1.1
Address = 10.13.128.85/24
Table = 1000
PostUp = ip -4 route change default via 10.13.128.1 table 1000
PostUp = ip -4 rule add priority 1 from 10.13.128.85 table 1000
PostDown = ip -4 rule del priority 1 from 10.13.128.85 table 1000

[Peer]
PublicKey = ...
AllowedIPs = 0.0.0.0/0
Endpoint = 77.81.139.74:1443
PersistentKeepalive = 25

Any ideas here what I am missing?

2

It looks like the DNS inside the container can’t resolve trackers (you commented out DNS= in your Wireguard config).

The simplest solution would be to restore DNS (Cloudflare, Quad9, Google or a TorGuard address, if they provided one). Then remove the custom policy routing lines (Table, PostUp, PostDown). Let wg-quick manage the default route inside the container.

I know you said you intentionally commented out the DNS entry, but did you try it with DNS enabled?

3

Thanks for the reply. I uncommented DNS but the results are the same. I should note that with and without DNS commented out, I can connect to the trackers just fine. I just can’t seem to get packets to go out the VPN tunnel.

Doing a traceroute in the wireguard container still shows it routing through my IP instead of the VPN:

root@6459a0d22ed6:/# ping google.com
PING google.com (142.251.186.139) 56(84) bytes of data.
64 bytes from lcdfwe-in-f139.1e100.net (142.251.186.139): icmp_seq=1 ttl=108 time=3.09 ms
64 bytes from lcdfwe-in-f139.1e100.net (142.251.186.139): icmp_seq=2 ttl=108 time=5.79 ms
64 bytes from lcdfwe-in-f139.1e100.net (142.251.186.139): icmp_seq=3 ttl=108 time=3.91 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 3.090/4.263/5.794/1.132 ms
root@6459a0d22ed6:/# traceroute google.com
traceroute to google.com (142.250.114.100), 30 hops max, 46 byte packets
 1  10.32.3.1 (10.32.3.1)  0.007 ms  0.008 ms  0.005 ms
 2  rb1.example.com (172.16.42.1)  0.317 ms  0.261 ms  0.243 ms
 3  example.com (x.x.x.x)  3.322 ms  3.355 ms  3.733 ms
....

Hop #3 is my ISP public address.

How do I use wg-quick in the container? Oh, I see, wg-quick is what uses the wireguard conf file. I’ll see if I can figure that out. But the problem is that it still doesn’t route anything to the VPN even without the custom routing rules. And I can’t access the web UI without those.

The default route is not being set in the wireguard container:

root@6459a0d22ed6:/# ip route
default via 10.32.3.1 dev eth0 
10.13.128.0/24 dev wg0 proto kernel scope link src 10.13.128.85 
10.32.3.0/24 dev eth0 proto kernel scope link src 10.32.3.2
4

I have now tried using Gluetun now instead of Wireguard, and even used the TorGuard example config file from their website. If I shell into the gluetun container (from a compose file with only gluetun), I don’t see a default route, and can’t ping Internet IPs.

I am at a loss here. I may need to reboot the whole server? That seems a bit of a problem if so…

5

Reboot of the server didn’t make a difference. I have also now tried two more integrated images:

  • DyonR/docker-qbittorrentvpn
  • tenseiken/docker-qbittorrent-wireguard

Neither are working for me.

I’m really at a loss here. At this point I think it has to be some bug with TrueNAS? Seems unlikely, but I have no more ideas.

Maybe I will try the 25.10-RC and see if anything is different. :-/