Enabling OpenVPN auto start

[Ninja...@protonmail.com]

In using the following command:
edit /etc/default/openvpn
Then attempting to remove the # next to “#AUTOSTART=“all”” I am unable to remove the hash.

Can anyone tell me why i’m unable to remove the hash? And how to go about removing it so I can auto start openvpn.

Thanks

[Chris Laprise]

I'm not familiar with 'edit'. Most would use 'sudo vim' or 'sudo nano'
to edit a settings file in the terminal.

Also, if you're looking for a VPN solution I'd recommend using
https://github.com/tasket/qubes-tunnel which automatically takes care of
the Qubes-specific DNS and iptables details.

--

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

[Ninja...@protonmail.com]

Dude I actually love you (no homo).

Spent 20+ trying to set vpn up (Big ass noob) and never came across the Qubes tunnel. It’s awesome. You’re awesome.

[Stuart Perkins]

I have two separate VPN's on my Qubes 3.2 laptop.

One Cisco VPN running via OpenConnect in a dedicated appVM for a client.
One OpenVPN running in a secondary copy of sys-net which I switch to when I need it. I run the server OpenVPN on a VM on my home server (Debian and VirtualBox).

When I want to connect EVERYTHING to the VPN, I switch out and run the copy of sys-net with the VPN credentials and scripts.

When I want to access the client, I start the appVM with the OpenConnect Cisco VPN client and credentials. I also use this appVM to run client specific software through Wine for most of my work on their equipment, although I do a fair amount of straight up command line stuff on their system as well. I can run this on top of the other VPN if absolutely necessary, but performance is not fast since my home connection is not fast.

Haven't had occasion to try the Qubes tunnel. Is there a particular reason to?

[Chris Laprise]

On 09/25/2018 05:27 PM, Stuart Perkins wrote:
>
> On Tue, 25 Sep 2018 12:52:16 -0700 (PDT)
> Ninja-mania via qubes-users <qubes...@googlegroups.com> wrote:
>
>> Dude I actually love you (no homo).
>>
>> Spent 20+ trying to set vpn up (Big ass noob) and never came across the Qubes tunnel. It’s awesome. You’re awesome.

Glad to help!

> I have two separate VPN's on my Qubes 3.2 laptop.
>
> One Cisco VPN running via OpenConnect in a dedicated appVM for a client.
> One OpenVPN running in a secondary copy of sys-net which I switch to when I need it. I run the server OpenVPN on a VM on my home server (Debian and VirtualBox).
>
> When I want to connect EVERYTHING to the VPN, I switch out and run the copy of sys-net with the VPN credentials and scripts.
>
> When I want to access the client, I start the appVM with the OpenConnect Cisco VPN client and credentials. I also use this appVM to run client specific software through Wine for most of my work on their equipment, although I do a fair amount of straight up command line stuff on their system as well. I can run this on top of the other VPN if absolutely necessary, but performance is not fast since my home connection is not fast.
>
> Haven't had occasion to try the Qubes tunnel. Is there a particular reason to?

Its good practice to use a Qubes-specific tool like qubes-tunnel to
ensure that DNS packets (and everything else) gets routed through the
tunnel and never _around_ it even when the link goes down. This is
important for Qubes because any service VM (NetVM or ProxyVM) that runs
VPN software is acting like a router, not a PC, and Qubes also has
special requirements for proper routing of DNS in this situation.

In your case the AppVM with OpenConnect acts like a PC endpoint and is
probably not a security issue. But the sys-net copy is acting like a
router as previously mentioned and that's an issue on Qubes; to improve
security you could move your openvpn config to a ProxyVM and use
qubes-tunnel.

There is also the issue of VPN passwords or keys being stored in a
sys-net type VM, since these VMs are considered vulnerable to attack.
Moving the VPN to a ProxyVM increases the security of your VPN secrets.

[Stuart Perkins]

I will try and get the qubes-tunnel to work, as this makes sense.

[Stuart Perkins]

Well, got the proxyVM created. Based it on Fedora-28. Have it squeezed between sys-firewall and sys-net. It runs automatically due to the dependency, but the vpn does not run automatically, which is what I want. I setup a shortcut to start the open vpn and another to kill it. It seems to work, but my ability to test it out is not complete right now. I'll know more after I test it some more tomorrow. That keeps my storage of VPN credentials away from sys-net, while still enabling sys-firewall. That is the part I need to test more fully. I have one appVM firewalled to only access my home system for backup purposes as well as other appVMs with full access. I'll do some serious testing tomorrow and report the results. I can synthesize being away from home by using my smartphone for internet. I will need to access my home network when connected to the VPN, which I ought to be able to, and a traceroute should go through my home system's DNS server. This may be the best solution for my need for now. It is better than the previous sys-net hosted openvpn instance. Thanks to Chris for the explanation as to why to use qubes-tunnel.

Stuart

[Chris Laprise]

On 09/26/2018 08:38 PM, Stuart Perkins wrote:
> Well, got the proxyVM created. Based it on Fedora-28. Have it squeezed between sys-firewall and sys-net. It runs automatically due to the dependency, but the vpn does not run automatically, which is what I want.

It should run openvpn automatically, unless there was a typo or a step
was skipped. You can check its log with 'sudo journalctl -u qubes-tunnel'.

I setup a shortcut to start the open vpn and another to kill it. It
seems to work, but my ability to test it out is not complete right now.
I'll know more after I test it some more tomorrow. That keeps my
storage of VPN credentials away from sys-net, while still enabling
sys-firewall. That is the part I need to test more fully. I have one
appVM firewalled to only access my home system for backup purposes as
well as other appVMs with full access. I'll do some serious testing
tomorrow and report the results. I can synthesize being away from home
by using my smartphone for internet. I will need to access my home
network when connected to the VPN, which I ought to be able to, and a
traceroute should go through my home system's DNS server. This may be
the best solution for my need for now. It is better than the previous
sys-net hosted openvpn instance. Thanks to Chris for the explanation as
to why to use qubes-tunnel.

There are two ways to access a LAN while connected to a VPN with
qubes-tunnel. One is to add exceptions to the ProxyVM internal iptables
rules, the other (recommended way) is to connect the particular VM
requiring LAN access to a clearnet VM such as sys-firewall (assuming you
have sys-firewall still connected directly to sys-net).

[Chris Laprise]

On 09/26/2018 08:38 PM, Stuart Perkins wrote:

> Well, got the proxyVM created. Based it on Fedora-28. Have it squeezed between sys-firewall and sys-net. It runs automatically due to the dependency, but the vpn does not run automatically, which is what I want. I setup a shortcut to start the open vpn and another to kill it. It seems to work, but my ability to test it out is not complete right now. I'll know more after I test it some more tomorrow. That keeps my storage of VPN credentials away from sys-net, while still enabling sys-firewall. That is the part I need to test more fully. I have one appVM firewalled to only access my home system for backup purposes as well as other appVMs with full access. I'll do some serious testing tomorrow and report the results. I can synthesize being away from home by using my smartphone for internet. I will need to access my home network when connected to the VPN, which I ought to be able to, and a traceroute should go through my home system's DNS server. This may be the best solution for my need for now. It is better than the previous sys-net hosted openvpn instance. Thanks to Chris for the explanation as to why to use qubes-tunnel.
>
> Stuart
>

FYI, I just posted a fix for a blocked traffic problem on Qubes 3.2 (4.0
is not affected).