Deluge may expose your real IP

[CalebFenton]

Thanks for making the docker compose. I really like the approach versus having a single, complex docker container and think this is the right way to do things. But it seems like traffic isn't forced through the VPN. Deluge reports my real external IP, even after setting the network device to wg0.

[CalebFenton]

I settled on just using gluetun and deluge. Seems to be working ok. Maybe you'll like this better? I'm not sure what the nginx proxy was for.

version: "3.7"

services:
  deluge:
    image: linuxserver/deluge
    restart: unless-stopped
    network_mode: service:gluetun
    volumes:
      - ./data/deluge/config:/config
      - downloads-data:/data
    environment:
     # my volume is cifs and expects this
      - PUID=1000
      - GUID=1000

  gluetun:
    image: qmcgaw/gluetun:latest
    container_name: gluetun-torrent
    cap_add:
      - NET_ADMIN
    environment:
      - TZ=America/Chicago
      - VPN_SERVICE_PROVIDER=xxxxx
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=xxxxx
      - WIREGUARD_PRESHARED_KEY=xxxxx
      - WIREGUARD_ADDRESSES=10.1.1.1/32, xxxxx
      - SERVER_REGIONS=America,Asia,Europe,Oceania
      # Allow access from local subnet and VPN subnet
      - FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24,10.1.1.1/32
      - FIREWALL_INPUT_PORTS=8112,12345
      - FIREWALL_VPN_INPUT_PORTS=12345
    ports:
      - 8112:8112/tcp
      - 12345:12345/tcp # whatever you setup port forwarding for
      - 12345:12345/udp

volumes:
  downloads-data:

[master-hax]

Hey @CalebFenton, glad you got it working with gluetun. These days I use nginx to access the deluge container locally using unix domain sockets which is in my opinion more simple & reliable than firewall or IP rule setup. You can see an example in https://github.com/master-hax/compose-downloadsquad

I think the issue you ran into is that there are a few seconds while the VPN container is starting up where traffic is not forced through the VPN. This is probably most easily solved by adding a healthcheck directive to the VPN container so the deluge container doesn't attach until the VPN is up & running. A more secure approach would be to use network namespaces with wireguard but it requires the VPN container to be privileged (not just NET_ADMIN) on my machine.

Not sure why you are opening port 12345 on the docker host in your config if that is your peering port. That should only go through the VPN right?

[CalebFenton]

@master-hax thanks for the info about nginx and your explanation for leaking the IP seems plausible.

As for port 12345, yes, and that's what pretty much what gluetun + this config will do. The firewall is enabled by default and if it's enabled it forces traffic over the VPN. There's a small mistake here, which may be what you're referencing, where FIREWALL_INPUT_PORTS should just be 8112. This would allow someone on your local network to access 12345 or remotely if you're forwarding the port on your router. I was copying the config from another service that I wanted to be accessible from my LAN or through the VPN. Take 12345 out of FIREWALL_INPUT_PORTS and traffic should be limited to only being allowed over the VPN.

Before, I had deluge and openvpn in one container. This was ugly because multiple apps in a single container is not the docker way, but it was nice if the vpn crashed or failed health checks, you could just restart the single container. By sharing networking between containers, if the vpn goes down, both containers need to be restarted, and I haven't seen an easy way to do this using only docker-compose.