Bug: protonvpn openvpn disconnects occasionally #2407
Comments
|
@qdm12 is more or less the only maintainer of this project and works on it in his free time.
|
|
Update: after starting a torrent on the ubuntu vps gluetun also restarts a lot. Torrents also immediately error every time i start them. I got the same error log: |
That error is being worked on right now, subscribe to #2334 (a bit of a long effort, I worked on it for a few days already). That will prevent gluetun from exiting completely and instead restart internally the vpn. By the way, this is a bug in |
|
Ah, Thank you for your work 🙏 |
|
The error you see is likely related to
Which is a problem in my log handling of openvpn. Probably openvpn crashes with some huge text and the Go code doesn't handle it. Let me fix it and you can run the fixed version to see why OpenVPN fails. |
qdm12
changed the title
|
Can you try image The error I've increased the limit to 20MB (extended only if needed, defaults to 64KB still to limit memoy usage), so hopefully that should be enough to log out whatever big log openvpn wants to send out. I'm guessing it's a core dump? 🤔 |
qdm12
added
Category: OpenVPN 🔐
Status: 🗯️ Waiting for feedback
Status: 🔴 Blocked
|
it died again with this error: |
What error do you get above the logs you shared? Still |
qdm12
added
Status: 🟡 Nearly resolved
|
doesnt seem like its the token too long error anymore |
|
🤷 Keep on running it to see if it happens again?
|
|
okay so it ran fine for 28 minutes until the vpn restarted again, but this time openvpn logged the WRWRWRWR stuff again (i truncated it, but it is 23 million letters of just that) |
|
it did the same thing again 13 minutes later (including the openvpn wrwrwwrrrwrwrwrwrw) EDIT: the rwRW indicate read writes from tcp/udp to tun/tap (according to this stackoverflow post) |
|
Yes but why does openvpn log this whole blob of debug information to the error stream stderr 🤔 there must be something very odd going on your host network or ISP I guess? Try increasing OPENVPN_VERBOSITY (for example to |
|
oh, i have openvpn verbosity set to 5 in my docker compose |
Indeed, my bad for not rechecking the docker-compose.yml. |
|
it still restarts constantly but there arent any recursive routing detected logs i removed the verbosity statement from the compose file, this is the log now: |
qdm12
changed the title
qdm12
removed
Status: 🟡 Nearly resolved
|
I am also seeing this.. In the previous version, with custom wireguard provider, everything is stable. gluetun-anime:
<<: *common-keys-share
image: qmcgaw/gluetun:latest
container_name: gluetun-anime
networks:
t2_proxy:
ipv4_address: 192.168.90.105
privileged: true
devices:
- /dev/net/tun:/dev/net/tun
ports:
- ${QBITTORRENT_PORT}:8185
volumes:
- ${DOCKERDIR}/appdata/gluetun:/gluetun
environment:
<<: *default-tz-puid-pgid
## PROTONVPN
VPN_PORT_FORWARDING: "on"
VPN_SERVICE_PROVIDER: protonvpn
VPN_TYPE: wireguard
VPN_PORT_FORWARDING_PROVIDER: protonvpn
WIREGUARD_PRIVATE_KEY: ${PROTON_PRIV_KEY}
# SERVER_COUNTRIES: ${PROTON_GLUETUN_SERVER_COUNTRIES}
SERVER_HOSTNAMES: node-nl-207.protonvpn.net
PORT_FORWARD_ONLY: "on"
FIREWALL_OUTBOUND_SUBNETS: 192.168.0.0/16
HEALTH_VPN_DURATION_ADDITION: "10s"
VPN_PORT_FORWARDING_STATUS_FILE: /gluetun/forwarded_port
DOT: "off"
LOG_LEVEL: info
UPDATER_PERIOD: 24h
|
|
This is somewhat related but I've always had this issue with ProtonVPN -- PIA seems to not have this issue. It has gotten really bad lately, though. As in, constant disconnects. I'm starting to think the issue is the # of connections generated through P2P and either Gluetun or Proton having an issue with it. When I'm seeding a ton of Linux ISOs, I'll end up getting hundreds, if not thousands, of connections and then I'll notice DoT issues and the container restarting. It seems to happen within minutes lately but I still have my PIA membership so I tried to use gluetun with PIA and noticed it was a lot slower and I had way less connections. I've adjusted my connection limits down to test and so far it seems to be OK. I'm pretty early on in testing/trying to track down the issue but it could be resources or it could be Proton itself. |
|
I had this issue until I used My working config: ---
services:
gluetun:
image: qmcgaw/gluetun
container_name: gluetun
hostname: gluetun
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
ports:
- 6881:6881
- 6881:6881/udp
- 8085:8085 # qbittorrent
- 8888:8888/tcp # HTTP proxy
- 8388:8388/tcp # Shadowsocks
- 8388:8388/udp # Shadowsocks
volumes:
- /homelab/arr-stack/gluetun:/gluetun
environment:
- TZ=Europe/London
- VPN_SERVICE_PROVIDER=protonvpn
- VPN_TYPE=wireguard
- SERVER_COUNTRIES=France
- WIREGUARD_PRIVATE_KEY=REDACTED
- FREE_ONLY=off
- UPDATER_PERIOD=24h
- HTTPPROXY=on
- DOT=off
- HEALTH_TARGET_ADDRESS=google.es:443
- HEALTH_VPN_DURATION_INITIAL=15s
- HEALTH_SUCCESS_WAIT_DURATION=15s
qbittorrent:
image: lscr.io/linuxserver/qbittorrent
container_name: qbittorrent
network_mode: "service:gluetun"
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/London
- WEBUI_PORT=8085
- QBITTORRENT_PASS=adminadmin
volumes:
- /homelab/arr-stack/qbittorrent:/config
- /homelab/arr-stack/qbittorrent/downloads:/downloads
depends_on:
- gluetun
restart: always
qbittorrent-natmap:
# https://github.com/soxfor/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=Europe/London
- QBITTORRENT_SERVER=172.25.0.2 #qbittorrent IP or 172.20.0.1
- QBITTORRENT_PORT=8085
- QBITTORRENT_USER=admin
- QBITTORRENT_PASS=adminadmin
network_mode: service:gluetun
depends_on:
qbittorrent:
condition: service_started
gluetun:
condition: service_healthy |
I had a series of support tickets with them since June. They've changed something in their infrastructure and it now severely limits the number of simultaneous connections you can make, which makes it unusable for any Torrenting now. If you're using Wireguard and hit this undocumented limit (unknown exactly what it is, support just said there "might" be a limit and gave no further details) it will blacklist your Wireguard key-pair so it no longer works. You'll have to generate a new key-pair by creating a new Wireguard config on your account from scratch. This behavior was verified with Support that even using the key-pair exclusively on an entirely separate device will allow nothing thru, and they just shrugged and wouldn't even open a ticket to have it fixed by the Proton developers. With gluetun, the OpenVPN connection is automaticaly queried and generated, and there is not singular key-pair for the ProtonVPN infrastructure to blacklist. Gluetun will instead detect repeated failed health checks from where ProtonVPN cut you off, and will initiate a new connection. ProtonVPN sees this as a brand new connection and will allow it thru, until you hit the secret limit again and they cut off the connection again. With Support (Visionary member here, so I should be getting their best-ever support) they had me decrease the connections until the Torrenting was completely unusable, then said that was the solution. TL;DR |
|
@mtalexan Thank you for sharing your experience! While I had these same disconnects occasionally, I never had to generate a new key-pair. To get qBittorrent to say "Connected" instead of "Firewalled" because of the ports, I have to switch ports to a random one and back to the one configured previously. But it seems this will be impacting me and everyone else in the near future, if not already, so I will definitely be looking for a different VPN again. |
|
Thanks @mtalexan for the detailed explanation, this is exactly what i'm experiencing. I'm using autoheal to restart gluetun (and child containers) automatically whenever this occurs, and it's working well, but very inconsistent. I can go days without a crash sometimes, and other times i'll restart 3 times within 30 minutes. I'd be curious to know a couple other details if you don't mind:
|
Is this urgent?
None
Host OS
Windows 10 22H2
CPU arch
x86_64
VPN service provider
ProtonVPN
What are you using to run the container
docker-compose
What is the version of Gluetun
Running version latest built on 2024-08-09T09:37:47.759Z (commit 01aaf2c)
What's the problem 🤔
Every time I start the gluetun container it runs fine for like 2-10 minutes and then it logs
[healthcheck] program has been unhealthy for 6s: restarting VPNand restarts the gluetun container. This is annoying because qbittorrent doesnt reconnect to gluetun after the restart so I have to restart the qbittorrent container manually every time. I tried all the fixes mentioned in the healthcheck.md file but nothing worked.I'm running the exact same config (only host volume path different) on an ubuntu vps to test and its been running fine for over an hour now.
I stopped the container manually at 2024-08-10 21:47:34 and then openvpn logged some internal screaming.
Share your logs (at least 10 lines)
Share your configuration
The text was updated successfully, but these errors were encountered: