Restart OpenVPN within the Container

[ygjkggyk]

Hello,

I have an issue with ProXPN where the VPN connectivity works for a while (number of days), then randomly loses internet connectivity. The VPN is showing as connected, however there is no internet connectivity. Restarting the container fixes the issue.

As this issue happens at a random time, I'd like to create a bashscript in a cronjob to check that the container has external internet connectivity, and if it doesn't to restart openvpn.

I've been playing around in the container, and can't get to grips with how the openvpn connection is handled, it doesn't seem to be running as a service... How can you restart the openvpn connection with the same settings as when you created the container, within the container itself?

Thanks,

[lethalwallabies]

I have this same issue with Mullvad also.

My logs show RESOLVE: Cannot resolve host address: nl.mullvad.net:1197 (Temporary failure in name resolution)

Is yours the same(ish) in the logs?

[martadams89]

@lethalwallabies I use Mullvad too and get the same... nice to know I'm not the only one.

I've set a cron job to restart my container every 4 hours because RESOLVE: Cannot resolve host address: nl.mullvad.net:1197 (Temporary failure in name resolution) just spams my logs.

If I have UFW on it will also cause my system to hang after some time :(

[lethalwallabies]

@Extcee, I also have a scheduled restart every night but I don't have any issues with UFW.

Do you have port forwarding enabled with Mullvad? I seem to have a lot of trouble seeding back to private trackers after I switched to Mullvad.

[martadams89]

Yeah I’ve set up port forwarding.

I believe the Mullvad doc’s state that the most recent connection takes the port forward.. so if you open your container, and then fire it up on a second device the second device inherits the port forward.

On 27 May 2020, at 16:49, lethalwallabies notifications@github.com wrote:

@Extcee https://github.com/Extcee, I also have a scheduled restart every night but I don't have any issues with UFW.

Do you have port forwarding enabled with Mullvad? I seem to have a lot of trouble seeding back to private trackers after I switched to Mullvad.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/1189#issuecomment-634754300, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABP4IMWQL3C2JF565NV2B2DRTUZA7ANCNFSM4NAYKMWA.

[lethalwallabies]

Yea I saw that, but that is only if they are connected to the same server. But I will have to check they don't overlap.

The port is open on Transmission and technically works but only with max 50 Kb/s.

[martadams89]

Have you limited your bandwidth within Transmission?

There’s a tick box for max download/upload speed - I thought it was dictated by an environment variable but I can only find the alt variables in my docker-compose file.

BTW, second time I’ve had to hard-reboot my server today because the health-check caused my server to hang.

My syslog file is full of:

May 27 16:51:25 xxx dockerd[769]: time="2020-05-27T16:51:25.579287865+01:00" level=error msg="stream copy error: reading from a closed fifo" May 27 16:51:25 xxx dockerd[769]: time="2020-05-27T16:51:25.611468599+01:00" level=error msg="stream copy error: reading from a closed fifo" May 27 16:51:25 xxx dockerd[769]: time="2020-05-27T16:51:25.662497041+01:00" level=warning msg="Health check for container 89ab669d0a7a679118889b0915d7848ab0820bc41ee79a41a70ad05f1e84adbe error: context deadline exceeded: unknown" May 27 16:51:48 xxx dockerd[769]: time="2020-05-27T16:51:48.727973175+01:00" level=warning msg="Health check for container 89ab669d0a7a679118889b0915d7848ab0820bc41ee79a41a70ad05f1e84adbe error: context deadline exceeded" May 27 16:51:56 xxx dockerd[769]: time="2020-05-27T16:51:56.754641630+01:00" level=warning msg="Health check for container 89ab669d0a7a679118889b0915d7848ab0820bc41ee79a41a70ad05f1e84adbe error: context deadline exceeded" May 27 16:52:05 xxx dockerd[769]: time="2020-05-27T16:52:05.725641747+01:00" level=warning msg="Health check for container 89ab669d0a7a679118889b0915d7848ab0820bc41ee79a41a70ad05f1e84adbe error: context deadline exceeded" May 27 16:52:26 xxx dockerd[769]: time="2020-05-27T16:52:14.589553465+01:00" level=warning msg="Health check for container 89ab669d0a7a679118889b0915d7848ab0820bc41ee79a41a70ad05f1e84adbe error: context deadline exceeded: unknown”

On 27 May 2020, at 16:55, lethalwallabies notifications@github.com wrote:

Yea I saw that, but that is only if they are connected to the same server. But I will have to check they don't overlap.

The port is open on Transmission and technically works but only with max 50 Kb/s.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/1189#issuecomment-634759012, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABP4IMU6HRGP5IQLDQ7TTQTRTUZYPANCNFSM4NAYKMWA.

[lethalwallabies]

@Extcee I haven't had any hanging issues - but I do get this warning in docker

haugene/transmission-openvpn:latest "dumb-init /etc/open…" 6 months ago Up 17 hours (unhealthy) 0.0.0.0:8888->8888/tcp, 0.0.0.0:9091->9091/tcp

There seems to be a few underlying issues but I would guess they could easily fall back to the issue of constantly trying to reconnect to the VPN? Putting unnecessary strain on the container?

Have you limited your bandwidth within Transmission?

I haven't got any issues here with public trackers it seems specific to my public trackers.

[incubug]

I'm experiencing the same DNS resolve issue (Mullvad). I've been having stability issues with my ISP recently (will go down for 5 minutes randomly, but I have to manually release & renew the DHCP lease on my router, or reboot it, for the WAN to become available again). Obviously this causes the transmission-openvpn service to fail the health check, but it never recovers. To fix it I just restart the container. The logs get spammed with:

RESOLVE: Cannot resolve host address: nl.mullvad.net:1197 (Temporary failure in name resolution)

I am passing 8.8.8.8 and 8.8.4.4 as the DNS options in my compose file, along with VPN_OPTIONS=--inactive 36000 --ping 10 --ping-exit 60

[jamesmeneghello]

Same issue happens with me (ExpressVPN), so I'm using https://github.com/willfarrell/docker-autoheal to automatically restart the container when it becomes unhealthy. Seems to have worked around it).

[pkishino]

there is a healthcheck script that currently pings whatever host you specify in the healthcheck (default google I believe) which will mark the container as unhealthy after x amount of tries. As @jamesmeneghello mentioned, restart on unhealthy is the best way for this. I do not agree with having the container try to fix itself, if there is a problem, mark itself unhealthy and then let the user decide what to do. will add a PR to this soon

[martadams89]

I've found that if I don't add the # - OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60 variable, and disable UFW, my container seems to tick along nicely.

I think it's still self-restarting the VPN every hour or so, but it hasn't crashed the container, gone unhealthy or spammed my system.

It's only been a day or so, so this may change - but at the moment it seems to be running well....