Bug: Torguard port forwarding not working

[SnippetSpace]

Is this urgent?

Yes

Host OS

Linux (truenas scale)

CPU arch

x86_64

VPN service provider

TorGuard

What are you using to run the container

Kubernetes

What is the version of Gluetun

3.35

What's the problem 🤔

I've been trying to get torguard to work with gluetun for the last 6 hours, after having tried this 2 months ago and abandoning. It simply doe snot work.

1. Setting up torguard with VPN_SERVICE_PROVIDER=torguard and OPENVPN does not work. It keeps looping an error (see logs below).

2. Setting up torguard with a custom wireguard configuration. This connects, but the port forwarding is broken. According to support it is a docker limitation: Torguard + Wireguard port forwarding #1282 but it works for other providers?

3. setting up torguard with a custom openvpn provider. VPN is healthy, connects, port gets forwarded with FIREWALL_VPN_INPUT_PORTS but checking the ports online there is no open port. I've checked this with a public and dedicated IP.

With truenas scale's truechart apps only supporting gluetun and having no good vpn alternatives I'm stranded with a broken VPN implementation. Is there any way torguard support can be improved? Is ther any way I can fix port forwarding for a custom openvpn or wireguard implementation?

Share your logs

log for scenario 1:

INFO [vpn] starting
INFO [firewall] allowing VPN connection...
INFO [openvpn] OpenVPN 2.5.8 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov  2 2022
INFO [openvpn] library versions: OpenSSL 3.1.1 30 May 2023, LZO 2.10
INFO [openvpn] TCP/UDP: Preserving recently used remote address: [AF_INET]206.217.216.9:1912
INFO [openvpn] UDP link local: (not bound)
INFO [openvpn] UDP link remote: [AF_INET]206.217.216.9:1912
INFO [healthcheck] program has been unhealthy for 21s: restarting VPN (see https://github.com/qdm12/gluetun/wiki/Healthcheck)
INFO [vpn] stopping

Share your configuration

using truecharts on truenas scale GUI:

scenario 1

VPN_SERVICE_PROVIDER: torguard
OPENVPN_USER: xxx
OPENVPN_PASSWORD: xxx
SERVER_COUNTRIES: netherlands
FIREWALL_VPN_INPUT_PORTS: 60000
FIREWALL_OUTBOUND_SUBNETS: 192.168.x.x/24

scenario 2:

VPN_SERVICE_PROVIDER: custom
VPN_TYPE: wireguard
VPN_ENDPOINT_IP: 75.x.x.x.x
VPN_ENDPOINT_PORT: 1337
WIREGUARD_PUBLIC_KEY: xxxxxxx
WIREGUARD_PRIVATE_KEY: xxxxxxxx
WIREGUARD_ADDRESSES: 10.x.x.x/24
SERVER_COUNTRIES: netherlands
FIREWALL_VPN_INPUT_PORTS: 60000
FIREWALL_OUTBOUND_SUBNETS: 192.168.x.x/24

scenario 3:

OPENVPN_CUSTOM_CONFIG: /gluetun/vpn.conf
VPN_SERVICE_PROVIDER: custom
OPENVPN_USER: xxx
OPENVPN_PASSWORD: xxx
FIREWALL_VPN_INPUT_PORTS: 60000
FIREWALL_OUTBOUND_SUBNETS: 192.168.x.x/24

vpn.config extract from torguard

[qdm12]

• scenario 1: servers data might be outdated, try updating them, see https://github.com/qdm12/gluetun/wiki/Healthcheck and https://github.com/qdm12/gluetun-wiki/blob/main/setup/servers.md#update-the-vpn-servers-list
• scenario 2: see Torguard + Wireguard port forwarding #1282 (reply in thread) correct me if I'm wrong!
• scenario 3: maybe it doesn't work on the vpn server. Have you tried on another machine outside docker?

[SnippetSpace]

for 2/3: I now have tested both hotio’s and binhex’ containers that include WireGuard and both work out of the box with TorGuard (even if not officially supported) with port forwarding.

have not tried updating the server list. I don’t want to spend more time on testing this tbh after spending nearly a full day trying to get it to work. You should probably remove TorGuard from the supported list if port forwarding is required.

[nghialm269]

I've been testing gluetun + torguard (wireguard) + qbittorrent (lscr.io/linuxserver/qbittorrent) for a day. Here are my findings:

• The gluetun container could connect to the internet, the [ip getter] shows the correct ip of the VPN server I'm connecting to.
• The qbittorrent container could not connect to internet at all (thus port forwarding doesn't work), I tried to download some Linux ISOs torrents and torguard torrent ip checker but none of them are able to download.
  • I've already added network_mode: "service:gluetun" in the qbittorrent container.
• I tried to use wireguard and qbittorrent without docker, qbittorrent was able to download the torrents, and port forwarding also worked (I was using yougetsignal.com to test).
• I tried to use binhex qbittorrentvpn image, and wireguard and qbittorrent and port forwarding all worked there.
• Then I tried to add privileged: true to the gluetun container (as required in binhex image), and everything worked fine (including port forwarding).
• But I don't want the container to have that privilege, so I continued to test. What finally worked for me was to configure qbittorrent to use the network interface tun0. (Tools -> Options... -> Advanced -> Network Interface: -> choose tun0).
• After that, qbittorrent was able to connect to the internet.
• I tried to download a Linux ISO torrent, and I saw some of the peers had I flag, so I believe port forwarding is working, and yougetsignal.com also reports that the port is opened.

I've tested this on my archlinux laptop (intel x64) and raspberrypi 4B (armbian - arm64).

I'm not sure why I need to explicitly choose the tun0 interface (by default it is Any interface), maybe it's a glitch in qbittorrent or gluetun. Hope this helps.

[SnippetSpace]

@nghialm269 i got to the same place. It seems to work for a few hours, maybe a day and then TorGuard starts rejecting the port forwarding. Can you leave it running for a few days and check the qbitorrent health indicator at the bottom?

[nghialm269]

@nghialm269 i got to the same place. It sends to work for a few hours, maybe a day and then TorGuard starts rejecting the port forwarding. Can you leave it running for a few days and check the qbitorrent health indicator at the bottom?

I see. I'm planning to setup sonarr and jellyfin on the Pi next, after that I'll leave the Pi running. I will add a comment here later.

[nghialm269]

@SnippetSpace

I've left gluetun and qBittorrent running for more than 3 days now, I've noticed a few things:

• If qBittorrent finishes starting up before gluetun can establish VPN connection, the port isn't open. I got this issue after I enabled DOT, which made gluetun a lot slower to start establishing VPN connection. But after I added vuetorrent theme to qBittorrent, which caused it to start up slower than gluetun, I've never had this issue since.

• While qBittorrent is running with working port forwarding, if gluetun restarts the VPN connection due to being unhealthy for more than 6 seconds, port forwarding stops working.

In both cases, it seems that qBittorrent doesn't automatically try to listen to the port again, that's why the port forwarding stops working. When I change the port in qBittorrent to a random one and then change back to the previous port, the port is open again.

At the same time, I also had a different gluetun instance running, but using caddy file-server to listen to the port instead of qBittorrent. There are some logs of gluetun restarting the VPN due to being unhealthy, but whenever I checked the port using yougetsignal or nmap (nmap <IP> -p <port>), they always reported that the port is open, and I also can access the caddy file server using browser.

I think the reason is that when gluetun restarts the VPN connection, it destroys the tun0 interface which qBittorrent binds to while caddy binds to all interfaces. Or maybe caddy has some built-in retry mechanism but qBittorrent doesn't.

I'm thinking of writing a small script to check if the port is still open, and if not use qBittorrent API to change the listening port to a different one and change it back (and let it run every hour or so) to work around this issue. Or maybe increasing gluetun's health check interval - 6s is a little too aggressive IMO.

So, I believe that Torguard port forwarding is working fine with gluetun. The issue is likely due to the interaction between gluetun and qBittorrent.

[SnippetSpace]

Thanks for your investigation. If this is the case it should be "broken" for all wireguard implementations. It might be more visible for torguard due to it somehow triggering more health issues.

[nghialm269]

@SnippetSpace I just searched through the issues in this repo, and it seems that other implementations also suffer from this, not just Torguard: #1407

Someone even made a container similar to the workaround I mentioned: #1407 (comment). I guess I can just use it instead of writing one myself.

[SnippetSpace]

This is really cool! I moved on to another image that includes WireGuard and just works. Will switch back to gluetun when I need to make some config changes and try out that bonus container. Not very elegant though. Might be worth integrating into gluetun even though the sentiment on the thread is the opposite.

[nghialm269]

This is really cool! I moved on to another image that includes WireGuard and just works. Will switch back to gluetun when I need to make some config changes and try out that bonus container. Not very elegant though. Might be worth integrating into gluetun even though the sentiment on the thread is the opposite.

I think it's because other images don't have health check like gluetun. If you set HEALTH_VPN_DURATION_INITIAL (and maybe also HEALTH_SUCCESS_WAIT_DURATION) to a really high value, I think it will behave the same as other images.

[qdm12]

I got this issue after I enabled DOT, which made gluetun a lot slower to start establishing VPN connection.

Actually the VPN connection is setup at the same speed whether DOT is on or off, BUT port forwarding will trigger later, after DNS over TLS setup completes (this will be much faster once #1742 gets merged).

I believe I read somewhere someone managed to configure qbitorrent to start once gluetun is healthy, and this solves it 😉 ? Worth a try maybe?

if gluetun restarts the VPN connection due to being unhealthy for more than 6 seconds, port forwarding stops working.

Total bug in Gluetun, this is being resolved in #1874 soon.

I think the reason is that when gluetun restarts the VPN connection, it destroys the tun0 interface which qBittorrent binds to while caddy binds to all interfaces.

Interesting!!! 💯 I don't think it's possible to reboot the VPN without tearing down the tun device sadly.
On a similar experience, the gluetun internal http client would fail after a vpn internal restart because it would keep a pool of opened connections, and these would no longer work. The solution was to close that pool when the VPN restarts. I guess it's a similar story for qbitorrent. Maybe one day I can implement some form of API call to reset the port forwarding in the qbittorrent container; but right now the priority is to refactor/make more stable the 'run loops' (like the port forwarding or vpn run loops) before adding more features.

Or maybe increasing gluetun's health check interval - 6s is a little too aggressive IMO.

yes and no, 6s means reaching cloudflare.com failed consecutively 6 times very second (see the FAQ healthcheck wiki page). It usually won't recover even with longer periods.

[nghialm269]

yes and no, 6s means reaching cloudflare.com failed consecutively 6 times very second (see the FAQ healthcheck wiki page). It usually won't recover even with longer periods.

Increasing HEALTH_VPN_DURATION_INITIAL (I'm setting it to 120s) works for me at least. Been leaving it like that for two weeks and the port forwarding is still working. The only time port forwarding stopped working was when I restarted my router and it seemed to take more than 120s.

[JermellB]

My comment is probably a little relevant here.

I am using Traefik, FastAPI, gluetun, docker-compose

I experienced a lot of similar issues to this comment thread.

My solution was implementing a healthcheck that simply tries to call out to the internet on the child container (a fastAPI app in my instance), when it becomes unhealthy I have another container called autoheal that will restart my child container and it rejoins the vpn network. Hackish, but works.

I run four instances of this API, and four instances of GlueTun, each on their own connections and it seems to do fine.

I am still working on getting torguard to work which is why I am here. I successfully tested with a few other providers though no big deal.

I should investigate the HEALTH_VPN_DURING_INITIAL flag as @nghialm269 has suggested. My child container doesn't normally start before my vpn container but sometimes if I lose the connection this approach is useful.

[reedjosh]

For anyone else coming here, I currently have no troubles with Torguard and Wireguard port forwarding.

I occasionally see the following message, but it seems harmless enough, and only last for fractions of a second at a time.

g any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-02-05T20:01:47Z INFO [firewall] setting allowed input port 51517 through interface tun0...
2024-02-05T20:01:49Z INFO [healthcheck] healthy!
2024-02-05T20:17:52Z INFO [healthcheck] unhealthy: dialing: dial tcp4: lookup cloudflare.com: i/o timeout
2024-02-05T20:17:53Z INFO [healthcheck] healthy!

I'm also deploying in k8s.

Here's the basics of my conf.

kind: Deployment
...
...
      containers:
      - env:
        - name: DNS_KEEP_NAMESERVER
          value: "on"
        - name: FIREWALL_OUTBOUND_SUBNETS
          value: 10.0.0.0/8
        - name: DNS_PLAINTEXT_ADDRESS
          value: 10.< redacted >.10
        - name: VPN_TYPE
          value: wireguard
        - name: WIREGUARD_PUBLIC_KEY
          value: < redacted >
        - name: WIREGUARD_PRIVATE_KEY
          value: < redacted >
        - name: WIREGUARD_ADDRESSES
          value: 10.< redacted >/24
        - name: VPN_ENDPOINT_IP
          value: 107.181.< redacted >
        - name: VPN_ENDPOINT_PORT
          value: "1443"
        - name: VPN_SERVICE_PROVIDER
          value: custom
        - name: FIREWALL_VPN_INPUT_PORTS
          value: "51517"
        image: ghcr.io/qdm12/gluetun
        imagePullPolicy: Always
        name: gluetun
        securityContext:
          capabilities:
            add:
            - NET_ADMIN

[reedjosh]

One issue I ran into is that FIREWALL_VPN_INPUT_PORTS != FIREWALL_INPUT_PORTS. Otherwise, just the Torguard UI is rather fiddly too, so double triple check that setup too.

[qdm12]

For the healthcheck discussion/issue/debate, please subscribe to #2154

Can we consider this issue resolved then? 🤔 Nothing much I can do anyway as far as I understood.

[SnippetSpace]

I’ve tried redeploying last week and it seems to work over WireGuard without dropping the connection. So for me the core issue (being completely broken) is resolved.