Bug: ProtonVPN port forwarding looses connection #1882
Comments
|
it seems that the port is not consistent on ProtonVPN when not in use. |
|
Technically speaking, they use the natpmp protocol, and Gluetun requests a port for a 60 seconds lifetime, and then, every 45 seconds it will re-request it for a 60 seconds lifetime. Basically 15 seconds before it expires, it re-requests it to maintain it. Does it behave the same with image |
|
Yeah, this sounds like expected behavior. It's annoying but that's how proton vpn works. You need to automate some other script or program to update the port forward settings. |
|
@akutruff so eventhough gluetun does request correctly on time, and their gateway answers correctly, the port forwarded gets disconnected silently after a few minutes!? I guess I could add something to try to reach |
|
@qdm12 It sounds like you're already doing the right thing. You just need to continually poll them for a port with natpmpc as far as I understand. I don't think you'd need to do any more of a check than that. However, I just checked the container I had setup to test your port forwarding PR and the port is no longer open. : ( I don't see any port forwarding messages in the log after the reconnect. |
|
Are you restarting the port forward process after the VPN restarts? |
|
@qdm12 I just verified that the port is now being reported as 0 when there's a healthcheck fail. The lines with |
|
with the version This is my Plex containers logs when I do a fresh restart: Here is some log when I noticed the connection was not possible anymore: Within gluetun there is no log past the initial start. |
|
@clemone210 Please pull the latest image and run it with
You are talking about internet --> forwarded port through Gluetun --> Plex container correct? If so, did you have any vpn internal restarts (due to unhealthy) maybe? @akutruff as @clemone210 mentioned, what you experience is likely the bug in Gluetun that was fixed only 3 days ago, are you sure you are running the latest image? I also answered on the closed issue. If you are running an image built on or after 2023-09-24 and still experience the problem, let me know! |
|
@qdm12 I pulled the |
|
i pulled the pr-1742 and it is a very old build. it says while starting its over 90 days old. i was answering in the already closed issue. i am not using ProtonVPN but PureVPN with "FIREWALL_VPN_INPUT_PORTS" and have the same issue. after a while i end up in a unhealthy/healthy loop, connection is stable and working but port forwarding is lost. i re-pulled the latest image right now but it is still |
|
@qdm12 when I pull the latest docker image with the tag :latest, I am still 1 commit behind according to the log. |
|
@qdm12 For the
The port forwarding does not happen again, and the control server still returns 0. |
So for example in gluetun the forwarded port is Maybe the DEBUG function will bring some light into the dark. |
|
I am currently experiencing the same issue, have not found a workaround including stopping and starting the VPN via the API. Only thing that fixes it is stopping the container and restarting it. Does seem to be AFTER a healthcheck fails and it restarts the VPN so as long as there is 0 interruption in the connection it does work. |
|
My apologies everyone for:
|
|
d4df872 should finally fix it for good. Let me know if this is fixed please 🙏 Thanks!!!! |
|
so for the gluetun image it seems to be okay. My problem still exists. I am not sure what its causing it. Furthermore the forwarded port within gluetun never matches with the one which is exposed in the Plex container (automatically). |
|
Thank you for your hard work. I can confirm with the latest version the problem sadly still exists, after a while the container isn't responsive any more and only a restart fixes it. |
I don't think gluetun supports UPnP and as such you will have to manually specify the port to forward in Plex with the one gluetun gets from protonVPN. Maybe you can forward 32400 through gluetun for LAN access and hope and pray the WAN port you manually set never changes. See this. I don't think they allow setting the WAN port thru their web API but maybe its undocumented somewhere. Edit: Perhaps it is possible to update the Plex public/wan port through the web api since this python api apparently can do it, but I admit I spent all of 2 minutes looking at it and have not verified. You could then add a cron job that would periodically update the web port with the one gluetun reports, or maybe if gluetun someday supported web hooks we could spin up something to do it on port change? |
|
Make sure that the ip address you are using from proton (which definitely is not dedicated) doesn't already have someone using this port, otherwise server hop to a new one and try again. Even if you yourself connect, port forward, disconnect vpn and try again, that port will still be bound for a considerable amount of time and you will not be able to rebind to it ... as proton's endpoint still has it in use. |
|
For me it was similar. after 4 days (with the current version) port forwarding stopped working. i am using a cron script which checks if port forwarding is still working and if not it restarts the container. so i dont care anymore, but the script was running last night, so port forwarding was actually not working anymore. Before the last update it was at least once a day stopping to work, so it got much better, but not totally solved. |
I'm glad to know it's not just me. Since this seems like a slightly different issue than what is being discussed in this thread (though, very adjacent), I deleted my original comment and opened up issue #1891 |
|
I wanna add a problem to this. |
|
I've more or less the same problem here. I can't figure out how to assign my forwarded port (VPN) to the port of my linked container ? Any idea please ? |
|
@akutruff indeed sorry I completely forgot. You can do docker exec gluetun iptables --append INPUT -i tun0 -p tcp --dport 38229 -j ACCEPT |
|
I found that forwarded port gets defunct after a while. At the not ok state i see dht has 0 hosts, kali linux torrents download and upload, but raspberry pi torrents dont start. Also other magnet links do not start downloading metadata in failing state. to me protonvpn with wireguard and portforwarding is just not working. I have a strong suspicion that the flaw is on their side. I try the openvpn option or get my money back, because it just doesnt work for me. A pitty that mullvad closed their ports (which i used before) |
|
@syss Thanks for clarifying! Let me know how it goes with OpenVPN, and others feel free to chime in with what you find out. I'll keep this issue opened, but won't mark it as urgent/blocker for next release anymore. |
|
The ovpn connection seems to stay intact. Edit: Port forwarding works on ovpn and stays open. But with said quality not useable for me edit2: after a while lots of peers, no upload with ovpn |
|
After tweaking a lot of settings I can now finally say, that the ProtonVPN is working nicely with wireguard. qbittorrent:
VPN settings: I was missing the VPN_PORT_* options before. When it comes to portforwarding and updating the port, each program has its own method. but I use this container here: https://hub.docker.com/r/technosam/qbittorrent-gluetun-port-update so what you could do to forward the exposed port from ProtonVPN is to somehow tell your firewall/router to do a port trigger from protonvpn port to your plex port. |
I feel like this is something gluetun should be able to do automatically when using protonvpn or any other vpn that returns a dynamic port, by forwarding it it to some static port that the user provides as configuration. Basically establish the vpn connection, extract the dynamic port from "${GLUETUN_URL}/v1/openvpn/portforwarded", and then use something like socat to forward to the given static port. |
|
This might be unrelated, but whenever the ProtonVPN using wireguard connection restarts, the forwarded port dies and you need to re-listen that on port, or maybe this is just an issue with deluge. Here's a script I am using to fix the issue using inotifyd, it is also updating the forwarded port if it changes for some reason (it should be straightforward to modify it to work for qbittorrent) : #!/bin/sh
FORWARDED_PORT_FILE=/gluetun/forwarded_port
while [ ! -f "$FORWARDED_PORT_FILE" ] || [ -z "$(cat "$FORWARDED_PORT_FILE")" ]; do
echo "info: waiting for forwarded port file.."
sleep 5
done
{
FORWARDED_PORT=$(cat "$FORWARDED_PORT_FILE")
echo "info: forwarded port is $FORWARDED_PORT"
while ! nc -z 0.0.0.0 8112 &>/dev/null; do
echo "info: waiting for deluge to wake up.."
sleep 5
done
deluge-console -c /config "config -s listen_ports [$FORWARDED_PORT,$FORWARDED_PORT]"
echo "info: watching if the forwarded port has been changed.."
while :; do
while read EVENT FILE; do
if [ "$EVENT" == "x" ]; then
while [ ! -f "$FORWARDED_PORT_FILE" ] || [ -z "$(cat "$FORWARDED_PORT_FILE")" ]; do
echo "info: waiting for forwarded port file to be recreated.."
sleep 5
done
fi
NEW_PORT=$(cat "$FILE")
if [ "$NEW_PORT" -ne "$FORWARDED_PORT" ]; then
echo "info: forwarded port has been changed to $NEW_PORT (was $FORWARDED_PORT)"
FORWARDED_PORT=$NEW_PORT
else
echo "info: forwarded port unchanged (is $FORWARDED_PORT)"
# We need to reset the port since it might be dead and deluge is not aware
deluge-console -c /config "config -s listen_ports [$((FORWARDED_PORT+1)),$((FORWARDED_PORT+1))]"
sleep 1
fi
deluge-console -c /config "config -s listen_ports [$FORWARDED_PORT,$FORWARDED_PORT]"
done < <(inotifyd - "$FORWARDED_PORT_FILE:wx")
done
} & |
@qdm12, I built the Dockerfile from commit [6122911]. Looks like After a little switcheroo, I've got it running, but then fail when trying to create the NAT redirect, is it supposed to be |
|
@alcroito my bad, the automated build failed because of a linter error; @KptCheeseWhiz indeed, what a disastrous commit 😄 I repushed the commit as 4105f74 it should fix both issues you successfully spotted! 😉 |
For me this didn't work in transmission (commit 4105f74, port was marked as closed). I've created docker mod instead for linuxserver container. If someone is interested it can be found here. |
I would assume the issue is created in that when transmission is announcing to trackers, it includes the callback port which is set in the config, not dynamically by the port it is accessing the internet with. As a result, you still need some intermediary code as you noticed such as what you are working on, or the linux container I have (link). The only way to change I would imagine to change this natively within gluetun/your torrent software would be to get NAT-PMP working properly, which to my knowledge is not (at least with qbittorrent). |
Appologies for taking forever to get back to this, but if you're still looking for an answer, here's what I have gluetun:
image: qmcgaw/gluetun:latest
container_name: gluetun
restart: unless-stopped
labels:
#Domain routing
com.centurylinklabs.watchtower.monitor-only: true
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
volumes:
- ${DIR}/config/gluetun:/gluetun
- ${DIR}/tmp/gluetun:/tmp/gluetun
environment:
- VPN_SERVICE_PROVIDER=custom
- VPN_TYPE=wireguard
- VPN_ENDPOINT_IP=[IP]
- VPN_ENDPOINT_PORT=[PORT]
- WIREGUARD_PUBLIC_KEY="[Public Key]"
- WIREGUARD_PRIVATE_KEY="[Private Key]"
- WIREGUARD_ADDRESSES="10.2.0.2/32"
- VPN_PORT_FORWARDING=on
- VPN_PORT_FORWARDING_PROVIDER=protonvpn
networks:
- external-network
- qbittorrent-proxy
qbittorrent:
image: qbittorrentofficial/qbittorrent-nox:latest
container_name: qbittorrent
restart: unless-stopped
labels:
com.centurylinklabs.watchtower.monitor-only: true
volumes:
- ${DIR}/config:/config
- ${DOWNLOADS}:/downloads
- /media/{user}/Media/torrent:/downloads2
network_mode: "service:gluetun"
qmap:
image: snoringdragon/gluetun-qbittorrent-port-manager:latest
container_name: qmap
restart: unless-stopped
labels:
com.centurylinklabs.watchtower.monitor-only: true
volumes:
- ${DIR}/tmp/gluetun:/tmp/gluetun
environment:
QBITTORRENT_SERVER: localhost
QBITTORRENT_PORT: 8080
QBITTORRENT_USER: "[username]"
QBITTORRENT_PASS: "[password]"
PORT_FORWARDED: /tmp/gluetun/forwarded_port
HTTP_S: http
network_mode: "service:gluetun"I have recently also done a bunch of updates for improved compatibility. |
|
So after some investigating, it seems like the problem isn't with Gluetun not port forwarding. But it's with Qbittorent losing the port binding when the tunnel restarts. So a really hacky way to get around this that I have found seems to be to tell it to listen on all addresses, and then switching it back to the tunnel address. This forces it to rebind to the port and it seems to be a fix for the issue. It just netcats the ip and port, and if it's closed then it forces it. I have pasted it below, and will report if I have any issues(it would be easy to integrate this with the other qbittorent-port-manager scripts.) #!/bin/bash
cd /root/docker/arr
while true; do
while [[ ! -f tmp/ip || ! -f tmp/forwarded_port ]]; do
echo "Waiting for gluetun to connect..."
sleep 1
FILE_NO_EXIST=1
done
if [[ $FILE_NO_EXIST -eq 1 ]]; then
FILE_NO_EXIST=0
echo "gluetun connected"
sleep 240
fi
nc -v -z -w 3 $(cat tmp/ip) $(cat tmp/forwarded_port)
if [[ $? -eq 0 ]]; then
sleep 60
else
echo "$(date -u +%Y-%m-%d-%H:%M) Port is closed, forcing qbittorent to relisten" | tee -a tmp/port_checker.log
curl -s -c tmp/qbittorrent-cookies.txt --data "username=$USER&password=$PASSWORD" https://$HOST/api/v2/auth/login >/dev/null
curl -b tmp/qbittorrent-cookies.txt -X POST https://$HOST/api/v2/app/setPreferences --data 'json={"current_interface_address":"10.2.0.2"}'
curl -b tmp/qbittorrent-cookies.txt -X POST https://$HOST/api/v2/app/setPreferences --data 'json={"current_interface_address":"0.0.0.0"}'
sleep 240
fi
done |
|
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: 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 |
|
@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. |
|
fixed on my end. |
|
What was the solution here @clemone210? |
With the latest version, I do not have any error or interruption. |
|
A hopefully helpful note for anyone looking over this issue report in the future:
Using 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. |
@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".
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 ( |
I have two solutions for you:
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 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. |
and others
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)
Share your configuration
The text was updated successfully, but these errors were encountered: