ANN: Testing new VPN code for Qubes

[Chris Laprise]

Hello fellow Qubes users:

Per issue 3503 the Qubes project would like to incorporate VPN features
from Qubes-vpn-support -- which a number of you are already using --
into the Qubes 4.1 release.

I've set up a new project "qubes-tunnel" to act as a staging area for
testing and eventual forking into Qubes. It is nearly the same as
Qubes-vpn-support except some names & paths are different... and install
to template is required for obvious reasons :) .


Project Link... https://github.com/tasket/qubes-tunnel


Everyone with an available VPN service is welcome to try this out and
report here on your results!

-

PS - Some of you will wonder if installing qubes-tunnel into an existing
template already used for Qubes-vpn-support will cause a conflict; They
will not conflict as long as the two services aren't enabled for the
same ProxyVM(s).

--

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

[JonHBit]

Worked well for me using a debian-9 template & commit 4e96ca8, only trouble was that my VPN provider's configs used /etc/update-resolv-conf and failed silently when it was missing - so shipping it with qubes-tunnel and installing it by default may be helpful.

[Chris Laprise]

Thanks!

This issue just became apparent to me when another user reported it. The
underlying problem is a bug (or several bugs) in openvpn's option parsing:

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

It only shows up when the config specifies its own scripts which is
rare. I'm trying out a workaround now which involves:

1. Removing the paths in the up & down options in the .service file.

2. Moving the up & down options to the beginning just after the openvpn
command.

3. Symlinking the up/down script from /usr/lib/qubes to the
/rw/config/qtunnel dir.

Hopefully this will override the config's up/down settings as intended.

[Chris Laprise]

I had to use a different approach but it should be fixed now. Update it
by copying new version to template and running installer. Then you'll
need to remove the 'qubes-tunnel' Qubes service for the proxyVM and add
'qubes-tunnel-openvpn' instead.

[john]

I installed this in a App/proxy 4.0 VM, as I am familiar with the 3.2
CLI VPN creation.

I don't really understand how installing it in a Template or The
Template(not cloning it 1st) would allow me to swich between
geolocations ...

So, I used the AppVM, then I simply cloned the 1st one created with
the script and went into the PIA config file area ....and did rm -f ln
-s to the network manager thing.

and then recreated the ln -s to a new config file, which works , and
Even wakes up from suspend (where in 3.2 it never did) ; However,

If the AppVM using one of the VPN-foo as a netvm, and it is started,
and I want to switch to another VPN-foo1 it doesn't work on the fly, I
have to go and qvm-shutdown the AppVM and open it again, which is a
big pain. I am often running out of RAM, and so try to just use one
App-proxy-vpnVM , however ,

is this the expected behavior no switching vpn appvms on the fly ?

[Chris Laprise]

IIRC this is a bug in the versions of Linux kernel that Qubes 4.0 uses.
There is an issue but I can't locate it at the moment.

[cicero]

On 04/19/18 14:04, Chris Laprise wrote:
> On 04/19/2018 07:26 PM, john wrote:
>> I installed this in a App/proxy 4.0 VM,  as I am familiar with the 3.2
>> CLI  VPN creation.
>>
>> I don't really understand how installing it in a Template or The
>> Template(not cloning it 1st)  would allow me to swich between
>> geolocations ...
>>
>> So, I used the AppVM,  then I simply  cloned the 1st one created with
>> the script and went into the PIA config file area ....and did rm -f ln
>> -s  to the network manager thing.
>>
>> and then recreated the ln -s  to a new config file,  which works , and
>> Even  wakes up  from  suspend  (where in 3.2 it never did) ;  However,
>>
>> If the AppVM using one of the VPN-foo as a netvm,  and it is started,
>> and I want to switch to another VPN-foo1  it doesn't work on the fly,
>> I have to go and qvm-shutdown the  AppVM and open it again,  which is
>> a big pain.    I am often running out of RAM, and so try to just use
>> one App-proxy-vpnVM , however ,
>>
>> is this the expected behavior  no switching vpn appvms on the fly ?
>
> IIRC this is a bug in the versions of Linux kernel that Qubes 4.0 uses.
> There is an issue but I can't locate it at the moment.
>
>

So, I guess I'll learn to live with it , and try not to change VPNs buy
buying some more expensive RAM :)

But, I'm curious , If I install the new script in the Template/s , how
would I switch VPN locations?

Or would every AppVM based on that Template be locked into whatever
geolocation's config file was symlinked to ?

[Chris Laprise]

Templates don't affect your ability to set a custom location script.
This is because the link that points from qtunnel.conf to any particular
config is stored in each proxyVM under /rw/config/qtunnel.

You can of course do one proxyVM setup, then clone it and change the
link in each clone.

BTW, thanks for trying it out!

[cicero]

Chris, what I'm trying to say is, if it is recommended to install it in
the Template or a cloned Template ; how then do I change the geolocation
to two different locations, one for each of , say, two AppVMs ?

I could create symlinks in /rw/config/qtunnel? in the AppVMs ? or


I understand that if this is integrated later, then I probably need to
learn to use it in the Template now, to avoid more issues down the road,
I don't really like cloning the Template too much, as Qubes, is already
a challenge in its complexity


eg: my current dracut emergency shell situation PS: seems I had an old
Q3.2 in an enclosure, I was going to reformat but hadn't yet, and during
a reboot it was in the USB drive, and this seems to have caused Q4.0 in
efi installation to dump it's init to boot ; so do I go make a
fedora live usb drive and try to mount and save it ? and lose all the
configuration and restoring of 3.2 VMs or just reinstall Q4.0?


I have read some folks on here , whom when trying to go back to Q3.2 are
having big issues, I don't really understand how efi works, my UEFI
still says Qubes 3.1 for some reason (I think there are some
gymnastics to try to get the EFI to update it's names but fear I'll lose
the windows 10 install on the 2nd HD, etc etc .....


Strangely windows 10 "just works", but I digress .....

[Chris Laprise]

Since there's no connection information in the template -- only the VPN
scripts & the OS are there -- templates don't affect configuration
issues like different locations. In any case, you have a proxyVM which
contains configurations for the connections to various sites, but each
proxyVM connects to only one VPN remote site at a time. So to have two
AppVMs routed through two different VPN sites, you need two proxyVMs
(one for each AppVM).

This is not an absolute rule BTW. Its just how our current tools are
most logically and safely configured. Conceivably you could rig a single
proxyVM to safely handle more than one VPN connection.

>
> I could create symlinks in /rw/config/qtunnel?   in the AppVMs  ?  or
>
>
> I understand that if this is integrated later, then I probably need to
> learn to use it in the Template now, to avoid more issues down the road,
> I don't really like cloning the Template too much, as Qubes, is already
> a challenge in its complexity

To clarify...

Cloning the template is recommended because the VPN software is still
being tested. Its just a way to backup in case something in the modified
template gets damaged.

Cloning a proxyVM is a quick way to make additional VPN VMs that can
connect to different VPN sites.

>
>
> eg: my current dracut emergency shell situation PS: seems I had an old
> Q3.2 in an enclosure, I was going to reformat but hadn't yet, and during
> a reboot it was in the USB drive, and this seems to have caused  Q4.0 in
> efi installation  to dump  it's  init   to boot  ; so do I go make a
> fedora live usb drive and try to mount and save it ?   and lose all the
> configuration and restoring of 3.2 VMs   or just reinstall Q4.0?

Boot issues aren't my strong suit, but this sounds serious enough to
start a separate thread for it.

>
>
> I have read some folks on here , whom when trying to go back to Q3.2 are
> having big issues, I don't really understand how efi works,  my UEFI
> still  says  Qubes 3.1 for some reason (I think there are some
> gymnastics to try to get the EFI to update it's names but fear I'll lose
> the windows 10 install on the 2nd HD,  etc etc .....
>
>
> Strangely windows 10 "just works", but I digress .....
>

[cicero]

On 04/20/18 04:58, Chris Laprise wrote:
> Since there's no connection information in the template -- only the VPN
> scripts & the OS are there -- templates don't affect configuration
> issues like different locations. In any case, you have a proxyVM which
> contains configurations for the connections to various sites, but each
> proxyVM connects to only one VPN remote site at a time. So to have two
> AppVMs routed through two different VPN sites, you need two proxyVMs
> (one for each AppVM).

hmm, so I guess by installing the script in the Template(cloned), it
would save me from having to re-run the script in the AppProxyVMs,
that's it ?

But, if I'm just cloning the Original AppProxyVMs , to make a 2nd
geolocation, doesn't seem like saves me any work by not having to
re-run the script, as it is already in the cloned AppProxyVM ?

Do I have this correct?


But, sometime in the future, a possible newer version will only run in a
Template, but then the rest is about the same on configuration, ( a
separate AppProxyVM for each location wanted , unless one wanted to
manually change the symlink to change locations ?

[Chris Laprise]

On 04/20/2018 11:14 AM, cicero wrote:
> On 04/20/18 04:58, Chris Laprise wrote:
>> Since there's no connection information in the template -- only the
>> VPN scripts & the OS are there -- templates don't affect configuration
>> issues like different locations. In any case, you have a proxyVM which
>> contains configurations for the connections to various sites, but each
>> proxyVM connects to only one VPN remote site at a time. So to have two
>> AppVMs routed through two different VPN sites, you need two proxyVMs
>> (one for each AppVM).
>
> hmm, so I guess by installing the script in the Template(cloned), it
> would save me from having to re-run the script in the AppProxyVMs,
> that's it ?

You wouldn't have to install it into proxyVMs. But there is still one
script-running step when configuring a proxyVM with qubes-tunnel.

https://github.com/tasket/qubes-tunnel

>
> But, if I'm just cloning the Original AppProxyVMs , to make a 2nd
> geolocation,  doesn't seem like  saves me any work  by  not having to
> re-run the script, as it is already in the cloned AppProxyVM  ?

If you clone an already configured proxyVM, no further configuration is
required for the clone to connect to the same site. To change the site,
you will only need to change the qtunnel.conf link.

>
> Do I have this correct?
>
>
> But, sometime in the future, a possible newer version will only run in a
> Template, but then the rest is about the same on configuration, ( a
> separate AppProxyVM for each location wanted , unless one wanted to
> manually change the symlink to change locations ?

That's the intention, to make qubes-tunnel (child of Qubes-vpn-support)
already available for use in the templates. This simplifies the setup
process for users.

[JonHBit]

Hi Chris,

Good to see the update!

However I think that's a separate issue; what I'm referencing is these lines in my .ovpn config:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

The VPN installer script will normally download this if it's missing - used to change the DNS server to the VPN-provided one.

The script is here: https://raw.githubusercontent.com/ProtonVPN/scripts/master/update-resolv-conf.sh

After adding it everything worked well.

[Chris Laprise]

The update will replace those lines because they should be overridden
with the Qubes-specific DNS handling. If dnat isn't setup for DNS then
those packets could get mis-routed.

You can check the dnat rules (which should have some address other than
10.139.1.x after connecting) with this:

sudo iptables -v -t nat -L PR-QBS

My guess why it might work with incorrect dnat addresses is that your
VPN provider takes the step of re-assigning DNS destination addresses to
its own. But this is unorthodox so I wouldn't count on it.

[vel...@tutamail.com]

Chris/Tasket,
I am currently using this version: https://github.com/tasket/Qubes-vpn-support

"Master version"

I have this running in a proxy AppVM (Not in a template)

Using PIA VPN service

OpenDNS checks out OK

I just tried this version in 4.0 in the template. Some notes feedback:

1) When I tried changing the DNS to OpenDNS in my config file:
setenv vpn_dns '208.67.222.222 208.67.220.220'

I then went to:
http://welcome.opendns.com/

It failed and informed me I was not using OpenDNS.

2) The step 3. in the abbreviated instructions say to run:
/usr/lib/qubes/qtunnel-setup --config

However I had to run:
sudo /usr/lib/qubes/qtunnel-setup --config

I was able to get to the internet....I didn't do any further testing. If you want me to try some things more then happy to help...

Thanks again for the work.

V

[vel...@tutamail.com]

Using debian 9, link indicates "Link is up", I get internet connection, https://www.dnsleaktest.com/ indicates my VPNs IP(despite "setenv vpn_dns '208.67.222.222 208.67.220.220'" in my vpn configuration) when I use this configuration...

V

[Chris Laprise]

On 04/29/2018 10:14 PM, vel...@tutamail.com wrote:
> I just tried this version in 4.0 in the template. Some notes feedback:
>
> 1) When I tried changing the DNS to OpenDNS in my config file:
> setenv vpn_dns '208.67.222.222 208.67.220.220'
>
>
> I then went to:
> http://welcome.opendns.com/
>
> It failed and informed me I was not using OpenDNS.

--

> Using debian 9, link indicates "Link is up", I get internet connection, https://www.dnsleaktest.com/ indicates my VPNs IP(despite "setenv vpn_dns '208.67.222.222 208.67.220.220'" in my vpn configuration) when I use this configuration...

Its working when I try it. On dnsleaktest.com, your VPN provider IP
should always appear on the first page. Then when you click on a test
button it should show "OpenDNS, LLC" in the ISP column. The OpenDNS
addresses will also show up in the log alongside "Using DNS servers...".

The problem is you're mixing instructions from the two different
projects. This thread is for testing qubes-tunnel but you said you were
using Qubes-vpn-support (...but said you were using qtunnel* commands
which belong to qubes-tunnel and are not correct for Qubes-vpn-support).

If using 'qubes-tunnel-openvpn' service for your VPN VM, your configs
should reside in /rw/config/qtunnel and the setenv line that you add
will be:

setenv tunnel_dns '208.67.222.222 208.67.220.220'

-

It would be nice, however, if you made the switch to qubes-tunnel to
give us some testing feedback. :)

[vel...@tutamail.com]

Adding this to my config:
setenv tunnel_dns '208.67.222.222 208.67.220.220'

instead of:
setenv vpn_dns '208.67.222.222 208.67.220.220'

worked.

Both http://welcome.opendns.com/ and https://www.dnsleaktest.com/ show that OpenDNS are being used.

I am more then happy to help test, I was planning to make the shift but my DNS wasn't working...all good now. Thanks for the help...

I'll move my sys-VPNs to this new project...I was just reluctant to make the move as my DNS was not showing correct. All good now!

Thanks again...if anything comes up I'll report back. If you want me to try something more then happy to help...

Thx

[vel...@tutamail.com]

Here are my notes/instructions I made based on yours, I drag and drop some files into terminal(vs purely command lines):

Using qTunnel:

For Debian proxy, add OpenVPN package to your VPN template:
su
apt-get update && apt-get install openvpn unzip

Download and transfer file to template
https://github.com/tasket/qubes-tunnel.git

cd “Then drag downloaded file into terminal from tasket”
sudo bash ./install

Create proxy AppVM using VPN template: sys-VPN
Colour: Green
Provides Network Checked
connect to sys-net
Launch settings - Checked

Settings:
Add files and Terminal to Applications
Add “qubes-tunnel-openvpn” to services

Move VPN config files to new proxy AppVM

Open proxy AppVM terminal:
sudo mkdir /rw/config/qtunnel

sudo /usr/lib/qubes/qtunnel-setup --config

Enter VPN name and password

sudo mv “Then highlight the .pem, .crt and config file (renamed to “openvpn-client.ovpn)” /rw/config/qtunnel

Optional - Change config DNS:
setenv tunnel_dns '208.67.222.222 208.67.220.220'

cd /rw/config/qtunnel
sudo ln -s xx.ovpn qtunnel.conf
(xx is the VPN client config)

Restart AppVM...look for “Links is up” pop-up

https://github.com/tasket/qubes-tunnel

[vel...@tutamail.com]

Sorry correction to my notes:

Using qTunnel:

For Debian proxy, add OpenVPN package to your VPN template:
su
apt-get update && apt-get install openvpn unzip

Download and transfer file to template
https://github.com/tasket/qubes-tunnel.git

cd “Then drag downloaded file into terminal from tasket”
sudo bash ./install

Create proxy AppVM using VPN template: sys-VPN
Colour: Green
Provides Network Checked
connect to sys-net
Launch settings - Checked

Settings:
Add files and Terminal to Applications
Add “qubes-tunnel-openvpn” to services

Move VPN config files to new proxy AppVM

Open proxy AppVM terminal:
sudo mkdir /rw/config/qtunnel

sudo /usr/lib/qubes/qtunnel-setup --config

Enter VPN name and password

sudo mv “Then highlight the .pem, .crt and config file (renamed to xx.ovpn)” /rw/config/qtunnel

[vel...@tutamail.com]

Strangest thing, I did a fresh installation of Qubes and now I can't get this to work again?

Sorry for the basic question but is there something I need to do to the fresh debian template after installation?

I am trying to eliminate all possible issues but to install OpenVPN to the debian template:

1) I simply allow access to TOR or a network to get OpneVPN
2) Type : sudo apt-get install openvpn

I am having the same issue with Fedora as well, could there be another reason for this not connecting?

I get the "Waiting for connection" message but I don't get the "Link is up"...

Thanks for any thoughts...

V

[morlan...@gmail.com]

On Tuesday, April 17, 2018 at 2:13:29 PM UTC-7, Chris Laprise wrote:

Worked great for me with Qubes 4.0 and Fedora 26.

I'm unclear on how to use sys-firewall now though. Should it be sys-net -> sys-firewall -> VPN -> App?

Thanks.

[john]

you seem to be confusing things.

1)
can you update your templates otherwise?

2)
sudo apt-get install openvpn should have nothing to do with the later
step of install the tasket scrip-let ..... (not the tunnel) just
the VPN script on GitHub

3)
if you Not talking about the "tunnel" script just the VPN tasket
script, why not leave the Template out of the equation and just
install the script in a fresh App-ProxyVM that "allows networking"
(proxy)


and just leave Tor out of the whole puzzle IMO

[vel...@tutamail.com]

>
> 1)
> can you update your templates otherwise?

Yes I can update my templates

> 2)
> sudo apt-get install openvpn should have nothing to do with the later
> step of install the tasket scrip-let ..... (not the tunnel) just
> the VPN script on GitHub

I was just hoping to make sure I haven't missed a basic step. It is my understanding the stock Debian-9 template that comes with 4.0 does not have OpenVPN installed. "sudo apt-get install openvpn" is all thats needed? Is there additional commands to install any dependencies?

> 3)
> if you Not talking about the "tunnel" script just the VPN tasket
> script, why not leave the Template out of the equation and just
> install the script in a fresh App-ProxyVM that "allows networking"
> (proxy)

Whats strange is I had the "Tunnel" script working prior to my fresh 4.0 install. The "VPN Tasket" also worked but moved to the "Tunnel" prior to my fresh install.

I tried going back to the "App-ProxyVM" only(i.e. no template configuration) but it too didn't work....

>
> and just leave Tor out of the whole puzzle IMO

I'll try with out TOR to see if that changes anything...

Thanks,
V

(Morlan - I used to connect my VPN proxy via sys-net -> VPN -> AppVM when I had this running...I would defer to other more seasoned Q users but consider multiple VPNs configured for different IPs, TOR over VPN...my thought was VPN thru sys-firewall consumed resources and wasn't sure it provided additional security...I would be open to being corrected if that is wrong)

[dangm...@gmail.com]

On Tuesday, April 17, 2018 at 2:13:29 PM UTC-7, Chris Laprise wrote:

I can get my browser to connect in the ProxyVM only after I manually change /etc/resolv.conf to NordVPN DNS servers.

But nothing that uses the ProxyVM as a NetVM can access the internet in any way. Cannot ping 8.8.8.8. Can't do anything. Doesn't matter what I do to /etc/resolv.conf in the AppVM.

[get]

среда, 18 апреля 2018 г., 0:13:29 UTC+3 пользователь Chris Laprise написал:

Hi. script not working more on debian-9/fedora-26. Please fix it.

Tested vpn's : mullvad, privateinternetaccess, expressvpn and multiple random openvpn.

Guides:
https://github.com/tasket/Qubes-vpn-support
https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service
https://github.com/tasket/qubes-tunnel

[dangm...@gmail.com]

Instructions also make no sense.


1. Copy to template

2. Copy to template VM

[JonHBit]

I've updating to 1.4beta4 and switched templates from debian-9 to fedora-28, but I'm getting the same error - also it seems like openvpn flag defaults changed, as it now returns an error for the up and down arguments

Specifically, it parses /usr/lib/qubes/qtunnel-connect up as 2 arguments instead of 1; putting the whole phrase in double quotes fixes this, which I see you did but for some reason the quotes seem to be removed when ExecStart runs, i.e. checking systemctl status qubes-tunnel shows the command without the quotes

[Chris Laprise]

On 05/12/2018 03:11 PM, JonHBit wrote:

> I've updating to 1.4beta4 and switched templates from debian-9 to fedora-28, but I'm getting the same error - also it seems like openvpn flag defaults changed, as it now returns an error for the up and down arguments

Did you mean fedora-26?

> Specifically, it parses /usr/lib/qubes/qtunnel-connect up as 2 arguments instead of 1; putting the whole phrase in double quotes fixes this, which I see you did but for some reason the quotes seem to be removed when ExecStart runs, i.e. checking systemctl status qubes-tunnel shows the command without the quotes

I'm a little unclear: Did you get the link working like this?

I have two fedora 26 templates, one was last updated over 10 days ago
and the other updated today. The VPN link won't come up with the latter
one...

[Chris Laprise]

On 05/06/2018 05:24 PM, morlan...@gmail.com wrote:
> Worked great for me with Qubes 4.0 and Fedora 26.
>
> I'm unclear on how to use sys-firewall now though. Should it be sys-net -> sys-firewall -> VPN -> App?
>
> Thanks.

That arrangement is OK. But you can take sys-firewall out of the path
(connect VPN directly to sys-net) because a VPN qube configured with
qubes-tunnel still does the job of a regular proxy qube (like sys-firewall).

[Chris Laprise]

On 05/14/2018 09:09 AM, Chris Laprise wrote:
> On 05/12/2018 03:11 PM, JonHBit wrote:
>
>> I've updating to 1.4beta4 and switched templates from debian-9 to
>> fedora-28, but I'm getting the same error - also it seems like openvpn
>> flag defaults changed, as it now returns an error for the up and down
>> arguments
>
> Did you mean fedora-26?
>
>
>> Specifically, it parses /usr/lib/qubes/qtunnel-connect up as 2
>> arguments instead of 1; putting the whole phrase in double quotes
>> fixes this, which I see you did but for some reason the quotes seem to
>> be removed when ExecStart runs, i.e. checking systemctl status
>> qubes-tunnel shows the command without the quotes
>
> I'm a little unclear: Did you get the link working like this?
>
> I have two fedora 26 templates, one was last updated over 10 days ago
> and the other updated today. The VPN link won't come up with the latter
> one...
>

I did some tests and there seems to be an intermittent problem with
qubes-firewall on fedora only. This can prevent openvpn from connecting.

[Chris Laprise]

On 05/12/2018 01:54 PM, dangm...@gmail.com wrote:
> I can get my browser to connect in the ProxyVM only after I manually change /etc/resolv.conf to NordVPN DNS servers.

This is as intended: local proxyVM programs running but not using the
tunnel.

You wouldn't normally use a browser in the proxyVM.

> But nothing that uses the ProxyVM as a NetVM can access the internet in any way. Cannot ping 8.8.8.8. Can't do anything. Doesn't matter what I do to /etc/resolv.conf in the AppVM.

Can you look at the log with 'sudo journalctl -u qubes-tunnel'? Does it
say "Initialization sequence completed" or an error message?

Also what is the output of 'sudo iptables -v -L PR-QBS -t nat'?

[Chris Laprise]

On 05/12/2018 02:10 PM, get wrote:
> Hi. script not working more on debian-9/fedora-26. Please fix it.
>
> Tested vpn's : mullvad, privateinternetaccess, expressvpn and multiple random openvpn.
>
> Guides:
> https://github.com/tasket/Qubes-vpn-support
> https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service
> https://github.com/tasket/qubes-tunnel

This thread is for qubes-tunnel not Qubes-vpn-support.

Also I can't read minds... Can you describe a specific example with one VPN?

[pietr...@gmail.com]

On Monday, May 14, 2018 at 9:45:04 PM UTC+2, Chris Laprise wrote:
> On 05/12/2018 01:54 PM, dangm...@gmail.com wrote:
> > I can get my browser to connect in the ProxyVM only after I manually change /etc/resolv.conf to NordVPN DNS servers.
>
> This is as intended: local proxyVM programs running but not using the
> tunnel.
>
> You wouldn't normally use a browser in the proxyVM.
>
>
> > But nothing that uses the ProxyVM as a NetVM can access the internet in any way. Cannot ping 8.8.8.8. Can't do anything. Doesn't matter what I do to /etc/resolv.conf in the AppVM.
>
> Can you look at the log with 'sudo journalctl -u qubes-tunnel'? Does it
> say "Initialization sequence completed" or an error message?
>
> Also what is the output of 'sudo iptables -v -L PR-QBS -t nat'?

Hi Chris,
thanks for your effort behind qubes-tunnel. I tried recent version and have similar issues. Namely I would like to reach clearnet from my VM which is behind ProxyVM. My VPN leads to company network (which can be reached without problems), what is useful for devices which are there, but there is no separate DNS for it.

'sudo journalctl -u qubes-tunnel' looks fine - no errors. ipables look like that:

Chain PR-QBS (1 references)
pkts bytes target prot opt in out source destination
78 5206 DNAT udp -- vif+ any anywhere 10.139.1.1 udp dpt:domain to:8.8.8.8
0 0 DNAT tcp -- vif+ any anywhere 10.139.1.1 tcp dpt:domain to:8.8.8.8
64 4338 DNAT udp -- vif+ any anywhere anywhere udp dpt:domain to:8.8.4.4
0 0 DNAT tcp -- vif+ any anywhere anywhere tcp dpt:domain to:8.8.4.4

/etc/resolv.conf:
nameserver 10.139.1.1
nameserver 10.139.1.2

BTW do you think it makes sense to move setup stuff and do that using salt? - I made some basic sls files with your setup now purely reproducing your instructions.

[Chris Laprise]

On 07/14/2018 07:30 PM, pietr...@gmail.com wrote:
> Hi Chris,
> thanks for your effort behind qubes-tunnel. I tried recent version and have similar issues. Namely I would like to reach clearnet from my VM which is behind ProxyVM. My VPN leads to company network (which can be reached without problems), what is useful for devices which are there, but there is no separate DNS for it.
>
> 'sudo journalctl -u qubes-tunnel' looks fine - no errors. ipables look like that:
>
> Chain PR-QBS (1 references)
> pkts bytes target prot opt in out source destination
> 78 5206 DNAT udp -- vif+ any anywhere 10.139.1.1 udp dpt:domain to:8.8.8.8
> 0 0 DNAT tcp -- vif+ any anywhere 10.139.1.1 tcp dpt:domain to:8.8.8.8
> 64 4338 DNAT udp -- vif+ any anywhere anywhere udp dpt:domain to:8.8.4.4
> 0 0 DNAT tcp -- vif+ any anywhere anywhere tcp dpt:domain to:8.8.4.4
>
> /etc/resolv.conf:
> nameserver 10.139.1.1
> nameserver 10.139.1.2

By default qubes-tunnel relies on the routing configuration supplied by
the VPN provider -- in this case, your corporate server setup by your IT
staff. Their preferences in routing will affect how and whether packets
will get routed.

The first thing I'd look for is whether they are pushing a
'redirect-gateway def1' directive to your client... you can see this in
the journalctl log. Alternately, it might be included in your conf file.
If there is no such redirect-gateway directive you can add it to your
conf file (it won't take effect until you restart the qubes-tunnel service).

If that doesn't help you can try troubleshooting the VPN link with no
frills: disable the firewall script and qubes-tunnel service, reboot
proxyVM, cd /rw/config/qtunnel and then run 'sudo openvpn --config
qtunnel.conf -up /etc/openvpn/update-resolv-conf'.

This sets up DNS _locally_ for a Debian proxyVM. For Fedora try '-up
/usr/share/doc/openvpn/contrib/pull-resolv-conf/client.up' instead.

After connecting use 'traceroute' with known IP addresses and domain
names to determine if the link is working as expected.

>
> BTW do you think it makes sense to move setup stuff and do that using salt? - I made some basic sls files with your setup now purely reproducing your instructions.

Sounds interesting, I would like to see it sometime!

[Piotr Król]

On 07/17/2018 01:40 AM, Chris Laprise wrote:
> On 07/14/2018 07:30 PM, pietr...@gmail.com wrote:

(...)

That is the option I needed. After adding it to my conf file I have
access to both Internet and devices behind VPN.

>>
>> BTW do you think it makes sense to move setup stuff and do that using
>> salt? - I made some basic sls files with your setup now purely
>> reproducing your instructions.
>
> Sounds interesting, I would like to see it sometime!

I will try to pack that in consumable form and publish on github. BTW it
would be great if QubesOS would have some better guidance how to extend
standard salt stuff with custom modifications. At this point I'm just
dropping symbolic links to /srv/salt, enable top and run highstate. If
anyone have reusable example it would help a lot.

I assume some salt stuff should be developed if you plan to include
qubes-tunnel as default component in QubesOS.

Best Regards,
Piotr Król

[sm...@tutamail.com]

Just got this going, awesome Tasket. Thank you again Qubes team for what you do!

Works like a charm...the only feedback is the newly updated "Qubes Manager" is sometimes "buggy" with the VPNApVM. I don't believe it impacts performance.

Some notes:
-Qubes 4.0
-Worked in Fedora28 and Debian9 template/Proxy VM
-Changed the DNS to use Quad9 and it worked
-Using PIA, utilizing the OpenVPN-IP files (haven't tried the other PIA configs from their site)
- I needed to install Nautilus and OpenVPN for Debian9 (using my instructions below)

I really struggled setting this up, but below are the steps/notes I followed in combination with the instructions on Github, the order to set this up does matter...hope this helps others out(open to feedback):

Instructions for the "terminal" challenged:

Using qTunnel: https://github.com/tasket/qubes-tunnel

In a Template do this:
For Debian proxy, add OpenVPN package to your VPN template(Fedora already has OpenVPN included):
su
apt-get install openvpn

Download and transfer file to VPN template:
https://github.com/tasket/qubes-tunnel.git

cd “Then drag downloaded, unzipped file into terminal from tasket”
sudo bash ./install

sudo mkdir /rw/config/qtunnel

Close Template.

Create a proxy VM:

Create proxy AppVM using VPN template: sys-VPN
Colour: Green
Provides Network Checked

connect to sys-net (or firewall)

Launch settings - Checked

Settings:

Add “Files” and “Terminal” to “Applications” in ProxyVM
Add “qubes-tunnel-openvpn” to services, hit the +

Optional - Change config DNS(Quad9 DNS), by adding the text below to the VPN config file, then hit save:
setenv tunnel_dns '9.9.9.9 149.112.112.112’'

In terminal move VPN config files to new proxy AppVM:
sudo mv “Then highlight the VPN folder and drag to terminal” /rw/config/qtunnel

cd /rw/config/qtunnel
sudo ln -s xx.ovpn qtunnel.conf
(xx is the VPN client config)

sudo /usr/lib/qubes/qtunnel-setup --config
Enter VPN name and password

exit

Restart AppVM...look for “Links is up” pop-up

(Sorry if this is Top posting!)

[22...@tutamail.com]

Everything has been working fine, however recently my VPN tunnel is failing?

I ran: sudo journalctl -u qubes-tunnel

and I get:

Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 All connections have been connect-retry-max (7) times unsuccessful, e
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 Exiting due to fatal error
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Main process exited, code=exited, status=1/FAILURE
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1149]: STOP-ing network forwarding!
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Unit entered failed state.
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Failed with result 'exit-code'.

Some additional notes:
My connection works on other devices
My TOR is not connecting
I am able to get Internet access via non-VPN connection
I did update Dom0 and my templates but it worked shortly afterwards

Any ideas how to trouble shoot this?

Thanks for any help...

[22...@tutamail.com]

Correction....my TOR is working. Any ideas how to trouble shoot?

Everything has been working fine, however recently my VPN tunnel is failing?

I ran: sudo journalctl -u qubes-tunnel

and I get:

Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 All connections have been connect-retry-max (7) times unsuccessful, e
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1138]: Wed Sep 5 10:17:48 2018 Exiting due to fatal error
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Main process exited, code=exited, status=1/FAILURE
Sep 05 10:17:48 VPN-Mid qtunnel-setup[1149]: STOP-ing network forwarding!
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Unit entered failed state.
Sep 05 10:17:48 VPN-Mid systemd[1]: qubes-tunnel.service: Failed with result 'exit-code'.

Some additional notes:
My connection works on other devices

[Chris Laprise]

Did you reboot the computer after the updates? What kind of template is
the VPN VM using?

Perhaps your other devices use non-openvpn protocols, and the VPN
service's openvpn server has gone offline?

You can try to make the connection manually, like this:

sudo systemctl stop qubes-tunnel
sudo iptables -P OUTPUT ACCEPT
cd /rw/config/qtunnel
sudo openvpn --config qtunnel.conf --verb 3

This will show a lot of detail in the terminal. A successful connection
will show "Initialization sequence completed" at the end.

[John S.Recdep]

I know this isn't your question but, have you tried the script in an
appvm/qube instead of the "tunnel" version ?

That is what I use fwiw

[22...@tutamail.com]

It appears as if I am getting a TLS error? Why would this suddenly start?

Wed Sep 5 17:23:39 2018 TLS Error: TLS handshake failed
Wed Sep 5 17:23:39 2018 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 5 17:23:39 2018 Restart pause, 5 second(s)
Wed Sep 5 17:23:44 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xx:port xxx

I have restarted the computer, I am using Qubes 4.0 and leveraging a Debian 9 template.

The other devices are using OpenVPN...

Any ideas?

John,
Not sure what " script in an appvm/qube instead of the "tunnel" version ?" is...I had tried to set up the "iptables and CLI scripts" https://www.qubes-os.org/doc/vpn/ but really struggled. I found the Tasket solution easier to set up for a relative novice in desperate need of VPN security. I am also able to setup a few configurations so I can use different destinations. Is this the version you are using?

[Chris Laprise]

On 09/06/2018 10:22 AM, 22...@tutamail.com wrote:
> It appears as if I am getting a TLS error? Why would this suddenly start?
>
> Wed Sep 5 17:23:39 2018 TLS Error: TLS handshake failed
> Wed Sep 5 17:23:39 2018 SIGUSR1[soft,tls-error] received, process restarting
> Wed Sep 5 17:23:39 2018 Restart pause, 5 second(s)
> Wed Sep 5 17:23:44 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xx:port xxx
>
> I have restarted the computer, I am using Qubes 4.0 and leveraging a Debian 9 template.
>
> The other devices are using OpenVPN...
>
> Any ideas?

When I search on the TLS error I get results like this:
https://serverfault.com/questions/709860/fix-tls-error-tls-handshake-failed-on-openvpn-client#765205

Specifying 'local' may be worth a try.

It sounds like something has gone wrong with the virtual devices or the
Qubes firewall for that VM... perhaps triggered by the system update.

I'm also using Debian 9 on Qubes 4. dom0 is updated with
security-testing enabled. Check your kernel version, mine is 4.14.67-1.

Testing basic connectivity for the VM can be done by first disabling the
tunnel firewall rules... delete the link at
/rw/config/qubes-firewall.d/90_tunnel-restrict. Then restart VM and use
ping/traceroute.

>
> John,
> Not sure what " script in an appvm/qube instead of the "tunnel" version ?" is...I had tried to set up the "iptables and CLI scripts" https://www.qubes-os.org/doc/vpn/ but really struggled. I found the Tasket solution easier to set up for a relative novice in desperate need of VPN security. I am also able to setup a few configurations so I can use different destinations. Is this the version you are using?

You can think of the vpn doc as a much older version of qubes-tunnel. I
doubt switching to it would help.

[John S.Recdep]

Sorry by "script" I meant "Qubes-vpn-support"
https://github.com/tasket

vs. "qubes-tunnel"


btw, it's a bit hard to tell your the OP ? Mr. 22rip ?

you installed qubes-tunnel in a Debian Template and it was working ,
now it is not


PS: tasket doesn't think trying "Qubes-vpn-support" in an AppVM will
make any difference, I noted .... goodluck

[22...@tutamail.com]

Thank you both for your responses...fair question John but I am the OP, lost access to my old tutamail. Yes my VPN was working fine for a few months however with a recent update it broke?? Its a little concerning because I did both a Debian and Dom0 update. When trying to update Dom0 I was not able to update it via Tor or VPN via Qubes??

I managed to confirm my VPN is spawning out in an attempt to connect but the TLS is still not working...I tried it on 3 different networks.

I know you can modify the DNS resolver by adding the following to the OpenVPN configuration:

setenv tunnel_dns '8.8.8.8'

But what would I add to "Specifying 'local'" in the OpenVPN configuration?

Thanks again for any help...

[Chris Laprise]

IIRC you only need to specify the IP address of a regular system
interface, which in this case is eth0. So do a 'sudo ip addr' and look
up the eth0 'inet' address and put 'local <address>' in the config.
There's a chance this might work.

If it doesn't work, and you know of no custom firewall rules or net
settings that you can check or remove, then I'd consider the following
possibilities:

1. Your VPN provider has changed their TLS certificate or other
connection parameters. In this case their special client software (e.g.
installed on other devices?) would automatically refresh the config
files while your Qubes config would remain stale and unable to complete
TLS verification of the remote.

Remedy for this is to download your provider's current openvpn configs
and put them in /rw/config/qtunnel (making sure that qtunnel.conf points
to a new config file).

2. Some residual network property of your VPN VM has triggered a bug
that prevents it from working correctly. Simple remedy would be to
create and setup a new proxyVM and use that instead.

3. Unlikely: Interference from malware, possibly residing in sys-net.

[22...@tutamail.com]

Thanks again for the help Chris...see my notes below:

IIRC you only need to specify the IP address of a regular system
interface, which in this case is eth0. So do a 'sudo ip addr' and look
up the eth0 'inet' address and put 'local <address>' in the config.
There's a chance this might work.

- Unfortunately this didn't work, I entered the following:

local 10.137.5.3

I was also able to find the IP in the Qubes Manager as an FYI, however I also ran the command in a terminal.

If it doesn't work, and you know of no custom firewall rules or net
settings that you can check or remove, then I'd consider the following
possibilities:

1. Your VPN provider has changed their TLS certificate or other
connection parameters. In this case their special client software (e.g.
installed on other devices?) would automatically refresh the config
files while your Qubes config would remain stale and unable to complete
TLS verification of the remote.

Remedy for this is to download your provider's current openvpn configs
and put them in /rw/config/qtunnel (making sure that qtunnel.conf points
to a new config file).

- It doesn't look like my VPN changed their TLS cert, downloaded a new config file and tried again fresh.

2. Some residual network property of your VPN VM has triggered a bug
that prevents it from working correctly. Simple remedy would be to
create and setup a new proxyVM and use that instead.

- I built a new VPN template with a new AppVM, I get the notification pop up but no connection.

3. Unlikely: Interference from malware, possibly residing in sys-net.

- I built a new sys-net (by creating a new Qube, provide network access, attached my Network controller/wireless....not sure more is needed to setup a sys-net) but this didn't fix it.

Whats strange is that the connection is showing up as allowed in my firewall log, which makes me think everything is working with the Tasket solution. I did notice a strange connection to port 137 (NetBIOS) in my firewall which could be related or the cause. I also recently saw an ssh attempt from within Qubes.

Unfortunately I have been under constant attack and a target and the only solution I see is a fresh rebuild or new computer unless you have another idea?

Thanks again Chris and Qubes for what you are doing...

[Anac]

On 09/14/2018 12:13 AM, 22...@tutamail.com wrote:
> Unfortunately I have been under constant attack and a target and the only solution I see is a fresh rebuild or new computer unless you have another idea?
>

You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that?

[Chris Laprise]

On 09/13/2018 08:00 PM, Anac wrote:
>
>
> On 09/14/2018 12:13 AM, 22...@tutamail.com wrote:
>> Unfortunately I have been under constant attack and a target and the
>> only solution I see is a fresh rebuild or new computer unless you have
>> another idea?
>>

https://github.com/tasket/qubes-doc/blob/tunnel/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-the-qubes-tunnel-service

Step 3 of the revised doc is probably the most effective test you can
perform... its basically starting fresh with (at that point) no scripts
added. Its just openvpn + the config. If that doesn't work then you may
be right that something in Qubes itself has become broken and maybe a
reinstall is necessary.

Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template.

>
> You said that Tor was running. When combining Tor with VPN, the VPN's
> connection type should be TCP, not UDP. Did you check that?

When connecting to VPN through TOR, TCP is required but depending on
your provider's server config you may also have to change the port number.

[22...@tutamail.com]

Thank you Anac and Chris, appreciate your suggestions:

You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that?

I did check this...opened the connection to Any/Any but this didn't seem to be the issue. I also eliminated TOR for testing and connected directly to the sys-net(to also eliminate any sys-firewall potential issues)

Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template.

I tried with fedora-28 but also had the same TLS connection error. I ran the tests in step 3 as suggested and recieved the following errors with both the Debian and Fedora setup:

Fri Sep 14 10:30:53 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Sep 14 10:30:53 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08
Enter Auth Username: My user name
Enter Auth Password: **************
Fri Sep 14 10:32:34 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]208.167.254.76:1198
Fri Sep 14 10:32:34 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 10:32:34 2018 UDP link local: (not bound)
Fri Sep 14 10:32:34 2018 UDP link remote: [AF_INET]208.x.x.x:port xx
Fri Sep 14 10:32:34 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:36 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:40 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:48 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:04 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:34 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 14 10:33:34 2018 TLS Error: TLS handshake failed
Fri Sep 14 10:33:34 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 10:33:34 2018 Restart pause, 5 second(s)

Definitely strange considering it was working great for a few months...the good news is the kill switch functionality with this solution worked.

Any insight with the errors I recieved? If not I think a reinstall is my best course...

[Chris Laprise]

You would normally get operation not permitted if the internal firewall
script is in effect, which is why this step comes before any scripts are
added (i.e. its performed in a fresh VM).

You can either disable the firewall script in
/rw/config/qubes-firewall.d and reboot, or try the test in a new VM
connected to sys-net.

[22...@tutamail.com]

Thanks Chris...I understand now. I just tried it again and below are my logs, while I don't get the "Operation not permitted (code=1)" error I still get the TLS error????

Fri Sep 14 16:55:06 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.08

Enter Auth Username: My username
Enter Auth Password: **********

Fri Sep 14 16:55:35 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]208.X.x.x ; port xx
Fri Sep 14 16:55:35 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 16:55:35 2018 UDP link local: (not bound)
Fri Sep 14 16:55:35 2018 UDP link remote: [AF_INET]208.x.x.x: port xx
Fri Sep 14 16:56:36 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 14 16:56:36 2018 TLS Error: TLS handshake failed
Fri Sep 14 16:56:36 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 16:56:36 2018 Restart pause, 5 second(s)

[Anac]

Looks like the connection type is still set as UDP in your OpenVPN
configuration file (.ovpn or .conf). Did you try to set it to TCP and
according ports?