On 06/21/2016 03:04 PM, Chris Laprise wrote:
On 06/21/2016 02:09 AM, Jane Jok wrote:
Hello!
So, long story short, I've successfully configured a debian-based
ProxyVM to run Mullvad's GUI client (I know one can use "vanilla
OpenVPN" to connect to mullvad, I still prefer their GUI thing and
decided to give it a try)
In a word, as long as one does not select "block internet access on
connection failure" everything works.
Hi,
Keep in mind that a Qubes proxy vm implies different conditions for
blocking than a regular desktop architecture, so the Mullvad client
may not get this right. Its best to setup Qubes-specific blocking
instead (which is more effective anyway)...
However, there is a persistent DNS leak from any AppVM connected to
the MullvadProxyVM (as detected by ipleak.net)
Also, if I take the "block connection if tunnel breaks" suggestion
from here https://www.qubes-os.org/doc/vpn/
(that is, add
|iptables -I FORWARD -o eth0 -j DROP iptables -I FORWARD -i eth0 -j
DROP to my iptables in the MullvadProxyVM) No connected AppVM can
resolve hostnames (direct IP works tho) I have, however, figured out
a sort-a-kinda solution. The solution I have found so far is to edit
resolv.conf in AppVM to something external (like say Google's DNS,
8.8.8.8) As long as AppVM's resolv.conf has 8.8.8.8 (or any other
external nameserver) in it, everything works like a charm without any
DNS leaks. However, it the resolv.conf in AppVMs is not very
persistent, and even if |||/rw/config/rc.local| is modified to adjust
resolv.conf, certain events (like changing netvms) trigger
restoration of "old" resolv.conf So, my first question is: 1) is
there a way to prevent reset of manually edited resolv.conf,
particularly in case when you change AppVM's netvm ? |
|Past advice on setting up a vpn vm revolved around these 3 steps:
1. Update resolv.conf (hard-coded IPs or from openvpn DHCP)
2. Run the /usr/lib/qubes/qubes-setup-dnat-to-ns script
3. Add the eth0 forward-blocking you mentioned to
qubes-firewall-user-script
The first two basically worked, but had the side-effect of making the
local vpn vm commands use the tunnel's dns. That might prevent the vpn
from successfully restarting, or maybe create a different kind of leak
if local commands inadvertently tried to access the net.
That's why qubes-vpn-handler.sh exists. It accepts dns addresses and
fixes the dns dnat issue without changing resolv.conf. It shouldn't be
too hard to integrate with the GUI client if it uses openvpn or
similar; you just need to run it as the up-script.
OTOH, if the side-effects I mentioned above seem trivial to you, then
you can use #2 to get dns working.
Also, don't mean to imply that #3 doesn't work. All three do work
together to route DNS and stop leaks.
Chris
--
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/56ab626e-b04f-93fd-c703-dfa41c20de72%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
