VPN reconnect when connection closes

[haugene]

@makloda asked this question in issue #49.

Hi Haugene. I am using pureVPN and it works great ,however, sometimes my VPN provider loses connection so that causes transmission to stop all transfers (as it should). Currently I use a cron on the Synology host to simply restart the docker container every 4 hours which then restarts the whole image and connecst to VPN again. But it feels like killing an ant with a sledgehammer. Is there a way to schedule automatic reconnection to the VPN inside the container in case the VPN connection is dropped?

Moving it here as it is unrelated to the other issue.

[haugene]

Ok, so... The container starts openvpn and as long as the openvpn-process is running the container is quite happy. I don't want to implement a lot of functionality trying to check the openvpn connection for special cases. This should be handled by openvpn.

Suggestion:
You can try the --ping-exit n option in openvpn. You can read about it in the openpn documentation. It exits openvpn if there is no traffic or reply to pings. You can set this by passing for example -e "OPENVPN_OPTS=--inactive 3600 --ping 10 --ping-exit 60".

As it states in the the docs:

...will cause OpenVPN to exit within 60 seconds if its peer disconnects, but will exit after one hour if no actual tunnel data is exchanged

If you use this along with the --restart=always option for the docker run command, a peer disconnect should trigger openvpn to exit and the container dies and gets restarted. Or at least, that's how it should go ;)

One question though... You say that transmission stops all transfers when you have a vpn disconnect. Are they actually stopped? Or does Transmission die? I.e; can you still access the WebUI? Could you paste some logs of what happens during a disconnect?

PS: They also have a --ping-restart option, but I'm not sure if this lets you skip the --restart=always on the container. If openvpn stops, the container stops. So it depends on how openvpn behaves. Try it first if you'd like, could be interesting to know if the --restart=always could be dropped.

[davidszp]

Hi, thanks for your response!

1. If I recall correctly the container remained accessible (I could connect to the transmission web GUI) but transfers stopped. I might be wrong, but that's my best recollection.
2. I have followed your instructions above and pulled the newest updates with git, rebuilt the new container to be able to use the "OPENVPN_OPTS" environment variable. I have removed my crontab entry to auto restart the container every four hours. I will post back with the results after a day or so of operation.
3. I will also try the ping-restart option, thanks I wasn't aware of this.

I will report back with my findings. Thank you so much!

[davidszp]

Ad 2.): The container has restarted itself twice now in 48 hours so I believe the ping/exist test is working fine via OPENVPN_OPTS. So far so good! This appears more elegant than my previous cronned stop/restart mechanism.

I will try 3.) next.

[haugene]

Good stuff 👍

[davidszp]

Ok, so I tried the --ping-restart option and it doesn't work as hoped. Right now, in my 2 day old container it appears the VPN connection dropped, so openvpn would need to be restarted.

I can attach a bash shell to the container and

• iftun shows a working device (tun0-00)
• ps -ax shows the running openvpn process: --ping-restart
• pinging 127.0.0.1 works fine
• pinging any outside IP such as 8.8.8.8 does not work, times out

This appears to be a bug in openvpn!? I can't ping outside IPs, but it does not seem to restart the openvpn connection.

[haugene]

Maybe. Openvpn has a lot of users, something tells me they would have caught it.
I'm leaning towards this being something to do with how the openvpn process is managed in the container. But I don't know. Could be fun to discover, but... For now I suggest we stick to the --ping-exit flag as the solution ;)

Thanks for exploring! I'll put something in the readme about the ping-exit option.

[davidszp]

Hmmm last night the container DID reset with ping-restart, so this time it worked as expected. I don't understand this. It appears sometimes it seems to get stuck, then next time it works fine with the exact same parameters. Do you know where I can find the Openvpn logs inside the container?

[haugene]

Don't know where they go by default. But looks like you can set a --log option and specify it.

[davidszp]

Ok I think I found the issue. The OpenVPN definition file for my provider (PureVPN) used a host name such as "at1.pointtoserver.com" to reach the VPN server. Now when the connection died I found a DNS error in the logs "Unable to resolve at1.pointtoserver.com".

So a week ago I changed "at1.pointtoserver.com" in the OpenVPN definition file to the corresponding numeric IP address. Since then the container restarted itself twice without hickups so far and always stayed responsive.

So Im crossing my fingers that this was the problem: OpenVPN couldn't reach the DNS service to resolve the hostname to use the --ping command. With a numeric IP it appears to be able to attempt to reach the IP, and in case it can't ping it, it will restart the container.

Maybe you want to include this in a FAQ, maybe this will be helpful to some people.

[haugene]

Aha, so the container loses dns and then it doesn't matter if the "--ping-restart" restarts the openvpn process because the container can't resolve the hostname anyways. But if you have "--ping-exit" the container will stop when the dns issues occur and then the container will be started again, probably refreshing or fixing dns setting.

I guess I'll link to this issue from the README and propose the --ping-exit as the most robust option. A few extra container restarts shouldn't be a problem ;) Thanks for coming back with an explanation, good exploring! 👍

[haugene]

Added --ping-exit option to the readme for future reference.