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:
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:
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
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
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.