No DNS with ProxyVM + OpenVPN

453 views
Skip to first unread message

koto...@gmail.com

unread,
Aug 15, 2016, 3:33:06 AM8/15/16
to qubes-users
Hi,


I set up a proxyVM with openvpn following the instructions from https://www.qubes-os.org/doc/vpn/.

I cannot do DNS query over the VPN, for example this command executed from a VM connected to the Proxy:


[user@fedora-23-dvm ~]$ dig www.google.com

; <<>> DiG 9.10.3-P4-RedHat-9.10.3-13.P4.fc23 <<>> www.google.com
;; global options: +cmd
;; connection timed out; no servers could be reached


Executing 'dig @8.8.8.8 www.google.com' works well.

What am I doing wrong?

Chris Laprise

unread,
Aug 15, 2016, 11:44:30 AM8/15/16
to koto...@gmail.com, qubes-users
Hi,

Its possible that your vpn service isn't supplying dns server info upon
connection.

You can check what openvpn is getting from your service by upping the
verbosity to 3 while running openvpn manually like this:

$ sudo groupadd -rf qvpn
$ sudo sg qvpn -c 'openvpn --cd /rw/config/openvpn/ --config
openvpn-client.ovpn --verb 3'

You should see a message like this from openvpn, though the dns numbers
will probably be different:
PUSH: Received control message: PUSH_REPLY,dhcp-option DNS
1.2.3.4,dhcp-option DNS 1.2.3.5

...etc. This indicates that openvpn has received dns server info from
the vpn provider.

Another thing to check is whether those dns numbers got into the firewall:
$ sudo iptables -v -L -t nat

The chain PR-QBS should have two entries per dns address.

OTOH, if you want to bypass dhcp and use hard-coded dns numbers instead,
add them to your openvpn config file like this:

setenv vpn_dns '1.2.3.4 1.2.3.5'

Chris

koto...@gmail.com

unread,
Aug 15, 2016, 1:05:48 PM8/15/16
to qubes-users, koto...@gmail.com, tas...@openmailbox.org
Thank you very much for your help. The DNS are transmitted but the rules in the firewall seems to be missing:

Chain PR-QBS (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT udp -- any any anywhere 10.137.5.1 udp dpt:domain to:10.137.2.1
0 0 DNAT tcp -- any any anywhere 10.137.5.1 tcp dpt:domain to:10.137.2.1
0 0 DNAT udp -- any any anywhere 10.137.5.254 udp dpt:domain to:10.137.2.254
0 0 DNAT tcp -- any any anywhere 10.137.5.254 tcp dpt:domain to:10.137.2.254

The qubes script is nonetheless correctly started because I see the notification "VPN is up".

Chris Laprise

unread,
Aug 15, 2016, 6:43:23 PM8/15/16
to koto...@gmail.com, qubes-users
Something else may be running a dnat script when you connect, because
that is the only thing that would be re-populating PR-QBS with the Qubes
internal IPs.

To test this theory, you could put a 7sec delay in qubes-vpn-handler.sh
right before the line 'iptables -t nat -F PR-QBS'. Then the right IPs
should appear in PR-QBS.

Alternative theory is that somehow openvpn is passing the internal IPs
to the script, but I think that's unlikely.

Chris

koto...@gmail.com

unread,
Aug 16, 2016, 6:56:12 AM8/16/16
to qubes-users, koto...@gmail.com, tas...@openmailbox.org

> To test this theory, you could put a 7sec delay in qubes-vpn-handler.sh
> right before the line 'iptables -t nat -F PR-QBS'. Then the right IPs
> should appear in PR-QBS.

It did work. Thank you again!

I wonder what is changing the NAT rules. I only see one 'up' directive in the openvpn configuration, the one calling the qubes script. Maybe something from Qubes itself? It's correct that the ProxyVM should be connected to sys-firewall right?

Chris Laprise

unread,
Aug 16, 2016, 5:38:15 PM8/16/16
to koto...@gmail.com, qubes-users
That was going to be my next question: Is there anything in the vpn
config that triggers it, such as any other references to scripts.
Ideally, there should only be up and down.

If you're comfortable posting the configuration maybe I or someone else
could see the cause. Also the parts of the log output near the end that
deal with PUSH data, since that is a source of configuration directives.

I also wonder if your template might have an openvpn service configured
to autostart... creating a second openvpn process? You can check that
with ps, systemctl, etc.

Also, Network Manager should not be running in that vm.

Finally, you could disable the /usr/lib/qubes/qubes-setup-dnat-to-ns
script by renaming it right before openvpn starts (but it does have to
run once on vm start). That should prevent it from steamrolling over the
vpn-specific IPs.

Chris

koto...@gmail.com

unread,
Aug 17, 2016, 6:23:26 AM8/17/16
to qubes-users, koto...@gmail.com, tas...@openmailbox.org
I found the culprit thanks to your very helpful instructions: the network-manager service was running in the VM.

It happened because I did first test my VPN with the instructions (https://www.qubes-os.org/doc/vpn/) following the "Using NetworkManager" section as a quick test, to only later set it up without it.

Thanks again. I hope this thread will be useful for others facing similar problems.

Reply all
Reply to author
Forward
0 new messages