Replies: 13 comments 13 replies
-
|
I have the same problem, the only difference being it has never restored the port after restarting the unhealthy VPN connection for as long as I've been using it (for almost two years now). Every time I have to restart the container along with all the containers that depend on it. More info in the connected issue: #1095 |
Beta Was this translation helpful? Give feedback.
-
|
My bad this got lost over time. I'll have a look at it tomorrow, I'll keep you updated! |
Beta Was this translation helpful? Give feedback.
-
|
I checked the firewall and rules are set correctly for Although I fixed 5aa39be which should had pretty much zero impact anyway, except duplicating accept rules on every internal vpn restart, now it'll remove them properly. Maybe try the latest image see if this makes a difference? You can also check yourself the firewall rules with |
Beta Was this translation helpful? Give feedback.
-
|
Meh it might be more related to PIA-specific code, I don't think it's related to the firewall really. I pushed image |
Beta Was this translation helpful? Give feedback.
-
|
@qdm12 Will do, thanks! Will report back in a week. |
Beta Was this translation helpful? Give feedback.
-
|
Did not take a week for it to happen again... Here's the log excerpt: Please note that there are two lines about removing allowed port – the first one is from my custom rule put in FIREWALL_VPN_INPUT_PORTS (thought that would help...), and the other one is from port forwarding. |
Beta Was this translation helpful? Give feedback.
-
|
Please run it with |
Beta Was this translation helpful? Give feedback.
-
|
Oh my... Note to self: Do not report late at night 😅. I thought it already was in debug, but not on that machine! Apologies, will report back witha a proper log if this happens again. |
Beta Was this translation helpful? Give feedback.
-
|
Heh, it did not take long... Seems like it's not even triggering the port forwarding after the restart. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. I would add to this post that I have tested both AirVPN and Mullvad with gluetun. I am getting the same result as above with both of the VPN-providers. The port forwarding is not restored after restarting of VPN. I am using qmcgaw/gluetun:latest and qBittorrent. I can provide logs if needed. |
Beta Was this translation helpful? Give feedback.
-
|
I've also been running into the same issue, although I've managed to fix it a few times by just restarting qbittorrent. Which makes me think it could be a qBittorrent but unsure. |
Beta Was this translation helpful? Give feedback.
-
|
I've experienced this issue while using Deluge back in July (OP). Recently moved to qBittorrent, but haven't seen this issue since the beginning of August. Makes me – somebody without knowledge on the internal workings – wonder if something like a '(dead)lock' on the listen port could exist, which in turn makes the renewal code hang…? |
Beta Was this translation helpful? Give feedback.
-
|
It has happened again on the latest commit (ea40b84). When restarting the stack, I noticed this final line in the log during shutdown: 2023-01-31T18:13:52+01:00 WARN Shutdown not completed gracefully: ordered shutdown timed out: port forwarding: goroutine shutdown timed out: after 1s; other: group shutdown timed out: 1 out of 4 goroutines: http proxy: goroutine shutdown timed out: after 400ms Seems safe to assume the port forwarding somehow really ends up being stuck and causing the original issue... |
Beta Was this translation helpful? Give feedback.
-
|
By the way I found a fix for my problem over in #1277 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Glad to know there's a solution for qBitTorrent users! Sadly, it doesn't help me since I'm using rtorrent instead. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, but not related to my problem. This issue started happening when I was still using Deluge. Meanwhile, I've been using qbittorrent (the libtorrentv1 variant) for months, and it started happening again two days ago. It's most definitely something that needs a fix in the Gluetun code. It could be a PIA issue, but Gluetun is the one that isn't recovering. |
Beta Was this translation helpful? Give feedback.
-
|
I am still having to completely restart my stack once in a while due to this issue. Even though it was expected, I've noticed that the portforwarded health endpoint returns 0 as well. # curl --fail --silent --show-error http://localhost:8000/v1/openvpn/status
{"status":"running"}
# curl --fail --silent --show-error http://localhost:8000/v1/openvpn/portforwarded
{"port":45032}
# curl -X PUT --fail --silent --show-error http://localhost:8000/v1/openvpn/status -H "Content-Type: application/json" -d '{"status":"stopped"}'
{"outcome":"stopped"}
# curl -X PUT --fail --silent --show-error http://localhost:8000/v1/openvpn/status -H "Content-Type: application/json" -d '{"status":"running"}'
{"outcome":"running"}
# curl --fail --silent --show-error http://localhost:8000/v1/openvpn/portforwarded
{"port":0} |
Beta Was this translation helpful? Give feedback.
-
|
Is there any script available to check the port forwarding status of the gluetun container. I am facing the same issue and trying to find an automated solution to restart and few other dependent containers once the port forwarding begins to fail |
Beta Was this translation helpful? Give feedback.
-
|
I am experiencing this issue too, on latest images of deluge and gluetun with PIA |
Beta Was this translation helpful? Give feedback.
-
|
Same for me using ProtonVPN, created an issue here (#1749) |
Beta Was this translation helpful? Give feedback.
-
|
So yeah this is still a thing unfortunately. It restarts from an unhealthy state and FIREWALL_VPN_INPUT_PORTS and the iptables update using it is never triggered. Everything must be restated manually. This could happen within like half an hour, rendering things that need port forwarding relative useless. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm using PIA. It works fine for multiple weeks, including the recreation of the port forwarding file. But eventually the port forwarding file is removed and not recreated.
Example log; the container is up until today, but the last [port forwarding] log is from the 21st this month (9 days ago):
A recreation of the container always fixes it for a while. Am I the only one with this issue?
Edit: Looking at the logs again, the issue is bigger than the file alone. The firewall also doesn't allow the forwarded port through interface tun0 after removing it (see 2022-07-21T23:57:10+02:00). Changed the title to reflect this new insight.
Beta Was this translation helpful? Give feedback.
All reactions