search

tasket / Qubes-vpn-support

VPN configuration in Qubes OS
GNU General Public License v3.0
127 stars 28 forks source link

Recovering from disconnect #12

Closed tabbyrobin closed 6 years ago

tabbyrobin commented 6 years ago

The VPN service seems to have a poor ability to recover from service interruptions/disconnections. My computer has a hardware switch to cut power to wifi card/antenna, that I often use to toggle off networking. The VPN often fails to work after using this switch to disconnect.

Regular Qubes sys-net and sys-firewall setup is able to robustly reconnect after hardware wifi power toggling.

This may, or may not, have something to do with MAC addresses. (There is a MAC error upon booting vpn-proxyvm when the problems manifest.)

What workarounds didn't work: From inside the vpn-proxyvm, sudo service restart openvpn did not seem to work to restore connectivity. sudo poweroff and re-starting the vpn-proxyvm did not seem to work either.

What workarounds did work: First shutting down all downstream-networked VMs (VMs using the vpn-proxyvm as their netVM), then restarting the vpn-proxyvm using Qubes VM manager. This seemed to work to restore connectivity.

My setup: Qubes 3.2, debian-8 ProxyVM, directly installed (into proxyVM, not into template), using openvpn package, with provider ProtonVPN, free tier account.

tasket commented 6 years ago

Best place to start would be to look at systemctl status qubes-vpn-handler when the connection has failed to restart, and journalctl -u qubes-vpn-handler will show you the full log. That will tell you how the .service and openvpn are responding to the situation.

Anticipating the problem, I recommend editing your service file to add --group qvpn to the options on the ExecStart line. This is already present in the upcoming Qubes 4 compatible release, and it helps ensure that openvpn doesn't get blocked by the OUTPUT rules when it does an internal restart.

You can also tell openvpn to do a hard exit after an interval of no net responses, for example --ping 10 --ping-exit 30. The result will be that openvpn is restarted by the .service about 40 sec. after the link fails.

You may also want to upgrade your template to debian 9, which has a current (2.4.x) release of openvpn. This is the version of debian I've primarily used since spring of last year and I have to say its version of systemd just works better than the one in debian 8.