Qubes: Unable to connect to VPN

[Crypto Carabao Group]

We've also been trying for days to get a VPN to  resolve on a brand new R4.0 install, to either one of 2 different VPN providers, using the iptables and cli scripts:

https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

I've also set it up before on a 3.x cubes and it worked using the above.

So far, what's pretty certain is that these instructions were carried over automatically, but actually don't work for the R4.0 version.

BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or Debian 9  templates. So, wherever that came from, it's not in the new installer version we got.

Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs based on Fedora 29. (Haven't tried Debian 9 for that yet.)

That probably came from a particular VPN provider, and would have to be installed in the template anyway to persist, right?

It seems that the update-resolve-conf is a default script that ships with some distros, such as Mint (attached), and works on our other machine, and does the function that the "qubes-vpn-handler.sh" does in the Qubes VPN instructions, but it doesn't work on Qubes in our case for the same VPN provider either.

Seems to require a lot of modification and merge the two maybe, which will take us another several days to figure out, if ever.

Openvpn actually does connect, but there's no DNS resolution, because the resolv.conf doesn't get updated.

One thing we noticed is that in the resolvctl the 8.8.8.8 and 8.8.4.4 and a couple of IPv6 servers are listed as "Fallback DNS Servers".

We can even resolve manually using them with dig.

However, the systemd-resolved or whatever is doing the resolution in this systemd mess, actually doesn't use them as a "Fallback" to resolve.

Don't know what to do next to fix this, except just more trial and error, and messy hack arounds...

On Tuesday, November 20, 2018 at 7:38:17 PM UTC, Otto Kratik wrote:

> Further update: I decided to try a completely different VPN provider's config file, and to my surprise that one worked fine using the old simple method of calling openvpn from the AppVM.

>

> Examining both files and looking for the difference between the two, it appears the broken one did not ever invoke resolvconf include the following lines:

>

> script-security 2

> up /etc/openvpn/update-resolv-conf

> down /etc/openvpn/update-resolv-conf

>

>

> Adding those lines to the non-functioning file and running it resulted in success.

[Chris Laprise]

On 6/12/19 10:14 AM, 'Crypto Carabao Group' via qubes-users wrote:
> We've also been trying for days to get a VPN to  resolve on a brand new
> R4.0 install, to either one of 2 different VPN providers, using the
> iptables and cli scripts:
> https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts
> I've also set it up before on a 3.x cubes and it worked using the above.
> So far, what's pretty certain is that these instructions were carried
> over automatically, but actually don't work for the R4.0 version.
>
> BTW, there is no "/usr/lib/qubes/qubes-vpn-setup" in the Fedora 29 or
> Debian 9  templates. So, wherever that came from, it's not in the new
> installer version we got.

There is no mention of a 'qubes-vpn-setup' in the vpn doc you linked to.
That script is a part of my Qubes-vpn-support project on github. You
might want to use that instead since the setup process is much simpler:

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

> Neither is there a path: /etc/openvpn/update-resolv-conf in the VMs
> based on Fedora 29. (Haven't tried Debian 9 for that yet.)
> That probably came from a particular VPN provider, and would have to be
> installed in the template anyway to persist, right?

There is no mention of 'update-resolv-conf' in the vpn doc, either.

One of the most frequent causes of failed vpn setups is when the user
decides to mix or combine different instructions because 'more is
better' or because they saw different people discussing the merits of
different approaches. This does NOT work; you have to pick one and
follow it.

>
> It seems that the update-resolve-conf is a default script that ships
> with some distros, such as Mint (attached), and works on our other
> machine, and does the function that the "|qubes-vpn-handler.sh|" does in
> the Qubes VPN instructions, but it doesn't work on Qubes in our case for
> the same VPN provider either.
> Seems to require a lot of modification and merge the two maybe, which
> will take us another several days to figure out, if ever.

Updating resolv.conf is not required at all to get DNS working for
downstream appVMs. The instructions avoid doing this to help keep the
VPN VM in a locked-down state, so it doesn't inadvertently try to access
the tunnel for its internal programs (i.e. only downstream VMs get to
access the tunnel).

What IS necessary is populating the DNAT rules in the firewall. Check
the PR-QBS chain to see if your DNS server IPs were added: iptables -L
-v -t nat PR-QBS

--

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

[Jon deps]

Install per the instructions for Mr.Laprise's excellent
qubes-vpn-setup in an Template-based AppVM , don't miss any steps.
ELSE

delete the AppVM and startover make sure openvpn is installed in
the Template chosen , make sure to enable proxy in the created AppVM
, and for services add the openvpn in the qubes manager tab


Which VPN provider are you using ?

[Crypto Carabao Group]

>
> Install per the instructions for Mr.Laprise's excellent
> qubes-vpn-setup in an Template-based AppVM , don't miss any steps.
> ELSE
>
> delete the AppVM and startover make sure openvpn is installed in
> the Template chosen , make sure to enable proxy in the created AppVM
> , and for services add the openvpn in the qubes manager tab
>
> Which VPN provider are you using ?
>
>

Thanks. Turned out that we probably got it to work earlier, but didn't know how to test it properly.
So, we spent days trying to figure out a problem that didn't exist.

We were confused from Step 1 by fact that to create ProxyVM, one now has to know to create an AppVM, and check "provides network".

Setting "vpn-handler-openvpn" in the the Services for that qubes, as some thread suggested, is still something we are not sure about.

We've decided to move to a hardware device from the VPN provider.

With so many manual steps and several different ways to set it up, on top of VPN provider script variations, a device seems the safest option to avoid making some mistake or misunderstanding, because we are not security experts or developers in the field.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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/ac3b7cc3-eede-c2f3-d368-7de333dd3c2a%40riseup.net.
> For more options, visit https://groups.google.com/d/optout.