OpenVPN Setup, revisited

[cprise]

It seems there are still people struggling with VPNs in Qubes, so
following are full the details of my own VPN setup which has worked out
very well . . .

Proxy VMs are eminently suited for the task of running a VPN link, and
this is the type of VPN VM I'm going to describe.

You can still setup a VPN link with NetworkManager in a netvm, but
auto-connection probably won't work and you'd be exposing your
credentials to an untrusted environment that way. A proxy vm will be
relatively secure and have fully automatic VPN connections.


First create a ProxyVM and give it a name that is VPN-related. Use a
template that you trust, like the original fedora template, and you can
set its network to either a firewallvm or netvm (I use netvm). Suggested
label/color is green.

Second, open a terminal in the VPN VM and get the contents of your
openvpn folder together so that you can manually connect using the
openvpn command.

Here is what my /rw/config/openvpn folder looks like for a connection
through my privateinternetaccess.com account:
$ ls -l
total 40
-rw------- 1 root root 22 Mar 17 19:20 auth.txt
-rw-r--r-- 1 root root 1395 Mar 17 19:20 ca.crt
-rw-r--r-- 1 root root 577 Mar 17 19:20 crl.pem
-rwxr-xr-x 1 root root 350 Mar 17 19:20 down.sh
-rw-r--r-- 1 root root 667 Mar 17 19:20 openvpn-client.ovpn
-rw-r--r-- 1 root root 52 Mar 17 19:20 resolv.conf
-rwxr-xr-x 1 root root 88 Mar 17 19:20 resolv.sh
-rwxr-xr-x 1 root root 367 Mar 17 19:20 up.sh

The ca.crt, crl.pem and openvpn-client.ovpn are supplied by your VPN
service; usually they have these files available for download. The first
two allow our openvpn client to verify the authenticity of the server.

The .ovpn file holds the configuration, which I have edited to this:

===
client
dev tun
proto udp
remote us-east.privateinternetaccess.com 1194
remote-random
resolv-retry infinite
nobind
persist-key
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass auth.txt
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.pem
script-security 2
route-up resolv.sh
up up.sh
down down.sh
===



The auth.txt file simply contains your username on the first line and
password on the second. If your VPN service requires a private key
instead of username+password then you will need to change the above
config for that type of authentication.


The resolv.conf file contains name server entries supplied by your VPN
service provider (they could also be public or private DNS servers of
your choosing):

===
nameserver 209.222.18.222
nameserver 209.222.18.218
===



The resolv.sh script tells Qubes firewall to use the VPN for DNS queries
and looks like this:

===
#!/bin/bash

cp resolv.conf /etc/resolv.conf
/etc/dhclient.d/qubes-setup-dnat-to-ns.sh
===



The down.sh script displays an on-screen message when the VPN disconnects:

===
#!/bin/bash

SPID=$(pgrep -f gnome-session)
dbus=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$SPID/environ|cut -d= -f2-)
export DBUS_SESSION_BUS_ADDRESS=$dbus

su -c 'notify-send -i /usr/share/pixmaps/faces/lightning.jpg "VPN IS
DOWN !" --icon=dialog-error' user
===



The up.sh script displays an on-screen message when the VPN connects:

===
#!/bin/bash

SPID=$(pgrep -f gnome-session)
dbus=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$SPID/environ|cut -d= -f2-)
export DBUS_SESSION_BUS_ADDRESS=$dbus

su -c 'notify-send -i /usr/share/pixmaps/faces/tennis-ball.png "VPN IS
UP"' user
===



All of the files ending in .sh must be made executable:
$ sudo chmod +x /rw/config/openvpn/*.sh

Finally (for now), you can test the connection manually like this:
$ sudo openvpn --writepid /var/run/openvpn/openvpn-client.pid --cd
/rw/config/openvpn/ --config openvpn-client.ovpn

When it says "Initialization Sequence Completed" the link is ready to use!



In my next message, I'll set openvpn to run automatically as a service.
Then I'll tweak the firewall to block any direct (non-VPN) routing from
other VMs to the Internet.

-cprise

[David Hobach]

Nice guide, could have used it recently! I attached the script I use
fyi. It assumes that the keys are in the *.ovpn files though.

[HW42]

David Hobach:

I would suggest that you add to /rw/config/qubes-firewall-user-script
something like this to prevent leaks:
#!/bin/sh
iptables -I FORWARD 2 ! -o tun0 -j REJECT --reject-with icmp-admin-prohibited

[David Hobach]

That solution might work, but only in the VPN proxy VM (didn't test it)
or in the netvm, if you run your VPN there, as tun0 only exists there.

I prefer to have a dedicated proxy VPN VM + the firewall rules
preventing leaks in the firewall VM for security reasons (even if the
VPN VM is owned, no one can change my firewall settings) and thus tend
to use the Qubes manager.

[cprise]

On 03/21/15 23:57, cprise wrote:
> It seems there are still people struggling with VPNs in Qubes, so
> following are full the details of my own VPN setup which has worked out
> very well . . .
>

[...]

>
> In my next message, I'll set openvpn to run automatically as a service.
> Then I'll tweak the firewall to block any direct (non-VPN) routing from
> other VMs to the Internet.
>
> -cprise

This second half of the openvpn setup will be quick and requires only
two additional files, which I have attached.

Before continuing, you should have already added and populated the
/rw/config/openvpn folder in your VPN VM and tested it there per my
previous message.


Simply add 'openvpn-client.service' and 'rc.local' to the /rw/config
directory and make rc.local executable:
$ sudo chmod +x /rw/config/rc.local

Now your VPN connection should start whenever your VPN VM starts!
Openvpn will start/restart the VPN link on its own whenever it has
access to the Internet, and will notify you whenever the virtual link
goes up or down.

Generally, I use NetworkManager (Netvm) to control the connnection. If,
for some reason, you want to disconnect the VPN while Netvm still has a
physical connnection, just set the VPN VM's network to 'none' from VM
Manager window or use 'sudo systemctl stop openvpn-client' from a VPN VM
shell prompt to stop the service (you can easily add such commands to
your launcher menu).


-- Some Notes --

This openvpn configuration is intended to completely tunnel traffic of
participating VMs through a commercial subscription VPN (aka 'public
VPN') for general Internet use. You may want to use a VPN for other
roles, in which case you'll need a different openvpn configuration, or
even additional VPN VMs to handle home, work, etc. connections. In some
cases the content of this Howto will not apply at all. Even if you
intend general Intenet use, you will probably need to at least tweak the
.ovpn config file to point to your VPN service; Replacing the .ovpn with
your own or one provided by your VPN service will probably require that
you add the 'route-up' line or some equivalent.

Firewall -- If you're concerned about firewall configuration, note the
rc.local script will add the following rules:

iptables -t mangle -I FORWARD 1 -o eth0 -j DROP
iptables -t mangle -I FORWARD 2 -i eth0 -j DROP

These should be very effective in stopping any flow of data to the
network 'in the clear'. Should openvpn crash or exit for some reason,
accidental forwarding of data through the uplink interface (eth0) will
be prevented.

IMHO, the risk of exploitation of the VPN VM is low since most of what
it does is encrypt, decrypt and route packets; So I believe its fine to
use the firewall in the VPN VM. An alternative already suggested in this
thread (using upstream Qubes firewall) can be added to the above
measure, although it does not necessarily provide more (or even as much)
protection in case of a breech. If the threat involves the upstream ISP
or LAN even incidentally, then a breeched VPN VM could make your
plaintext data visible to either the attacker or third parties
/regardless/ of the Qubes firewall filtering by address or port
number... if others can sniff the traffic then to whom or how its
addressed may not matter.

I know of no firewalling scheme that can thorougly protect against
compromised VPN software (e.g., we are trusting openvpn to be secure).
But if anyone can propose an ingenious solution then I'm all ears...

Also note I did not use the Qubes firewall script, and the rules are put
in the 'mangle' table to avoid their erasure by Qubes firewall. If you
want to be more formal you can change '-t mangle' to '-t filter' on each
line and move them to /rw/config/qubes-firewall-user-script; Qubes
firewall will then replace the new rules each time the table is erased.

Finally, there is a small bug in Qubes that leaves VMs in the 'yellow'
state after they start up and this can happen to the VPN VM, too. In
this case the VPN should operate normally -- but the up/down status
messages will not display. (If someone could post a link to the thread
that deals with this I'd appreciate it.) The shorthand solution is to
tell Qubes to run something in the VM; simply running a Terminal will do
the trick.

That's all. Enjoy!

-cprise

[cprise]

On 03/22/15 06:06, David Hobach wrote:

>
> Nice guide, could have used it recently! I attached the script I use
> fyi. It assumes that the keys are in the *.ovpn files though.

Thanks for sharing your script... One thing it does that mine doesn't is
to make a backup of resolve.conf. I also like that is creates a named
chain for the firewall rules.

One thing I wanted to do for my VPN but didn't was to create a systray
status icon; But I also wanted to stay in bash and couldn't find a
straightforward do it.

[David Hobach]

Good point! The only advantage of using the firewall VM would then be
trying to prevent an attacker from further attacking other targets in
the LAN or other VMs (if inter-VM communication is allowed) after having
owned the VPN VM, but certainly not data leakage.
Plus I hope Qubes updates are less likely to screw it up.

> I know of no firewalling scheme that can thorougly protect against
> compromised VPN software (e.g., we are trusting openvpn to be secure).
> But if anyone can propose an ingenious solution then I'm all ears...
>
> Also note I did not use the Qubes firewall script, and the rules are put
> in the 'mangle' table to avoid their erasure by Qubes firewall. If you
> want to be more formal you can change '-t mangle' to '-t filter' on each
> line and move them to /rw/config/qubes-firewall-user-script; Qubes
> firewall will then replace the new rules each time the table is erased.
>
> Finally, there is a small bug in Qubes that leaves VMs in the 'yellow'
> state after they start up and this can happen to the VPN VM, too. In
> this case the VPN should operate normally -- but the up/down status
> messages will not display. (If someone could post a link to the thread
> that deals with this I'd appreciate it.) The shorthand solution is to
> tell Qubes to run something in the VM; simply running a Terminal will do
> the trick.

Didn't find it neither, but I recall it involved adding some sleep delay
in /etc/xdg/autostart/qubes-guid.desktop.

[cprise]

Actually, that is a good point about other LAN targets. Routers/APs have
become increasingly targeted by spies and crooks, sometimes to gain MITM
capability. It depends on the threat model.

Also, a VPN service might have hundreds of IP addresses on different
subnets, and DNS picks them randomly. Coordinating the addresses between
the two VMs could be a problem; I'd even lean toward adding the
address-based blocking inside the VPN VM for this reason (or else try
picking one address).

[conp...@gmail.com]

On Monday, 23 March 2015 19:45:54 UTC, cprise wrote:
>
> Actually, that is a good point about other LAN targets. Routers/APs have
> become increasingly targeted by spies and crooks, sometimes to gain MITM
> capability. It depends on the threat model.
>
> Also, a VPN service might have hundreds of IP addresses on different
> subnets, and DNS picks them randomly. Coordinating the addresses between
> the two VMs could be a problem; I'd even lean toward adding the
> address-based blocking inside the VPN VM for this reason (or else try
> picking one address).
>
>

Thanks for the ideas. I haven't noticed any iptables rules that would block packets coming from tun0, just FORWARD rules. Are you blocking those?

[gaffne...@gmail.com]

I am new to openvpn and followed the directions from cprise and it seemed that everything worked properly with the exception of the iptables rules added via rc.local

iptables -t mangle -I FORWARD 1 -o eth0 -j DROP
iptables -t mangle -I FORWARD 2 -i eth0 -j DROP

I setup the system as follows using qubes 3x
1. clone default template -fedora-21-openvpn
2. create a new proxyvm using the new template -openvpn -- asign networking as sys-net
3. I applied all the scripts and rules into the new proxyvm using the config file sent by my vpn.
4. create a new appvm and assign the netvm as the new proxyvm created above.

What I noticed is that I have no problem reaching the net using the actual proxyvm and my ip shows as the vpn so seems to work.

If I try to use the new appvm (which is how I want to set it up to separate the proxy from the app for security) then I have no net access and firefox just spins caught in a loop using max cpu.

I removed the 2 above iptables rules from the rc.local in the proxyvm and now I have no problem using the appvm through the proxy to get online.

Any idea what I did wrong to make it so that the iptables rules are not working?
Are those rules supposed to be added to something other than the rc.local in the new proxyvm?

thanks for the great guide cprise! It really forced me to not just copy and paste but to try and really understand what each step is doing and why. I'm getting much closer to understanding the basics of this.

[conp...@gmail.com]

The rules should not be removed, though I think that one of them is obsolete and I dont understand why they are applied in mangle table.
Your problem is most probably with DNS queries, that appvm sends. Looks like they are routed not through VPN so they get blocked if the filter rules are applied. Please check "iptables -t nat -L -n -v" once VPN link is established. If the destination in DNAT rules are Qubes internal IP addresses (10.137...) then something is wrong with your list of DNS resolvers (have you changed those?) or the Qubes DNAT script. In my setup I just added a PREROUTING rule to redirect all DNS queries to a trusted public server as I never intend to use the VM with VPN turned off.

[Olivier Médoc]

On 03/23/15 00:50, cprise wrote:
> On 03/21/15 23:57, cprise wrote:
>> It seems there are still people struggling with VPNs in Qubes, so
>> following are full the details of my own VPN setup which has worked out
>> very well . . .
>>
> [...]
>>
>> In my next message, I'll set openvpn to run automatically as a service.
>> Then I'll tweak the firewall to block any direct (non-VPN) routing from
>> other VMs to the Internet.
>>
>> -cprise
>
> This second half of the openvpn setup will be quick and requires only
> two additional files, which I have attached.
>
> Before continuing, you should have already added and populated the
> /rw/config/openvpn folder in your VPN VM and tested it there per my
> previous message.
>
>
> Simply add 'openvpn-client.service' and 'rc.local' to the /rw/config
> directory and make rc.local executable:
> $ sudo chmod +x /rw/config/rc.local
>
> Now your VPN connection should start whenever your VPN VM starts!
> Openvpn will start/restart the VPN link on its own whenever it has
> access to the Internet, and will notify you whenever the virtual link
> goes up or down.
>

Nice scripts.

I'm trying to improve them slightly:
- DNSs can be retrieved in the UP script via variables that are sent by
the VPN/DHCP server
- A single script can be used for up.sh/down.sh

I sent to you a feedback as soon as I manage to make my vpn server
working again...

[Olivier Médoc]

Hello,

You can find attached the modified up/down script that retrieve the DNS
server from the DHCP variables.

The openvpn config can then be changed to :
script-security 2
#route-up resolv.sh
up vpn-setup.sh
down vpn-setup.sh

[cprise]

The two rules block forwarding to/from the uplink port (eth0) only, so
you should consider my configuration to be secure for use cases where
one VPN link supplies N downstream VMs.

I don't know what blocking of packets from tun0 would accomplish beyond
that. Since the client apps are assumed to be in downstream VMs, there
are no apps local to the VPN VM that might access tun0.

Also note that OpenVPN should block any traffic between various
downstream VMs by default. A special option must be specified in order
for clients to be able to see each others' traffic on the VPN.

[cprise]

Thanks for that, Olivier. I decided to use a simple populated
resolv.conf file because my provider fortunately has only a couple of
static addresses. But your contribution does reduce the number of files
a user has to setup by 2.

I also changed the notify part of the script to work properly under
Debian 8, so I'll probably post another revision and also include your
changes.

[Otto Kratik]

Thanks for posting this detailed guide, as getting a setup that ultimately goes:  Computer -> TorVM -> VpnVM - > Internet  has been one of my goals for a while. The idea being that one's ISP only sees the connection to the VPN, and has no knowledge that one is connecting to TOR beyond that.

Given how elaborately complicated-as-all-hell it seems to get even just the OpenVPN setup working correctly, I very much doubt I'd have much chance at success without step-by-step instructions like these above. Even with them, I estimate approximately 16-20 hours of trial and error attempts and constant failure, before hopefully eventually getting to the point where it works. I'll of course test OpenVPN through a ProxyVM first by itself, before trying to integrate TorVM as well, which is already working independently.

Since I'll be using a different VPN provider from the one listed above, I imagine they'll have they're own unique configurational parameters which will differ significantly enough from the example as to cause a few more headaches. It probably doesn't help a great deal that I've never used GNU/Linux before in my life, prior to trying QubesOS. Tough way to dive into it for the first time.

[7v5w7go9ub0o]

On 07/09/2015 01:04 PM, Otto Kratik wrote:
> Thanks for posting this detailed guide, as getting a setup that ultimately
> goes: Computer -> TorVM -> VpnVM - > Internet has been one of my goals
> for a while. The idea being that one's ISP only sees the connection to the
> VPN, and has no knowledge that one is connecting to TOR beyond that.

Heh.... yep! (though it would be computer -> vpn -> TOR -> net)

And alternatively, on the road you may want to TOR out of the hotspot
(they don't need to see your VPN destination - especially if it is on
your home router) and then VPN on to routine business. Each works well
using the DOM0 gui.

[Otto Kratik]

On Thursday, July 9, 2015 at 4:10:11 PM UTC-4, 7v5w7go9ub0o wrote:

Heh.... yep! (though it would be computer -> vpn -> TOR -> net)

Isn't the outermost layer, the one that the ISP sees, closest to the "net" mode? I guess I was phrasing it in the order of connected VM's within Qubes. Meaning, AppVM sends request to TorVM, which sends it along to VpnVM, which in turn passes it along to normal NetVM. But yes I see what you mean, in visualized terms the computer is connecting to the VPN first, then from there to TOR, then from there to a website or whatever. Same setup, just illustrated differently from within the Qubes VM infrastructure versus the external network of nodes.

 

And alternatively, on the road you may want to TOR out of the hotspot
(they don't need to see your VPN destination - especially if it is on
your home router) and then VPN on to routine business. Each works well
using the DOM0 gui.

Yes, just have to actually get the VpnVM up and functioning first, then easily manageable from Qubes Manager thereafter. My VPN will likely be a remote one located somewhere in NeverNeverland, rather than on a home router, so connecting to it on the road shouldn't be an issue.

[cprise]

On 07/09/2015 01:04 PM, Otto Kratik wrote:

Most of the paid VPN services that support openvpn have pretty similar
parameters, and will supply a configuration file (or a set of them, with
a cert included to protect against MITM) for you to use. Once the config
file tests OK using 'openvpn' on the command line, it gets easy from there.

Also, you can save yourself some steps (i.e. not having to manually add
your DNS addresses to a resolv file) if you use Olivier's script instead
of my 3 .sh scripts:

https://groups.google.com/d/msgid/qubes-users/556FFC4D.3060600%40yahoo.fr

If you are using Debian (as I am now) for your VM instead of Fedora, you
will need to change the 'SPID=' line in order for VPN status
notifications to work. The following will work on both Debian 8 and
Fedora 20:

SPID=$(pgrep -U user -f dconf-service)

[Otto Kratik]

Thanks, I am certainly going to give it a shot. Right now it is about fifth or sixth on my list of Qubes-related tasks, after getting Fedora 21 templates to install correctly, updating Dom0 without a crash, and a few other configurational type items. Once that is done I will tackle OpenVPN..  I am using Fedora (20/21 remains to be determined) so hopefully minimal custom changes will be needed.

[☣Adam]

If you plan on going the other way around (going through Tor network
-> VPN -> Internet), to hide your IP from the VPN provider (but allow
your ISP to see that you are using Tor), you'll probably experience
problems unless you have the patch available here:
https://community.openvpn.net/openvpn/ticket/328

After I added that patch, OpenVPN worked just fine when going through
Tor. The patch has been available for 15 months, but based on the
last comment, it looks like the maintainers have no intention of
reviewing & including it. That's a shame since it's only about 20
lines of code, and is backward compatible.

[nelsonb...@gmail.com]

Hey guys, great thread. I just wanted to post what has worked well for me. I needed a way to manage multiple available vpn servers efficiently.

* I built a package called Gopenvpn, which is a graphical front end for OpenVpn, not network manager:

https://github.com/dweeezil/gopenvpn

* I added these lines to /rw/config/qubes-firewall-user-script which will prevent DNS leaks:
iptables -t filter -I FORWARD 1 -o eth0 -j drop
iptables -t filter -I FORWARD 1 -o eth1 -j drop

* Gopen looks for config files in /etc/openvpn.

* Edit your config file appropriately

* add lines:
auth-user-pass nameofyourauth.txt
script-security 2
#route-up resolv.sh
up openvpn-setup.sh
down openvpn-set
* add lines for your certs or/and key if needed
ca nameofyour_ca.crt
tls-auth nameofyour.key 1

* Create auth.txt in /etc/openvpn
* add two lines
username
password

* Copy vpnsetup-sh to /etc/openvpn --- file was posted earlier in thread

* Copy resolv.conf to /etc/openvpn --- file was posted earlier in thread

* Gopenvpns GUI will now show whatever available servers you configured in /etc/openvpn

* All your configs will use openvpn-setup.sh which will configure your DNS servers automatically

* All your configs will contain these lines:
script-security 2
#route-up resolv.sh
up openvpn-setup.sh
down openvpn-setup.sh

* If you want your GUI to launch and VPN connect at startup

* Download gnome-tweak-tool

* Launch and and add gopenvpn.desktop (make executable) to Startup Applications

* Select auto connect option in gopenvpn GUI

Let me know if this setup works for y'all

[nelsonb...@gmail.com]

> * Gopen looks for config files in /etc/openvpn.
>
> * Edit your config file appropriately
>
> * add lines:
> auth-user-pass nameofyourauth.txt
> script-security 2
> #route-up resolv.sh
> up openvpn-setup.sh

> down openvpn-setup.sh

I don't know how to edit a post on here but in my original post there was a typo on the last line. It should read

down openvpn-setup.sh

[conp...@gmail.com]

On Thursday, 30 July 2015 22:07:25 UTC+1, nelsonb...@gmail.com wrote:
> Hey guys, great thread. I just wanted to post what has worked well for me. I needed a way to manage multiple available vpn servers efficiently.
>
> * I built a package called Gopenvpn, which is a graphical front end for OpenVpn, not network manager:
>
> https://github.com/dweeezil/gopenvpn
>
>
> * I added these lines to /rw/config/qubes-firewall-user-script which will prevent DNS leaks:
> iptables -t filter -I FORWARD 1 -o eth0 -j drop
> iptables -t filter -I FORWARD 1 -o eth1 -j drop
>
> * Gopen looks for config files in /etc/openvpn.
>
> * Edit your config file appropriately
>
> * add lines:
> auth-user-pass nameofyourauth.txt
> script-security 2
> #route-up resolv.sh
> up openvpn-setup.sh
> down openvpn-set
> * add lines for your certs or/and key if needed
> ca nameofyour_ca.crt
> tls-auth nameofyour.key 1
>
> * Create auth.txt in /etc/openvpn
> * add two lines
> username
> password
>

Did you do that in a template and expose your credentials to all VMs based on that??? You can provide full path to the file with password and store it in /home/user/openvpn of just one vm that doesn't run anything else.
cprise's approach of storing config files in /rw/config and copying them to /etc on start is the best practice for qubes.

[nelsonb...@gmail.com]

I did this all in a standalone proxy vm. It wouldn't matter how inconspicuous the title of the credentials file had or where the file was stored, all an adversary had to do is take a quick look in the pain text configuration file

[Cube]

Note that on Oliviers script above (vpn-setup.sh), it need to bet set executable to work.

The excellent scripts and notes on this thread work for me, however after a system sleep the VPN is down and doesn't come up. Sending a SIGHUP/SIGUSR1 to the process doesn't help, I can only reenable the vpn by killing the existing process, systemd then launches a new one and it's up again.

Any thoughts on how to have it auto reconnect?

[Cube]

Solved it. Here is a solution to have your VPN seamlessly re-initiailize after sleep, using the above scripts. This should really be set up as a salt configuration or something, I'll try to look into that.

Based on this post I created the following file in /etc/systemd/system/wakeup.service  ...

[Unit]
Description=Run user script after suspend
After=basic.target
After=suspend.target
After=hibernate.target

[Service]
User=YOURLOGIN
Environment=Display=:0
ExecStart=/home/YOURLOGIN/bin/wakeup.sh

[Install]
WantedBy=basic.target
WantedBy=suspend.target
WantedBy=hibernate.target

 Then create the 'wakeup.sh' referenced above (make it executable)

#!/bin/bash

qvm-run YOUR-VPN-VMNAME 'sudo kill -SIGHUP `sudo cat /var/run/openvpn/openvpn-client.pid`'

Then run the commands as given in the link provided above

systemctl enable wakeup.service

systemctl status wakeup.service

And you should be good to go. I notice that the notifications don't usually make it to the screen on wakeup, but it indeed does reset the VPN and reconnect automatically.


 

[Manuel Amador (Rudd-O)]

On 12/27/2015 07:06 PM, Cube wrote:
> Solved it. Here is a solution to have your VPN seamlessly
> re-initiailize after sleep, using the above scripts. This should
> really be set up as a salt configuration or something, I'll try to
> look into that.

Using
https://github.com/Rudd-O/ansible-qubes/tree/master/examples/ansible
this is the formula you want:


------wakeupservice.yml playbook -------
- hosts: <your template>
- sudo: True
- tasks:
- name: set up service
template:
src: wakeup.service.j2
dest: /etc/systemd/system/wakeup.service
mode: 0644
- name: activate service on next boot
service: name=wakeup enabled=True
- name: copy shell script
copy:
src: shellscript.sh
dest: /usr/local/bin/shellscript.sh
mode: 0755
----------- wakeup.service.j2 -----------

|
[Unit]
Description=Runshellscript after suspend
After=basic.target
After=suspend.target
After=hibernate.target

[Service]
Environment=Display=:0
ExecStart=/usr/local/bin/shellscript.sh

[Install]
WantedBy=basic.target
WantedBy=suspend.target
WantedBy=hibernate.target
|
------- shellscript.sh ---------
#!/bin/bash

echo "I ran after suspend/hibernate"
---------------------------------

The example has been posted here too:

https://github.com/Rudd-O/ansible-qubes/tree/master/examples/sampleplaybooks

--
Rudd-O
http://rudd-o.com/

[Cube]

On Sunday, December 27, 2015 at 7:51:00 PM UTC-8, Manuel Amador (Rudd-O) wrote:

Using
https://github.com/Rudd-O/ansible-qubes/tree/master/examples/ansible
this is the formula you want:

Good work! But Qubes has decided on using Salt Stack as the management tool recently

https://www.qubes-os.org/news/2015/12/14/mgmt-stack/ 

My script will work standalone, and I'd prefer sticking with mainline systems so will look into integrating this vpn foo into that as a VPN module or something.

[Manuel Amador (Rudd-O)]

On 12/28/2015 01:13 PM, Cube wrote:
>
>
> On Sunday, December 27, 2015 at 7:51:00 PM UTC-8, Manuel Amador
> (Rudd-O) wrote:
>
> Using
> https://github.com/Rudd-O/ansible-qubes/tree/master/examples/ansible
> <https://github.com/Rudd-O/ansible-qubes/tree/master/examples/ansible>
>
> this is the formula you want:
>
>
> Good work! But Qubes has decided on using Salt Stack as the management
> tool recently

Yes, I'm not competing with that. In fact the latest update to my
project incorporates Qubes SaltStack compatibility.

>
> My script will work standalone, and I'd prefer sticking with mainline
> systems so will look into integrating this vpn foo into that as a VPN
> module or something.

The SaltStack subsystem in Qubes is not yet capable of customizing any
innards of any VMs, as far as I knew. It can only deploy VMs and set VM
properties. To customize what actually goes in the VM, you need
something like Ansible or proper SaltStack recipes with the SaltStack
connection module that I shared in the project I linked above. Or maybe
a shellscript, but you would have to write tons of support code to get
everything to work nicely without copypaste.

Anyway, good luck with the VPN thing!

--
Rudd-O
http://rudd-o.com/