On Wed, 26 Sep 2018 00:24:29 -0500
Stuart Perkins <perkins.stu...@gmail.com> wrote:
>On Tue, 25 Sep 2018 22:34:12 -0400
>Chris Laprise <tas...@posteo.net> wrote:
>
>>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-users@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.
>>
>
>I will try and get the qubes-tunnel to work, as this makes sense.
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
--
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/20180926193803.7eb70ee5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
