Port not opening and general unreliability

[Enduriel]

I currently have the following stack up and running:

version: "3"
services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    network_mode: bridge
    cap_add:
      - NET_ADMIN
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
      - 8000:8000/tcp # Built-in HTTP control server
        # other containers ports
      - 6881:6881     # qBittorrent
      - 6881:6881/udp # qBittorrent
      - 50000:8080     # qBittorrent
    volumes:
      - /data/local/gluetun/data:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=custom
      - VPN_TYPE=wireguard
      - VPN_ENDPOINT_IP=[removed]
      - VPN_ENDPOINT_PORT=51820
      - WIREGUARD_PUBLIC_KEY=[removed]
      - WIREGUARD_PRIVATE_KEY=[removed]
      - WIREGUARD_ADDRESSES=10.2.0.2/32
      # - FIREWALL_OUTBOUND_SUBNETS=192.168.1.0/24 I also tried this
      - TZ=Europe/London
      # - VPN_DNS_ADDRESS=${VPN_DNS_ADDRESS}
    restart: unless-stopped

  qbittorrent:
    container_name: qbittorrent
    image: cr.hotio.dev/hotio/qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=002
      - TZ=Europe/London
    network_mode: "service:gluetun"
    volumes:
      - /data/local/qbittorrent/config:/config
      - /data/external/badssd/torrents:/downloads
    restart: unless-stopped

  qbittorrent_natmap:
    container_name: qbittorrent_natmap
    image: ghcr.io/soxfor/qbittorrent-natmap:latest
    environment:
      - QBITTORRENT_SERVER=10.2.0.2
      - VPN_GATEWAY=10.2.0.1
      - QBITTORRENT_PORT=8080
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    network_mode: "service:gluetun"
    depends_on:
      gluetun:
        condition: service_healthy
      qbittorrent:
        condition: service_started
    restart: unless-stopped

Basically, everything seems to be working correctly, and the logs from qbittorrent-natmap suggest everything is going well:

$ docker logs qbittorrent_natmap
2023-05-12 11:37:14 | VPN container gluetun in healthy state!
2023-05-12 11:37:19 | qBittorrent SessionID Ok!
2023-05-12 11:37:19 | Public IP: [publicIP]
2023-05-12 11:37:19 | Configured Port: 53371
2023-05-12 11:37:19 | Active Port: 53371
2023-05-12 11:37:19 | Port OK (Act: 53371 Cfg: 53371)
2023-05-12 11:37:21 | IPTables rule added for port 53371 on gluetun container
2023-05-12 11:37:21 | NAT-PMP/UPnP Ok!
2023-05-12 11:37:21 | Sleeping for 5 minutes
2023-05-12 11:42:21 | qBittorrent SessionID Ok!
2023-05-12 11:42:21 | Public IP: [publicIP]
2023-05-12 11:42:21 | Configured Port: 53371
2023-05-12 11:42:21 | Active Port: 53371
2023-05-12 11:42:21 | Port OK (Act: 53371 Cfg: 53371)
2023-05-12 11:42:22 | NAT-PMP/UPnP Ok!
2023-05-12 11:42:22 | Sleeping for 5 minutes

but the port isn't actually connectable when I check it on yougetsignal and my private tracker tests reports that it responds with connection refused. At one point it was reporting the port as open, but even then it completely refused to seed, and the private tracker stated that it was leeching and not seeding.
I'm going to be honest I'm pretty new to the homelab thing so this is very much a learning process for me but this solution you set up seems like exactly what I was looking for and I hoped it would work perfectly but I can't seem to get it set up, I'm happy to try and debug this in any way, just let me know what you need.
I have also tried the linuxserver qbittorrent with the same result.

[nrk666]

I just set this up two days ago and its been working great, my port shows open. The differences between my compose file and yours are:

1. gluetun config: identical on the parts that matter
2. qbittorrent config: identical on the parts that matter
3. nat-pmp : I leave VPN_GATEWAY empty, I also pass the login/pw to qbit even tho my lan/docker subnets are login bypassed in qbittorrent config.

Don't think either of those should matter though but maybe give it a shot. Or kind of a long shot add 10.2.0.2 to the bypass list in qbit. I don't think that is going to help tho.

Otherwise it looks right to me.

There are only two places this can go bad really. Either the gluetun container isn't opening the port or qbittorrent isn't actually listening on that port.

Check the iptables config on gluetun: "sudo docker exec -it gluetun /bin/sh" then "iptables -L -v -n", should see something like:

124K 6855K ACCEPT 6 -- tun0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:YOURPORT 372K 42M ACCEPT 17 -- tun0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:YOURPORT

If that looks ok, check qbittorrent for a few things:

1. make sure the port was correctly updated in Connection
2. make sure qbittorrent is binding to tun0 interface in Advanced. No reason to be on any other interface including "Any Interface".

There are other things you can try but take a little more know-how:

shut down qbit, find some other container you can run "netcat" or "nc" on using servce:gluetun
set netcat to listen on the same port as qbit would be listening on "nc -l 53371"
use netcat from another machine to connect to the VPN public addr on that port "nc PUBLICIP 53371" - if it connects, type something in the window, you should see it come over on the listener side. If that works, gluetun/proton are working correctly, the problem is qbit somewhere.

[IBNobody]

So, what I found on my end was that doing a port test via telnet -4 <public VPN assigned IP address> <port forwarded port> would return a telnet: Unable to connect to remote host: Connection refused error.

I was very confused, since my port hadn't changed in a few days and I had been listed as "connected" in the tracker I was using.

It turns out that ProtonVPN had changed the wireguard server I was using from allowing port forwarding to not. I had to change servers.

I regenerated glueTUN with a new wireguard server, and my telnet -4 <public VPN assigned IP address> <port forwarded port> test connected.

@soxfor maybe a feature request to come out of this would be to actively test if the port is indeed open. (This is a feature I miss from Transmission.)