Bug: ProtonVPN port forwarding looses connection

clemone210 commented 11 months ago

Is this urgent?

No

Host OS

Ubuntu

CPU arch

x86_64

VPN service provider

ProtonVPN

What are you using to run the container

docker-compose

What is the version of Gluetun

latest docker image

What's the problem 🤔

I use gluetun to connect plex to protonvpn with OpenVPN + port forwarding.

When starting the container everything works. The container gets a opened port ad uses this to allow remote access.

Somehow after a few minutes (10-15min) the port connection is not possible anymore. Within Plex, no remote access is possible anymore. After restarting gluetun and Plex there will be a new port which is used and it works again.

Anything I can provide in order to resolve this?

Share your logs (at least 10 lines)

========================================
========================================
=============== gluetun ================
========================================
=========== Made with ❤️ by ============
======= https://github.com/qdm12 =======
========================================
========================================

Running version latest built on 2023-09-23T13:31:26.334Z (commit aa6dc78)

🔧 Need help? https://github.com/qdm12/gluetun/discussions/new
🐛 Bug? https://github.com/qdm12/gluetun/issues/new
✨ New feature? https://github.com/qdm12/gluetun/issues/new
☕ Discussion? https://github.com/qdm12/gluetun/discussions/new
💻 Email? quentin.mcgaw@gmail.com
💰 Help me? https://www.paypal.me/qmcgaw https://github.com/sponsors/qdm12
2023-09-25T14:30:39+02:00 INFO [routing] default route found: interface eth0, gateway 172.20.0.1, assigned IP 172.20.0.4 and family v4
2023-09-25T14:30:39+02:00 INFO [routing] local ethernet link found: eth0
2023-09-25T14:30:39+02:00 INFO [routing] local ipnet found: 172.20.0.0/16
2023-09-25T14:30:40+02:00 INFO [storage] creating /gluetun/servers.json with 17689 hardcoded servers
2023-09-25T14:30:40+02:00 INFO Alpine version: 3.18.3
2023-09-25T14:30:40+02:00 INFO OpenVPN 2.5 version: 2.5.8
2023-09-25T14:30:40+02:00 INFO OpenVPN 2.6 version: 2.6.5
2023-09-25T14:30:40+02:00 INFO Unbound version: 1.17.1
2023-09-25T14:30:40+02:00 INFO IPtables version: v1.8.9
2023-09-25T14:30:40+02:00 INFO Settings summary:
├── VPN settings:
|   ├── VPN provider settings:
|   |   ├── Name: protonvpn
|   |   ├── Server selection settings:
|   |   |   ├── VPN type: openvpn
|   |   |   ├── Countries: germany
|   |   |   ├── Cities: frankfurt
|   |   |   └── OpenVPN server selection settings:
|   |   |       └── Protocol: TCP
|   |   └── Automatic port forwarding settings:
|   |       ├── Use port forwarding code for current provider
|   |       └── Forwarded port file path: /tmp/gluetun/forwarded_port
|   └── OpenVPN settings:
|       ├── OpenVPN version: 2.5
|       ├── User: [set]
|       ├── Password: s5...KML
|       ├── Network interface: tun0
|       ├── Run OpenVPN as: root
|       └── Verbosity level: 1
├── DNS settings:
|   ├── Keep existing nameserver(s): no
|   ├── DNS server address to use: 127.0.0.1
|   └── DNS over TLS settings:
|       └── Enabled: no
├── Firewall settings:
|   └── Enabled: no
├── Log settings:
|   └── Log level: INFO
├── Health settings:
|   ├── Server listening address: 127.0.0.1:9999
|   ├── Target address: cloudflare.com:443
|   ├── Duration to wait after success: 5s
|   ├── Read header timeout: 100ms
|   ├── Read timeout: 500ms
|   └── VPN wait durations:
|       ├── Initial duration: 6s
|       └── Additional duration: 5s
├── Shadowsocks server settings:
|   └── Enabled: no
├── HTTP proxy settings:
|   └── Enabled: no
├── Control server settings:
|   ├── Listening address: :8000
|   └── Logging: yes
├── OS Alpine settings:
|   ├── Process UID: 1000
|   ├── Process GID: 1000
|   └── Timezone: europe/berlin
├── Public IP settings:
|   ├── Fetching: every 12h0m0s
|   └── IP file path: /tmp/gluetun/ip
└── Version settings:
    └── Enabled: yes
2023-09-25T14:30:40+02:00 INFO [routing] default route found: interface eth0, gateway 172.20.0.1, assigned IP 172.20.0.4 and family v4
2023-09-25T14:30:40+02:00 INFO [routing] adding route for 0.0.0.0/0
2023-09-25T14:30:40+02:00 INFO [firewall] firewall disabled, only updating allowed subnets internal list
2023-09-25T14:30:40+02:00 INFO [routing] default route found: interface eth0, gateway 172.20.0.1, assigned IP 172.20.0.4 and family v4
2023-09-25T14:30:40+02:00 INFO TUN device is not available: open /dev/net/tun: no such file or directory; creating it...
2023-09-25T14:30:40+02:00 INFO [dns] using plaintext DNS at address 1.1.1.1
2023-09-25T14:30:40+02:00 INFO [http server] http server listening on [::]:8000
2023-09-25T14:30:40+02:00 INFO [healthcheck] listening on 127.0.0.1:9999
2023-09-25T14:30:40+02:00 INFO [firewall] firewall disabled, only updating internal VPN connection
2023-09-25T14:30:40+02:00 INFO [openvpn] OpenVPN 2.5.8 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Nov  2 2022
2023-09-25T14:30:40+02:00 INFO [openvpn] library versions: OpenSSL 3.1.3 19 Sep 2023, LZO 2.10
2023-09-25T14:30:40+02:00 INFO [openvpn] TCP/UDP: Preserving recently used remote address: [AF_INET]194.126.177.14:443
2023-09-25T14:30:40+02:00 INFO [openvpn] Attempting to establish TCP connection with [AF_INET]194.126.177.14:443 [nonblock]
2023-09-25T14:30:40+02:00 INFO [healthcheck] healthy!
2023-09-25T14:30:40+02:00 INFO [openvpn] TCP connection established with [AF_INET]194.126.177.14:443
2023-09-25T14:30:40+02:00 INFO [openvpn] TCP_CLIENT link local: (not bound)
2023-09-25T14:30:40+02:00 INFO [openvpn] TCP_CLIENT link remote: [AF_INET]194.126.177.14:443
2023-09-25T14:30:40+02:00 WARN [openvpn] 'link-mtu' is used inconsistently, local='link-mtu 1635', remote='link-mtu 1636'
2023-09-25T14:30:40+02:00 WARN [openvpn] 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
2023-09-25T14:30:40+02:00 INFO [openvpn] [node-de-17.protonvpn.net] Peer Connection Initiated with [AF_INET]194.126.177.14:443
2023-09-25T14:30:41+02:00 INFO [openvpn] TUN/TAP device tun0 opened
2023-09-25T14:30:41+02:00 INFO [openvpn] /sbin/ip link set dev tun0 up mtu 1500
2023-09-25T14:30:41+02:00 INFO [openvpn] /sbin/ip link set dev tun0 up
2023-09-25T14:30:41+02:00 INFO [openvpn] /sbin/ip addr add dev tun0 10.81.0.7/16
2023-09-25T14:30:41+02:00 INFO [openvpn] UID set to nonrootuser
2023-09-25T14:30:41+02:00 INFO [openvpn] Initialization Sequence Completed
2023-09-25T14:30:41+02:00 INFO [firewall] firewall disabled, only updating allowed ports internal state
2023-09-25T14:30:41+02:00 INFO [vpn] You are running 6 commits behind the most recent latest
2023-09-25T14:30:41+02:00 INFO [port forwarding] starting
2023-09-25T14:30:41+02:00 INFO [port forwarding] gateway external IPv4 address is 194.126.177.84
2023-09-25T14:30:41+02:00 INFO [port forwarding] port forwarded is 36736
2023-09-25T14:30:41+02:00 INFO [firewall] firewall disabled, only updating allowed ports internal state
2023-09-25T14:30:41+02:00 INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port
2023-09-25T14:30:41+02:00 INFO [ip getter] Public IP address is 194.126.177.84 (Germany, Hesse, Frankfurt am Main)

Share your configuration

gluetun:
    image: qmcgaw/gluetun:${GLUETUN_VERSION}
    container_name: gluetun
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - OPENVPN_USER=myuser+pmp
      - OPENVPN_PASSWORD=mypassword
      - FIREWALL_VPN_INPUT_PORTS=32400
      - VPN_PORT_FORWARDING=ON
      - SERVER_COUNTRIES=GERMANY
      - FIREWALL=OFF
      - DOT=OFF
      - OPENVPN_PROTOCOL=TCP
      - SERVER_CITIES=FRANKFURT
      - TZ=${TIMEZONE}
    ports:
      - 32400:32400

jakesmorrison commented 8 months ago

EDIT: I changed "container:vpn" to "service:vpn" and restarted the containers. Instead of resuming all the qbit torrents at once I did them in batches. It has been 5 hours and I have not had a Gluetun crash and my port is still open.

EDIT2: Overnight Gluetun crashed and ports closed

I am also using Proton VPN (wireguard) and Gluetun.

I recently had to restart my gluetun container that had been active for ~2 months (working great). After restarting the container I am now experiencing some port forwarding problems.

I start the gluetun, qbittorrent and qbittorrent-natmap. For the first 10 minutes or so everything works; the port is open. Then gluetun crashes and the port closes after gluetun reconnects. If I manually restart all containers the port is open again.

Crash Code:

2024-01-04T22:39:38Z DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2024-01-04T22:39:38Z DEBUG [port forwarding] port forwarded 43785 maintained
2024-01-04T22:39:53Z INFO [healthcheck] unhealthy: dialing: dial tcp4 104.16.132.229:443: i/o timeout
2024-01-04T22:40:01Z INFO [healthcheck] program has been unhealthy for 6s: restarting VPN (see https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md)
2024-01-04T22:40:01Z INFO [vpn] stopping
2024-01-04T22:40:01Z INFO [port forwarding] stopping
2024-01-04T22:40:01Z INFO [firewall] removing allowed port *******
2024-01-04T22:40:01Z DEBUG [firewall] iptables --delete INPUT -i tun0 -p tcp --dport 43785 -j ACCEPT
2024-01-04T22:40:01Z DEBUG [firewall] ip6tables-nft --delete INPUT -i tun0 -p tcp --dport 43785 -j ACCEPT
2024-01-04T22:40:01Z DEBUG [firewall] iptables --delete INPUT -i tun0 -p udp --dport 43785 -j ACCEPT
2024-01-04T22:40:01Z DEBUG [firewall] ip6tables-nft --delete INPUT -i tun0 -p udp --dport 43785 -j ACCEPT
2024-01-04T22:40:01Z INFO [port forwarding] removing port file /tmp/gluetun/forwarded_port
2024-01-04T22:40:01Z DEBUG [wireguard] closing controller client...
2024-01-04T22:40:01Z DEBUG [wireguard] removing IPv6 rule...
2024-01-04T22:40:01Z DEBUG [wireguard] removing IPv4 rule...
2024-01-04T22:40:01Z DEBUG [wireguard] shutting down link...
2024-01-04T22:40:01Z DEBUG [wireguard] deleting link...
2024-01-04T22:40:01Z INFO [vpn] starting
2024-01-04T22:40:01Z DEBUG [wireguard] Wireguard server public key: *******
2024-01-04T22:40:01Z DEBUG [wireguard] Wireguard client private key: ICu...1c=
2024-01-04T22:40:01Z DEBUG [wireguard] Wireguard pre-shared key: [not set]
2024-01-04T22:40:01Z INFO [firewall] allowing VPN connection...
2024-01-04T22:40:01Z INFO [wireguard] Using available kernelspace implementation
2024-01-04T22:40:01Z INFO [wireguard] Connecting to ****
2024-01-04T22:40:01Z INFO [wireguard] Wireguard setup is complete. Note Wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the Wireguard connection is not working.
2024-01-04T22:40:01Z INFO [port forwarding] starting
2024-01-04T22:40:01Z INFO [healthcheck] healthy!
2024-01-04T22:40:01Z INFO [port forwarding] gateway external IPv4 address is *******
2024-01-04T22:40:02Z INFO [port forwarding] port forwarded is 
2024-01-04T22:40:02Z INFO [firewall] setting allowed input port 43785 through interface tun0...
2024-01-04T22:40:02Z DEBUG [firewall] iptables --append INPUT -i tun0 -p tcp --dport 43785 -j ACCEPT
2024-01-04T22:40:02Z DEBUG [firewall] ip6tables-nft --append INPUT -i tun0 -p tcp --dport 43785 -j ACCEPT
2024-01-04T22:40:02Z DEBUG [firewall] iptables --append INPUT -i tun0 -p udp --dport 43785 -j ACCEPT
2024-01-04T22:40:02Z DEBUG [firewall] ip6tables-nft --append INPUT -i tun0 -p udp --dport 43785 -j ACCEPT
2024-01-04T22:40:02Z INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port
2024-01-04T22:40:02Z INFO [ip getter] Public IP address is *******
2024-01-04T22:40:47Z DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2024-01-04T22:40:47Z DEBUG [port forwarding] port forwarded 43785 maintained

Docker Compose

  vpn:
    container_name: vpn
    image: qmcgaw/gluetun:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /config/gluetun/config:/gluetun
      - /config/gluetun/tmp:/tmp/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=custom
      - VPN_TYPE=wireguard
      - VPN_ENDPOINT_IP=
      - VPN_ENDPOINT_PORT=
      - WIREGUARD_PUBLIC_KEY=
      - WIREGUARD_PRIVATE_KEY=
      - WIREGUARD_ADDRESSES=
      - WIREGUARD_ALLOWED_IPS=
      - FIREWALL_OUTBOUND_SUBNETS=
      - VPN_PORT_FORWARDING=on
      - VPN_PORT_FORWARDING_PROVIDER=protonvpn
      - LOG_LEVEL=debug
    restart: unless-stopped
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=3000
      - PGID=568
      - TZ=US/Boise
      - WEBUI_PORT=10095
    restart: unless-stopped
    network_mode: container:vpn
  qbittorrent-natmap:
    image: ghcr.io/soxfor/qbittorrent-natmap:latest
    container_name: qbittorrent-natmap
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - TZ=America/Boise
      - QBITTORRENT_SERVER=192.168.100.5
      - QBITTORRENT_PORT=10095
      - QBITTORRENT_USER=admin
      - QBITTORRENT_PASS=adminadmin
      - VPN_CT_NAME=vpn
      - VPN_IF_NAME=tun0
      - CHECK_INTERVAL=300
      - NAT_LEASE_LIFETIME=300
    depends_on:
      vpn:
        condition: service_healthy
      qbittorrent:
        condition: service_started
    network_mode: container:vpn

jakesmorrison commented 8 months ago

@Stetsed I have been testing the port using a simple Python script. I wasn't convinced that toggling qbits binding ipaddress would matter because I thought the python script that only uses port and ipaddress of the vpn would be independent from qbit.

Turns out I was wrong. I manually toggled the ip address binding and my port is now open.

clemone210 commented 8 months ago

fixed on my end.

levouh commented 7 months ago

What was the solution here @clemone210?

clemone210 commented 7 months ago

What was the solution here @clemone210?

With the latest version, I do not have any error or interruption.

kainzilla commented 6 months ago

A hopefully helpful note for anyone looking over this issue report in the future:

With the current versions (2024-02-27) of the LinuxServer.io Deluge and qBittorrent containers attached to Gluetun's network,
With Gluetun connecting to ProtonVPN via Wireguard protocol,
When Gluetun needed to restart the VPN,
the Deluge and qBittorrent clients would stop listening on the forwarded port specifically only on the tun0 adapter.

Using nc -zvw10 <ip> <port> to test, you can confirm that even within the torrent client container itself, the torrent client listening port on the tun0 adapter would not respond, even though Gluetun was forwarding and working as usual.

As soon as the configured IP in the torrent client is changed, (whether to the tun0 address or to 0.0.0.0, or to something else and back to it's original setting), the torrent client would start responding on that port; sometimes not for long however. Restarting the torrent client container would resolve the issue 100% until a VPN disconnection occurs.

A final note is that LinuxServer.io's Transmission torrent client container doesn't seem to have this issue; it survives VPN restarts for me and keeps listening without needing restarts. As far as I can tell, Gluetun and Proton VPN appear to be working great, and the port listening issue lies with the torrent clients.

beastlybeast commented 3 months ago

As soon as the configured IP in the torrent client is changed, (whether to the tun0 address or to 0.0.0.0, or to something else and back to it's original setting), the torrent client would start responding on that port; sometimes not for long however. Restarting the torrent client container would resolve the issue 100% until a VPN disconnection occurs.

@kainzilla, thanks for recapping -- is there a fix for the quoted part above? I notice when it loses connection, I too can get it to resume if I restart the containers, or, if I change the network interface in qBittorrent (like from "any" to "tun") and click "save".

CleanShot 2024-06-13 at 13 34 47@2x

The port updating script I use simply updates the port:

https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update

However, I see another that fully restarts the qbittorrent container when the port changes:

https://github.com/royborgen/qbt_port_update

That said, the issue I'm having is not when the port changes. The port from ProtonVPN might not change for many days, but I still have this issue where qBittorrent becomes unconnectable until restarting the container or toggling the network interface in the qBittorrent advanced menu.

It seems like the ideal situation would be something that checked for connectability (nc -zvw10 <ip> <port>) and restarted if it wasn't connectable.

kainzilla commented 3 months ago

It seems like the ideal situation would be something that checked for connectability (nc -zvw10 <ip> <port>) and restarted if it wasn't connectable.

I have two solutions for you:

Solution 1: I actually made a script that was intended for the specific purpose of updating the port and also checking that the port is working - and it will toggle the qBittorrent or Deluge network adapter for you if it detects that the port isn't receiving. It currently doesn't force a restart of the entire torrent container... but someone could probably add this feature in.
Solution 2: In my testing, the Transmission client outright didn't experience this portion of the issue - Gluetun UDP disconnections would still happen, but the client recovered gracefully from them without fail, which was a significant reliability improvement. I actually prefer this over the script. I combined Transmission with the Flood Torrent Client UI running in another container and I like it.

I think the bug in question is in the torrent clients, as opposed to anything Gluetun is doing - and I suspect it might be a libtorrent bug as both qBittorrent and Deluge use it, and they both experience the issue.

Regarding the script above - it's meant to be used with LinuxServer.io's containers (see the page for links), because their containers have a super-easy way to drop in add-on scripts like that. I have a gluetun-delay script that delays the torrent client startups that works with the same LinuxServer.io containers also.

qdm12 / gluetun