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 
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 and 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.

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 
For more options, visit https://groups.google.com/d/optout.

Attachment: update-resolv-conf
Description: Binary data

Attachment: publickey - cryptocarabao@protonmail.ch - 0x3F7D5EFD.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to