On 12/03/2017 12:09 AM, Michael Siepmann wrote:
On 11/30/2017 10:14 PM, Chris Laprise wrote:
On 11/30/2017 11:44 PM, Michael Siepmann wrote:

On Jun 12, 2017, Andrew Morgan wrote:

Did you follow the "Set up a ProxyVM as a VPN gateway using iptables and
CLI scripts" section of the Qubes VPN docs
(https://www.qubes-os.org/doc/vpn/ <https://www.qubes-os.org/doc/vpn/> )?

If so you should be good just to execute the `/rw/config/rc.local` file
on your VPN VM after every suspend either manually, through a keyboard
shortcut (which I do personally with the following command):

qvm-run -i root sys-vpn "/rw/config/rc.local"

I followed the "Set up a ProxyVM as a VPN gateway using iptables and CLI scripts" instructions but for me executing "/rw/config/rc.local" doesn't make it work again.

I've also tried commenting out or deleting "persist tun" from my OpenVPN config file, as Chris Laprise as suggested in the thread "is vpn made manually, not supposed to restart after suspend?" on May 21 but that isn't helping either.

My current workaround is a script I wrote in dom0 that first does "qvm-prefs VMname -s netvm none" for all the VMs I normally have running that use sys-vpn (my ProxyVM VPN gateway), then shuts sys-vpn down, waits 10 seconds, starts sys-vpn, then does "qvm-prefs VMname -s netvm sys-vpn" for all those VMs.

Any ideas what could be going on so that neither executing /rw/config/rc.local nor commenting out "persist tun" works in my case?


I have a couple ideas as to workarounds. Instead of re-starting sys-vpn, you could:

  qvm-run -u root sys-vpn 'pkill openvpn'
  qvm-run -u root sys-vpn 'sh /rw/config/rc.local'

...before you re-enable the netvm prefs.

Also, one thing that changing the netvm prefs does is to trigger qubes-firewall-user-script to run again. You might compare the state of iptables before and after your workaround to see if something went missing after waking from sleep. If that's the case, you could just trigger the script as a third command added to the above.


Thanks! I tried those commands and they don't get it working again. I still have to shut it down and restart it. I also checked the iptables and that does not seem not to be the problem. However, I've found out that after a brief suspend the VPN may continue working, but in cases when it stops working, the process ends and can't be restarted. In the following the first ps command was just after resuming, and the second a few seconds later, after I'd seen the "VPN is down" notification:

    [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
    5 S root      1093     1  0  80   0 - 16371 poll_s 14:33 ?        00:00:42 
openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon
    [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
    [user@sys-vpn ~]$
    [user@sys-vpn ~]$ sudo sh /rw/config/rc.local
    [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
    [user@sys-vpn ~]$

I also tried "pkill openvpn" when it is working, and I can't restart it after that either:

    [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
    5 S root      1134     1  0  80   0 - 16371 poll_s 21:26 ?        00:00:00 
openvpn --cd /rw/config/vpn/ --config openvpn-client.ovpn --daemon
    [user@sys-vpn ~]$ sudo sg qvpn -c "pkill openvpn"
    [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
    [user@sys-vpn ~]$ sudo sh /rw/config/rc.local
    [user@sys-vpn ~]$ sudo sg qvpn -c "ps -leaf | grep openvpn | grep -v grep"
    [user@sys-vpn ~]$

Any ideas why this might be happening?

Looking at openvpn entries in 'journalctl' can give you a better idea.

I've seen instances where openvpn versions starting with 2.4 have this bad reaction to disconnection (which is what sleep/wake is in this case); with openvpn 2.3 you could count on it to keep going/re-connecting. But there may also be an issue with the way Qubes/Xen are handling the virtual interfaces between VMs; the symptoms remind me of basic networking problems many of us have experienced with prior Qubes releases, where only VM restarts would re-build inter-VM links correctly.

But if there isn't a basic networking problem, moving to a service-based config will be more robust and should keep openvpn running. One way to do this is to have your rc.local script start openvpn with systemd-run (and the right options), but I've already created a project that uses a full systemd config to manage VPN processes...

https://github.com/tasket/Qubes-vpn-support

Setup is much easier than the vpn doc, though it currently only works with Qubes 3.2 which I'm guessing you're using. The usual 'systemctl start/stop/status' commands give you control over the qubes-vpn-handler.service that manages openvpn.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9774421f-bcb0-a8bb-199b-7af7a1f09910%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to