OpenVPN Setup, Revisited Again!
1,151 views
Skip to first unread message
cprise
Sep 25, 2015, 10:48:58 PM9/25/15
to qubes...@googlegroups.com
OpenVPN setup for Qubes
-----------------------
This is an update of the instructions posted in a previous thread[1],
for a type of connection that completely tunnels all traffic to/from VMs
that are connected to the VPN VM for general Internet use.
This version of the openvpn setup has been tested with fedora-21 and
debian-8 templates on Qubes R3b3. The vpn-setup2.sh script is a modified
version of the one that Olivier Médoc uploaded to the previous thread.
The script has been changed to run without the complication of an
unprivileged user, to provide a static DNS option, and to fix a problem
with pop-up notifications.
---
1. Create a ProxyVM and give it a name like 'sys-vpn'. Use a template
that you trust where you have installed the openvpn package, such as the
debian-8 template, and then set its network to either a firewallvm or
netvm (I use sys-net). Suggested label/color is green.
2. Transfer the attached archive to sys-vpn, then cd to the /rw/config
folder and extract it:
$ sudo tar -xJf openvpn-4qubes.tar.xz
Warning: This will overwrite rc.local and files in subfolder 'openvpn'.
3. The ca.crt, crl.pem and openvpn-client.ovpn are supplied by my VPN
provider; usually providers have these files available for download. The
first two allow the openvpn client to verify the authenticity of the
server (your VPN service may name these files differently).
3. a. If necessary, re-name your .ovpn config file to
'openvpn-client.ovpn' to match the rest of the setup:
$ cd /rw/config/openvpn
$ sudo mv acme-config.ovpn openvpn-client.ovpn
4. openvpn-client.ovpn must be edited to include these 3 script-enabling
lines:
script-security 2
up vpn-setup2.sh
down vpn-setup2.sh
5. Finally, edit the auth.txt file, placing your username on the first
line and password on the second.
Optional: Though it should be unnecessary for most VPN providers, you
can create a 'resolve.static' file in the openvpn folder if you want to
override the automatic DNS. It should be formatted just like
resolve.conf. To switch back to auto/DHCP DNS simply delete the
resolve.static file.
Testing
-------
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! You should see an on-screen pop-up that says "VPN IS UP". Next,
point the 'netvm' setting of an AppVM to sys-vpn then start the AppVM to
start testing the connection.
You can stop the test by pressing Ctrl-C to exit openvpn.
Testing the automatic starting of the VPN connection is simple: Just
shutdown sys-vpn and start it again... the rc.local script will take
over and start the connection automatically. To temporarily stop or
restart the connection, just open a terminal in sys-vpn and issue a
command like:
$ sudo systemctl stop openvpn-client
Notes
-----
The notes I posted previously[2] mostly still apply, though you can
disregard the 'route-up' part.
1. https://groups.google.com/d/msg/qubes-users/-9gR1Va3BnY/pJFTZXp2zzEJ
2. https://groups.google.com/d/msg/qubes-users/-9gR1Va3BnY/n02NJI3dRocJ
-----------------------
This is an update of the instructions posted in a previous thread[1],
for a type of connection that completely tunnels all traffic to/from VMs
that are connected to the VPN VM for general Internet use.
This version of the openvpn setup has been tested with fedora-21 and
debian-8 templates on Qubes R3b3. The vpn-setup2.sh script is a modified
version of the one that Olivier Médoc uploaded to the previous thread.
The script has been changed to run without the complication of an
unprivileged user, to provide a static DNS option, and to fix a problem
with pop-up notifications.
---
1. Create a ProxyVM and give it a name like 'sys-vpn'. Use a template
that you trust where you have installed the openvpn package, such as the
debian-8 template, and then set its network to either a firewallvm or
netvm (I use sys-net). Suggested label/color is green.
2. Transfer the attached archive to sys-vpn, then cd to the /rw/config
folder and extract it:
$ sudo tar -xJf openvpn-4qubes.tar.xz
Warning: This will overwrite rc.local and files in subfolder 'openvpn'.
3. The ca.crt, crl.pem and openvpn-client.ovpn are supplied by my VPN
provider; usually providers have these files available for download. The
first two allow the openvpn client to verify the authenticity of the
server (your VPN service may name these files differently).
3. a. If necessary, re-name your .ovpn config file to
'openvpn-client.ovpn' to match the rest of the setup:
$ cd /rw/config/openvpn
$ sudo mv acme-config.ovpn openvpn-client.ovpn
4. openvpn-client.ovpn must be edited to include these 3 script-enabling
lines:
script-security 2
up vpn-setup2.sh
down vpn-setup2.sh
5. Finally, edit the auth.txt file, placing your username on the first
line and password on the second.
Optional: Though it should be unnecessary for most VPN providers, you
can create a 'resolve.static' file in the openvpn folder if you want to
override the automatic DNS. It should be formatted just like
resolve.conf. To switch back to auto/DHCP DNS simply delete the
resolve.static file.
Testing
-------
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! You should see an on-screen pop-up that says "VPN IS UP". Next,
point the 'netvm' setting of an AppVM to sys-vpn then start the AppVM to
start testing the connection.
You can stop the test by pressing Ctrl-C to exit openvpn.
Testing the automatic starting of the VPN connection is simple: Just
shutdown sys-vpn and start it again... the rc.local script will take
over and start the connection automatically. To temporarily stop or
restart the connection, just open a terminal in sys-vpn and issue a
command like:
$ sudo systemctl stop openvpn-client
Notes
-----
The notes I posted previously[2] mostly still apply, though you can
disregard the 'route-up' part.
1. https://groups.google.com/d/msg/qubes-users/-9gR1Va3BnY/pJFTZXp2zzEJ
2. https://groups.google.com/d/msg/qubes-users/-9gR1Va3BnY/n02NJI3dRocJ
David Hobach
Sep 26, 2015, 6:08:07 AM9/26/15
to cprise, qubes...@googlegroups.com
noticed that you are using the iptables mangle table for filtering which
should usually not be done as far as I know. It's meant for changing
packet headers I think.
I also recall that OpenVPN already sets the routing in a way that should
prevent traffic from bypassing the VPN tunnel (may depend on the VPN
config used though), i.e. dropping all eth0 traffic should be rather
pointless. Actually I'm not sure whether openvpn is still using eth0 to
route it's encrypted traffic, i.e. you might even block yourself.
I attached my solution (which was also updated since the last thread)
fyi. Admittedly yours appears to be far more user-friendly though. ;-)
Connor Page
Sep 26, 2015, 2:13:16 PM9/26/15
to qubes-users
David, in what scenario will there be packets coming in through tun+ with qubes ip address as their source?
David Hobach
Sep 26, 2015, 6:10:13 PM9/26/15
to Connor Page, qubes-users
On 09/26/2015 08:13 PM, Connor Page wrote:
> David, in what scenario will there be packets coming in through tun+ with qubes ip address as their source?
My VPN provider is using a 10.0.0.0/8 address space, Qubes does as well.
> David, in what scenario will there be packets coming in through tun+ with qubes ip address as their source?
That's why I wanted to make sure that no conflicts occur. But it might
be handled by the kernel already, I don't know.
cprise
Sep 26, 2015, 6:29:25 PM9/26/15
to David Hobach, qubes...@googlegroups.com
On 09/26/2015 06:08 AM, David Hobach wrote:
>
> I just had a short look to compare it with my current solution and
> noticed that you are using the iptables mangle table for filtering which
> should usually not be done as far as I know. It's meant for changing
> packet headers I think.
Hi David,
>
> I just had a short look to compare it with my current solution and
> noticed that you are using the iptables mangle table for filtering which
> should usually not be done as far as I know. It's meant for changing
> packet headers I think.
In practice its been a good way to keep forwarding locked down while
keeping the scripts (and instructions) simple and reliable. IIRC in the
previous thread I mentioned how moving iptables commands to a qubes
firewall script also works (while removing "-t mangle").
However, mangle-forward is the *first* thing to be evaluated after Linux
marks the packet for forwarding (and non-VPN forwarding is the key thing
we do not want); AFAIK there's no chance that another decision inserted
by Qubes' manipulation (or anything else) will result in a packet being
inadvertently forwarded *unless* something else is inserted before those
specific rules in mangle-forward (and only there). So under the
circumstances, my confidence in using that arrangement is higher.
>
> I also recall that OpenVPN already sets the routing in a way that should
> prevent traffic from bypassing the VPN tunnel (may depend on the VPN
> config used though), i.e. dropping all eth0 traffic should be rather
> pointless. Actually I'm not sure whether openvpn is still using eth0 to
> route it's encrypted traffic, i.e. you might even block yourself.
regularly. It leaked like a sieve without additional help. So I'm
reticent to rely on openvpn to take care of all the details at the OS
level; maybe it has improved, but neither it nor the OS appear to
register and track the user's *intention* to connect or disconnect with
a VPN, and act accordingly (an intention to connect in this context
means block all forwarding outside the VPN, even if the link isn't
working and/or openvpn has crashed).
As for "block yourself"... do you mean the VPN host? The firewall rules
block forwarding, not access for programs (openvpn) on the host.
Peter M
Sep 26, 2015, 10:15:51 PM9/26/15
to qubes-users
On Saturday, September 26, 2015 at 2:48:58 AM UTC, cprise wrote:
OpenVPN setup for Qubes
-----------------------
This is an update of the instructions posted in a previous thread[1],
for a type of connection that completely tunnels all traffic to/from VMs
that are connected to the VPN VM for general Internet use.
Thanks for the guide. I am relatively new to Qubes OS but had quite a bit of linux experience.
I am trying to connect to BolehVPN (a relatively popular VPN).
When I run the openvpn command "sudo openvpn --writepid /var/run/openvpn/openvpn-client.pid --cd /rw/config/openvpn/ --config openvpn-client.ovpn" I get the following error message:
"SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sun Sep 27 01:58:20 2015 TLS Error: TLS object -> incoming plaintext read error
Sun Sep 27 01:58:20 2015 TLS Error: TLS handshake failed
Sun Sep 27 01:58:20 2015 SIGUSR1[soft,tls-error] received, process restarting"
My guess is that the CA Cert is SSL3 and this is causing my problems. I have tried using debian and fedora proxyvm but have the same problem.
From my OpenVPN file I have the following:
auth sha512
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
Can someone help me here? I am a little lost.
cprise
Sep 27, 2015, 12:28:04 AM9/27/15
to Peter M, qubes-users
On 09/26/2015 10:15 PM, Peter M wrote:
>
>
> On Saturday, September 26, 2015 at 2:48:58 AM UTC, cprise wrote:
>
> OpenVPN setup for Qubes
> -----------------------
>
> This is an update of the instructions posted in a previous thread[1],
> for a type of connection that completely tunnels all traffic to/from
> VMs
> that are connected to the VPN VM for general Internet use.
> <https://groups.google.com/d/msg/qubes-users/-9gR1Va3BnY/n02NJI3dRocJ>
>
>
> On Saturday, September 26, 2015 at 2:48:58 AM UTC, cprise wrote:
>
> OpenVPN setup for Qubes
> -----------------------
>
> This is an update of the instructions posted in a previous thread[1],
> for a type of connection that completely tunnels all traffic to/from
> VMs
> that are connected to the VPN VM for general Internet use.
>
>
> Thanks for the guide. I am relatively new to Qubes OS but had quite a
> bit of linux experience.
> I am trying to connect to BolehVPN (a relatively popular VPN).
> When I run the openvpn command "sudo openvpn --writepid
> /var/run/openvpn/openvpn-client.pid --cd /rw/config/openvpn/ --config
> openvpn-client.ovpn" I get the following error message:
>
> "SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> Sun Sep 27 01:58:20 2015 TLS Error: TLS object -> incoming plaintext
> read error
> Sun Sep 27 01:58:20 2015 TLS Error: TLS handshake failed
> Sun Sep 27 01:58:20 2015 SIGUSR1[soft,tls-error] received, process
> restarting"
>
> My guess is that the CA Cert is SSL3 and this is causing my problems. I
> have tried using debian and fedora proxyvm but have the same problem.
>
> From my OpenVPN file I have the following:
>
> auth sha512
> cipher AES-256-CBC
> tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
>
> Can someone help me here? I am a little lost.
>
>
I assume you first tried it with just the config files that your VPN
>
> Thanks for the guide. I am relatively new to Qubes OS but had quite a
> bit of linux experience.
> I am trying to connect to BolehVPN (a relatively popular VPN).
> When I run the openvpn command "sudo openvpn --writepid
> /var/run/openvpn/openvpn-client.pid --cd /rw/config/openvpn/ --config
> openvpn-client.ovpn" I get the following error message:
>
> "SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> Sun Sep 27 01:58:20 2015 TLS Error: TLS object -> incoming plaintext
> read error
> Sun Sep 27 01:58:20 2015 TLS Error: TLS handshake failed
> Sun Sep 27 01:58:20 2015 SIGUSR1[soft,tls-error] received, process
> restarting"
>
> My guess is that the CA Cert is SSL3 and this is causing my problems. I
> have tried using debian and fedora proxyvm but have the same problem.
>
> From my OpenVPN file I have the following:
>
> auth sha512
> cipher AES-256-CBC
> tls-cipher TLS-DHE-RSA-WITH-AES-128-CBC-SHA
>
> Can someone help me here? I am a little lost.
>
>
service provided... If that didn't work, it does sound like the SSL3
compatibility issue. Perhaps this is cause to call Boleh for tech support?
theman
Sep 27, 2015, 2:10:41 AM9/27/15
to cprise, Peter M, qubes-users
> following files:
ca.crt
your_user.crt
your_user.key
ta.key 1
for example, in the *.ovpn file add the following lines:
ca /rw/config/openvpn/name_of_your_folder/ca.crt
cert /rw/config/openvpn/name_of_your_folder/your_user.crt
key /rw/config/openvpn/name_of_your_folder/your_user.key
tls-auth /rw/config/openvpn/name_of_your_folder/ta.key 1
You also have to change permissions on some of the files
You also have to comment out (put # at the beginning of the line) an
earlier reference in the *.ovpn file to the tls-auth (near the top of
the file).
theman
Sep 27, 2015, 2:14:41 AM9/27/15
to cprise, Peter M, qubes-users
Actually, now I recall, it's a problem with Fedora 21+ and OpenVPN
https://groups.google.com/forum/?hl=en#!searchin/qubes-users/OpenVPN$20setup$2C$20revisited/qubes-users/tC6SBAD_yr4/XvMKhulUJQAJ
Just use the debian template
https://groups.google.com/forum/?hl=en#!searchin/qubes-users/OpenVPN$20setup$2C$20revisited/qubes-users/tC6SBAD_yr4/XvMKhulUJQAJ
Just use the debian template
Peter M
Sep 27, 2015, 10:34:19 AM9/27/15
to qubes-users, cpr...@gmail.com, pjm...@gmail.com, the...@infrasonic.com.au
On Sunday, September 27, 2015 at 6:14:41 AM UTC, theman wrote:
Actually, now I recall, it's a problem with Fedora 21+ and OpenVPN
https://groups.google.com/forum/?hl=en#!searchin/qubes-users/OpenVPN$20setup$2C$20revisited/qubes-users/tC6SBAD_yr4/XvMKhulUJQAJ
Just use the debian template
So what I did:
1.) References to the ta.key, my.crt, my.key and ca.crt were already in my ovpn file. I put the full path (/rw/config/openvpn/my.crt) in just to be on the safe side.
2.) Switched to the Debian template
3.) I was using the ovpn file from my provider (as per the set of instructions)
4.) Tried with (tls-auth ta.key 1) commented out
Results:
When I do everything but step 4 I get the following:
Sun Sep 27 14:18:57 2015 [UNDEF] Inactivity timeout (--ping-restart), restarting
Sun Sep 27 14:18:57 2015 SIGUSR1[soft,ping-restart] received, process restarting
Sun Sep 27 14:18:59 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Sep 27 14:18:59 2015 UDPv4 link local: [undef]
Sun Sep 27 14:18:59 2015 UDPv4 link remote: [AF_INET]142.4.194.8:443
Sun Sep 27 14:19:00 2015 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=MY, ST=WP, L=KualaLumpur, O=VPNService, OU=CertAuth, CN=VPN-Server, emailAddress=amin...@gmail.com
Sun Sep 27 14:19:00 2015 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sun Sep 27 14:19:00 2015 TLS Error: TLS object -> incoming plaintext read error
Sun Sep 27 14:19:00 2015 TLS Error: TLS handshake failed
Sun Sep 27 14:19:00 2015 SIGUSR1[soft,tls-error] received, process restarting
Sun Sep 27 14:19:02 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Sep 27 14:19:02 2015 UDPv4 link local: [undef]
When I comment out tls-auth I get
Sun Sep 27 14:30:55 2015 UDPv4 link remote: [AF_INET]151.80.94.225:443
Sun Sep 27 14:31:05 2015 [UNDEF] Inactivity timeout (--ping-restart), restarting
Sun Sep 27 14:31:05 2015 SIGUSR1[soft,ping-restart] received, process restarting
Sun Sep 27 14:31:07 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Sep 27 14:31:07 2015 UDPv4 link local: [undef]
The provider does specify that I need TLS authentication and a key direction of 1
Sun Sep 27 14:18:57 2015 SIGUSR1[soft,ping-restart] received, process restarting
Sun Sep 27 14:18:59 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Sep 27 14:18:59 2015 UDPv4 link local: [undef]
Sun Sep 27 14:18:59 2015 UDPv4 link remote: [AF_INET]142.4.194.8:443
Sun Sep 27 14:19:00 2015 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=MY, ST=WP, L=KualaLumpur, O=VPNService, OU=CertAuth, CN=VPN-Server, emailAddress=amin...@gmail.com
Sun Sep 27 14:19:00 2015 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sun Sep 27 14:19:00 2015 TLS Error: TLS object -> incoming plaintext read error
Sun Sep 27 14:19:00 2015 TLS Error: TLS handshake failed
Sun Sep 27 14:19:00 2015 SIGUSR1[soft,tls-error] received, process restarting
Sun Sep 27 14:19:02 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Sep 27 14:19:02 2015 UDPv4 link local: [undef]
When I comment out tls-auth I get
Sun Sep 27 14:30:55 2015 UDPv4 link remote: [AF_INET]151.80.94.225:443
Sun Sep 27 14:31:05 2015 [UNDEF] Inactivity timeout (--ping-restart), restarting
Sun Sep 27 14:31:05 2015 SIGUSR1[soft,ping-restart] received, process restarting
Sun Sep 27 14:31:07 2015 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Sep 27 14:31:07 2015 UDPv4 link local: [undef]
The provider does specify that I need TLS authentication and a key direction of 1
Marek Marczykowski-Górecki
Sep 27, 2015, 2:30:49 PM9/27/15
to Peter M, qubes-users, cpr...@gmail.com, the...@infrasonic.com.au
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Sep 27, 2015 at 07:34:18AM -0700, Peter M wrote:
> Sun Sep 27 14:19:00 2015 VERIFY ERROR: depth=1, error=self signed
> certificate in certificate chain: C=MY, ST=WP, L=KualaLumpur, O=VPNService,
> OU=CertAuth, CN=VPN-Server, emailAddress=amin...@gmail.com
> Sun Sep 27 14:19:00 2015 TLS_ERROR: BIO read tls_read_plaintext error:
> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed
Make sure you've specified correct ca.crt (the one you've got from your
VPN provider).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJWCDXOAAoJENuP0xzK19csWWAH/Alfb6973chG6ckts7pxJ3r6
A4zYdVOvlj3qu6iDbo96R85vCe/v4eZTHX7kmBBSRj2t6TFw2GvFevuyzHIHXGHg
gJeT8wG4Enr4G+OLjqfXlUMCbUDMywZlSz2Gcvp4s6jhmmTns2jTfK+m+fvw1GXM
jZk+5Ohebj/4ClWbnCo8KpwLfNI5ooYd9XHLeDnWQvBcZlPC7qQQPX3sA7isxRK8
q6NDSazi/wbN5S/d2KeiP896lUKXUGPDh/X3ynTRxYEJBSc0vuK3nrnvPxXGD/DY
QPSeIDTO+ORSsDbyiGKBFruSSh9iZG6SnDySAujYFSvJ03eaeY8nvfm/jHbYwzw=
=GUnE
-----END PGP SIGNATURE-----
Hash: SHA256
On Sun, Sep 27, 2015 at 07:34:18AM -0700, Peter M wrote:
> Sun Sep 27 14:19:00 2015 VERIFY ERROR: depth=1, error=self signed
> certificate in certificate chain: C=MY, ST=WP, L=KualaLumpur, O=VPNService,
> OU=CertAuth, CN=VPN-Server, emailAddress=amin...@gmail.com
> Sun Sep 27 14:19:00 2015 TLS_ERROR: BIO read tls_read_plaintext error:
> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed
VPN provider).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJWCDXOAAoJENuP0xzK19csWWAH/Alfb6973chG6ckts7pxJ3r6
A4zYdVOvlj3qu6iDbo96R85vCe/v4eZTHX7kmBBSRj2t6TFw2GvFevuyzHIHXGHg
gJeT8wG4Enr4G+OLjqfXlUMCbUDMywZlSz2Gcvp4s6jhmmTns2jTfK+m+fvw1GXM
jZk+5Ohebj/4ClWbnCo8KpwLfNI5ooYd9XHLeDnWQvBcZlPC7qQQPX3sA7isxRK8
q6NDSazi/wbN5S/d2KeiP896lUKXUGPDh/X3ynTRxYEJBSc0vuK3nrnvPxXGD/DY
QPSeIDTO+ORSsDbyiGKBFruSSh9iZG6SnDySAujYFSvJ03eaeY8nvfm/jHbYwzw=
=GUnE
-----END PGP SIGNATURE-----
Peter M
Sep 27, 2015, 4:24:31 PM9/27/15
to qubes-users, pjm...@gmail.com, cpr...@gmail.com, the...@infrasonic.com.au
On Sunday, September 27, 2015 at 6:30:49 PM UTC, Marek Marczykowski-Górecki wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Make sure you've specified correct ca.crt (the one you've got from your
VPN provider).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-
-----END PGP SIGNATURE-----
Thanks you picked up one part of my error. I didnt copy over the correct ca.crt.
I changed the cert but still had connection issues. I decided then to just start a fresh VM and it worked perfectly.
Thanks for all the help here, greatly appreciated. I am becoming a very big fan of qubes very quickly.
cprise
Oct 1, 2015, 1:01:13 AM10/1/15
to qubes...@googlegroups.com
On 09/25/2015 10:48 PM, cprise wrote:
> OpenVPN setup for Qubes
> -----------------------
>
> OpenVPN setup for Qubes
> -----------------------
>
> 3. The ca.crt, crl.pem and openvpn-client.ovpn are supplied by my VPN
> provider; usually providers have these files available for download. The
> first two allow the openvpn client to verify the authenticity of the
> server (your VPN service may name these files differently).
>
> 3. a. If necessary, re-name your .ovpn config file to
> 'openvpn-client.ovpn' to match the rest of the setup:
>
> $ cd /rw/config/openvpn
> $ sudo mv acme-config.ovpn openvpn-client.ovpn
For Clarification:
> provider; usually providers have these files available for download. The
> first two allow the openvpn client to verify the authenticity of the
> server (your VPN service may name these files differently).
>
> 3. a. If necessary, re-name your .ovpn config file to
> 'openvpn-client.ovpn' to match the rest of the setup:
>
> $ cd /rw/config/openvpn
> $ sudo mv acme-config.ovpn openvpn-client.ovpn
These config files are provided as an example only, and will not allow
you to make a connection unless your VPN provider is
privateinternetaccess.com:
ca.crt
crl.pem
openvpn-client.ovpn
After deleting those three files, you must add the openvpn configuration
files provided by your VPN service to the /rw/config/openvpn folder, and
rename their .ovpn file to match the example. This should be considered
"step 0" in the instructions.
Anonymous
Oct 31, 2015, 7:31:36 AM10/31/15
to qubes-users, cpr...@gmail.com
On thing I particularly like about this, is you can create a TemplateVM (copy debian-8), and set up your OpenVPN as above, (I also included a text file that has a list of many of the PIA IP addresses). Then create ProxyVMs based on the template. In each ProxyVM, change the remote IP in your config file to a different server location. So now I have a pile of VPN Proxies, (pia-vpn-nyc, pia-vpn-ca, pia-vpn-nj, pia-vpn-uk, riseup-vpn-ny, riseup-vpn-brazil, etc etc) Now, I can more effectively isolate my different pseudonyms.
Note: PIA "doesn't support" AES-256-CBC with OpenVPN. Which I find unacceptable. So I'll be taking my business elsewhere.
RiseUp VPN has a pretty interesting setup using BitMask. I have setup ProxyVMs that autostart Bitmask to connect to RiseUp, and have been fairly pleased with the results. I tried applying the Adrelanos-Firewall, to make sure that the Proxy fails closed if Bitmask crashes. But I was unsuccessful with that. As it stands, Bitmask closes all connections if the connection to RiseUp is interrupted, but if Bitmask itself crashes, or doesn't start, then you are SOL. Also, I am not sure what Bitmask uses for it's cipher and such, as there is almost no configuration for it that I can find. But it is something others may be interested in, particularly since it is free, and seems to be relatively fast, and you can sign up for it anonymously using Bitmask itself. So you can sign up easily over Tor. The RiseUp Black accounts don't require approval or invitations either. I was able to sign up for several accounts, no problem . Another use for Bitmask could be for those who want the VPN client running in their AppVM for whatever reason.
Note: PIA "doesn't support" AES-256-CBC with OpenVPN. Which I find unacceptable. So I'll be taking my business elsewhere.
RiseUp VPN has a pretty interesting setup using BitMask. I have setup ProxyVMs that autostart Bitmask to connect to RiseUp, and have been fairly pleased with the results. I tried applying the Adrelanos-Firewall, to make sure that the Proxy fails closed if Bitmask crashes. But I was unsuccessful with that. As it stands, Bitmask closes all connections if the connection to RiseUp is interrupted, but if Bitmask itself crashes, or doesn't start, then you are SOL. Also, I am not sure what Bitmask uses for it's cipher and such, as there is almost no configuration for it that I can find. But it is something others may be interested in, particularly since it is free, and seems to be relatively fast, and you can sign up for it anonymously using Bitmask itself. So you can sign up easily over Tor. The RiseUp Black accounts don't require approval or invitations either. I was able to sign up for several accounts, no problem . Another use for Bitmask could be for those who want the VPN client running in their AppVM for whatever reason.
c6dl...@gmail.com
Jan 16, 2016, 11:27:33 AM1/16/16
to qubes-users, cpr...@gmail.com
Hello
Thanks for posting this manual!
I followed every step and the vpn is manually working :)
I got several problems..
Can someone help me with this?
1/ The VPN is manually working with this command:
$ sudo openvpn --writepid /var/run/openvpn/openvpn-client.pid --cd
/rw/config/openvpn/ --config openvpn-client.ovpn
unfortunately the VPN connection is not automatic activated when the sys-vpn is rebooted!
I created a AppVM and point the netVm to this sys-vpn, and when I check my IP is my "normal" IP without vpn.
When I manually make the connection, the vpn is normally working in this appvm.
So my first question is, how to get this working automatic?
And second, the most important.. how can I PREVENT that my AppVM goes online WITHOUT vpn protection??
thanks!
prance...@sigaint.org
Jan 16, 2016, 2:45:34 PM1/16/16
to c6dl...@gmail.com, qubes-users, cpr...@gmail.com
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/8c87634c-4c19-4abc-a969-f4414f9f76ae%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
Add the commands to start the vpn to /rw/config/rc.local and make sure
that it is executable with sudo chmod +x /rw/config/rc.local . That script
is executed every time the VM boots.
c6dl...@gmail.com
Jan 17, 2016, 9:01:48 AM1/17/16
to qubes-users, c6dl...@gmail.com, cpr...@gmail.com
Op zaterdag 16 januari 2016 20:45:34 UTC+1 schreef prance...@sigaint.org:
Thanks mate..
Its working now!!
I use this in combination with the sys-whonix.
I pointed sys-whonix NETvm to sys-vpn ...
When I startup Qubes the VPN and TOR is connecting the same time..
How can I force TOR to wait for the VPN is up?
It's now more a lucky shot if VPN is first of second before TOR
prance...@sigaint.org
Jan 17, 2016, 9:59:18 AM1/17/16
to c6dl...@gmail.com, qubes-users, c6dl...@gmail.com, cpr...@gmail.c
> Thanks mate..
> Its working now!!
>
> I use this in combination with the sys-whonix.
> I pointed sys-whonix NETvm to sys-vpn ...
>
> When I startup Qubes the VPN and TOR is connecting the same time..
> How can I force TOR to wait for the VPN is up?
>
> It's now more a lucky shot if VPN is first of second before TOR
I guess one way would be to play around with the VM startup services in
> Its working now!!
>
> I use this in combination with the sys-whonix.
> I pointed sys-whonix NETvm to sys-vpn ...
>
> When I startup Qubes the VPN and TOR is connecting the same time..
> How can I force TOR to wait for the VPN is up?
>
> It's now more a lucky shot if VPN is first of second before TOR
/etc/systemd/system/multi-user.target.wants/ and figure out how to delay
the whonix one. The easiest way would be to somehow time delay the
whonix-vm's startup. Otherwise you'll need to somehow get the vpn-vm to
inform dom0 that it has connected, and I'm really not sure how that could
be achieved.
Someone else here might give you a step by step for this, but you'd be
better off just figuring it out yourself by searching the net for info on
systemd startup ordering/customization/delays. If you figure it out,
please do post your solution here. Others would benefit from it.
Tim W
Jan 17, 2016, 9:01:00 PM1/17/16
to qubes-users, c6dl...@gmail.com, cpr...@gmail.c, prance...@sigaint.org
I was looking into this for my chained proxy setup I have planned in the next few weeks. vpn.whonix.vpn as well as allowing various vms to use any one of this as their net-vm depending on what section or all of the mutli tunnel I wanted. I also looked at the possibility of automating the VPN start up to ensure user mistakes do not happen but at the same time I worried about the risk of a race condition creating a corruption in the tunnel layers. I ended up looking at the systemd setup as you mentioned.
having very little experince with systemd I went and dug into the dom0 ssytemd directory to see how things were configured.
I think it looks like going into directory:
$ /etc/systemd/system/
There are a few different sub directories. But the one that seems to be for user created vms etc is multi-user.target,wants.
./system/multi-user.target.wants
Again I could be completely wrong here as I am just learning as well.
But I found these pages helpful: http://www.freedesktop.org/software/systemd/man/systemd.unit.html but as we are talking about services this sub page specifically: http://www.freedesktop.org/software/systemd/man/systemd.service.html
Looking in there you can see how you can setup types to prescribe dependencies for the service. Looking at the various configs it looks like not only can you set the VPN service to start before the whonix tor serivice but beyond that by using the type=notify possibly could be user to send notification ot service manager andt thus user message of the service status such as ready ( finished starting), reloading, and stopping.
Then there are the more striaght forward commands such as "before" and "after" to list services after each. So in tor.service you could have under [unit] After=openvpn.service
I do not know if I would user timer function i.e time delay as this best could be a unneeded delay but the real issue is if for some reason the service takes longer. But again I am a major newbie but it seems from looking that there are more definitive ways. I still have a good bit more to understand it all especially in terms of how Qubes handles it all.
I am on board with helping out finding solution info and trying various configs to help debug issues for this. I think there are at least a few people running chained proxies and it would be nice it we could get them to all auto start with confirmation and locked down depenencies ensuring each one starts only when the preceding one is confirmed connected.
having very little experince with systemd I went and dug into the dom0 ssytemd directory to see how things were configured.
I think it looks like going into directory:
$ /etc/systemd/system/
There are a few different sub directories. But the one that seems to be for user created vms etc is multi-user.target,wants.
./system/multi-user.target.wants
Again I could be completely wrong here as I am just learning as well.
But I found these pages helpful: http://www.freedesktop.org/software/systemd/man/systemd.unit.html but as we are talking about services this sub page specifically: http://www.freedesktop.org/software/systemd/man/systemd.service.html
Looking in there you can see how you can setup types to prescribe dependencies for the service. Looking at the various configs it looks like not only can you set the VPN service to start before the whonix tor serivice but beyond that by using the type=notify possibly could be user to send notification ot service manager andt thus user message of the service status such as ready ( finished starting), reloading, and stopping.
Then there are the more striaght forward commands such as "before" and "after" to list services after each. So in tor.service you could have under [unit] After=openvpn.service
I do not know if I would user timer function i.e time delay as this best could be a unneeded delay but the real issue is if for some reason the service takes longer. But again I am a major newbie but it seems from looking that there are more definitive ways. I still have a good bit more to understand it all especially in terms of how Qubes handles it all.
I am on board with helping out finding solution info and trying various configs to help debug issues for this. I think there are at least a few people running chained proxies and it would be nice it we could get them to all auto start with confirmation and locked down depenencies ensuring each one starts only when the preceding one is confirmed connected.
c6dl...@gmail.com
Jan 18, 2016, 2:21:28 AM1/18/16
to qubes-users, c6dl...@gmail.com, cpr...@gmail.c, prance...@sigaint.org
@Tim
Nice reply!!
Your knowledge is way beyond mine .. So I think I cannot help you with this :(
I followed this thread and my vpn is working when the sys-vpn is online.
I UNCHECKED the automatic startup of whonix, so this way I am in control that the VPN must be online first.
It's sort of a work around ;)
My worst concern.. and maybe the most important thing to fix..
Is that there is no "check" that monitors the VPN connection.
IF the VPN is down...then TOR is reconnecting (with my OWN ip) and still up,
so my Appvm's is also reconnected without the VPN...
This is my biggest concern :(
prance...@sigaint.org
Jan 18, 2016, 8:24:33 AM1/18/16
to Tim W, qubes-users, c6dl...@gmail.com, cpr...@gmail.c
>
> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/c59241a2-7d17-409c-a00f-72b87ad85d84%40googlegroups.com.
> --
> 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...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
Hi again Tim,
Thanks for looking into this. The links look useful. I agree a time delay
is not ideal, but if the vpn connection was delayed and you've got the
vpn-vm firewalled correctly (i.e. no connections except to vpnip:port),
then the worst that could happen is no connectivity in the whonix-gateway.
A pain, true, but it won't reveal you are using tor.
I had two reasons for suggesting a time delay. One, is it's probably the
easiest solution to implement. Two, I am slightly worried (maybe
foolishly) that allowing the vpn-vm to communicate the vpn's status to
dom0 could potentially be a security issue. That might sound paranoid, but
any line of communication from vms to dom0 are a potential avenue to
exploit. Hopefully, a developer might weigh in on the second worry.
Reply all
Reply to author
Forward
0 new messages