qBittorrent traffic routing through eth0 instead of tun0 with AirVPN WireGuard on Ugreen NAS (UGOS Pro)

[teemyster]

Environment

Host OS: UGOS Pro (Ugreen DXP4800 Plus NAS)
Docker: Running via Portainer
Gluetun version: v3.41.0
VPN provider: AirVPN
VPN type: WireGuard
qBittorrent image: lscr.io/linuxserver/qbittorrent:libtorrentv1
Network mode: network_mode: "service:gluetun"

Problem
All torrents immediately show "Errored" status in qBittorrent with 0 peers and 0 seeds. Trackers show "Not contacted yet" and never progress.

What we've confirmed works

• Gluetun connects successfully to AirVPN Toronto server
• Public IP from Gluetun confirms AirVPN IP: 184.75.208.122
• Public IP from qBittorrent container also confirms AirVPN IP via curl
• AirVPN port checker shows port as "Open!" on TCP and UDP
• qBittorrent can reach tracker URLs — curl https://torrent.ubuntu.com/announce from inside qBittorrent container successfully connects and returns a response
• File permissions on download directories are correct (777, UID 1000)
• Fresh qBittorrent config rules out corrupted settings

Root cause identified
The policy routing rules show traffic from 172.21.0.2 (the container's eth0 IP) is being caught by rule 100 and routed through eth0 (table 200) instead of tun0 (table 51820):

ip rule list output:
0: from all lookup local
98: from all to 172.21.0.0/16 lookup main
99: from all to 172.21.0.0/16 lookup 199
100: from 172.21.0.2 lookup 200
101: not from all fwmark 0xca6c lookup 51820
32766: from all lookup main
32767: from all lookup default

ip route show table all:
default dev tun0 table 51820
default via 172.21.0.1 dev eth0 table 200
default via 172.21.0.1 dev eth0
172.21.0.0/16 dev eth0 proto kernel scope link src 172.21.0.2

Rule 100 catches all traffic originating from 172.21.0.2 and routes it through eth0 via table 200, bypassing the VPN tunnel entirely. Rule 101 (which should route unmarked traffic through tun0) never gets reached for qBittorrent's connections.

The mangle table is completely empty — no packet marking rules exist:

iptables -t mangle -L -n -v
All chains empty (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING)

What we've tried

• FIREWALL_VPN_INPUT_PORTS=<redacted> — configured correctly
• FIREWALL_OUTBOUND_SUBNETS=172.21.0.0/16 — added, created rule 99 but didn't resolve routing issue
• FIREWALL_OUTBOUND_SUBNETS=0.0.0.0/0 — rejected by Gluetun v3.41.0 with error "outbound subnet has an unspecified address"
• VPN_INTERFACE=tun0 — no effect on routing table
• sysctls: net.ipv4.conf.all.rp_filter=2 — no effect
• Manually adding ip rule add from 172.21.0.2 lookup 51820 priority 99 — routes traffic through VPN but breaks WebUI access since all traffic including WebUI goes through tun0

Docker Compose

yamlservices:
  gluetun:
    image: qmcgaw/gluetun:v3.41.0
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=airvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=<redacted>
      - WIREGUARD_PRESHARED_KEY=<redacted>
      - WIREGUARD_ADDRESSES=<redacted>
      - SERVER_COUNTRIES=Canada
      - FIREWALL_VPN_INPUT_PORTS=<redacted>
      - FIREWALL_OUTBOUND_SUBNETS=172.21.0.0/16
      - TZ=America/Toronto
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
      - 3000:3000
    restart: always
    networks:
      - torrent-net

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:libtorrentv1
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Toronto
      - WEBUI_PORT=8080
    volumes:
      - /volume2/app-data/qbittorrent:/config
      - /volume1/downloads:/downloads
    depends_on:
      - gluetun
    restart: always

networks:
  torrent-net:
    driver: bridge

Question
Is rule 100 (from 172.21.0.2 lookup 200) expected behavior when using network_mode: "service:gluetun"? It appears to intercept all outbound traffic from containers sharing Gluetun's network namespace before rule 101 can route it through tun0. Is there a supported configuration option to fix this, or is this a bug specific to certain Docker network configurations?

[KindaWrks]

I don't know how much help this will be but did you set the program to tun0 itself as the only usable interface?

[bluskye]

I had odd problems, but in the options in web UI did you do this?