MacOS – OpenVPN client to use local DNS server and VPN provider’s DNS server

dnsmacosopenvpntunnelblick

Target: I would like the openvpn client on macOS using tunnelblick to use the VPN provider's DNS server first, and if it cannot resolve a DNS name there, it should use my local DNS server.

Situation: a local DNS server provides names/IPs for machines on the LAN, and also resolves names on remote DNS servers for names of machines on the WAN. When connected to the VPN provider, the openvpn server pushes dhcp-option DNS . In this situation local machine's DNS names do not get resolved, if connected to the openvpn server at the provider. This is clearly not what one wants.
I am aware that modern macOS does not use /etc/resolv.conf and therefore I am testing the resolution using the browser to access local or remote machines and dnsleaktest.com to check which DNS server is used!

Problem: When using "dhcp-option DNS ", it will be prioritized over the VPN DNS server. Then local machine names do get resolved, but when resolving names on the WAN, this will also be done by the local DNS server, which represents a DNS leak (as is verifiable using dnsleaktest.com). This is clearly also not what one wants.

Unfortunately, using: pull-filter accept "dhcp-option DNS”
before or after "dhcp-option DNS " will not(!) influence the order in which DNS servers are queried. In fact it seems that only 1 DNS server gets queried, even if the answer is NXDOMAIN no other DNS server gets queried.

I would really like the VPN DNS server to be queried first, and if it fails, the local DNS server should be queried. The chance for a DNS leak should be small / zero then?

Overall, I am stuck here, I do not seem to find a way to use tunnelblick in a way as the target statement describes.
Can you confirm, that this is not possible, or could you provide a solution?

Best Answer

Yes, I had tried the various dhcp-option, these leads nowehere. In the meanwhile I found a solution for macOS:

you create /etc/resolver/lan with the following content:

domain lan
nameserver 10.0.1.1   <- the local dns server
search_order 1
search lan            <- important! otherwise you must append .lan every time by yourself

Now the system behaves exactly as I wanted. local machine names are resolved properly without the need to append ".lan", and external names get revsolved via the VPN provider's DNS server. There is no DNS leak.

Related Solutions

Openvpn client connects to server but name resolution does not work

Ubuntu does magic stuff with DNS, but fortunately OpenVPN provides a way to deal with that. If you've installed openvpn from the Ubuntu repositories, you'll have a script in /etc/openvpn/update-resolv-conf to tell Ubuntu what DNS it should use for your vpn connection. To use it, add the following lines to your openvpn configuration file:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

That will run the script when your VPN connection comes up and goes down, and will update the DNS settings accordingly.

Edit (20-06-2018): As @Thenightmanager mentions in the comments, modern Ubuntu (at least 18.04 and newer) introduced some extra systemd DNS magic, and the update-resolv-conf script might no longer suffice. Check out update-systemd-resolved for a possible working alternative.

Linux – Resolve names on OpenVPN server side

I'm not sure if that "push" is necessary, as I don't use DHCP client-side.

OpenVPN already receives its IP address and other configuration from the server, so it understands certain "DHCP options" itself even if they're not technically sent via DHCP.

I presume I must set up my (VPN) server to also be a DNS server in order for that to work. But is that necessary?

Yes, it is. (Specifically you need a resolver – Unbound, dnsmasq, Bind9 will work, but NSD will not as it's authoritative-only.)

Why can't the VPN server handle forwarded DNS queries via it's resolv.conf (without being a DNS server, just as it handles everything else without being an everything else server)?

That's not even close to the same thing – the VPN server doesn't handle "everything else", it merely forwards the IP packets.

For example, if a client connects to Google, or uses 8.8.8.8 as your DNS server, the VPN server only sees that it's an IPv4 packet for someone else's IP address. So the VPN server doesn't try to understand the packet's contents – just sends it towards the next router, and so on, until the packet eventually reaches the real destination.

But if you want the VPN server to honor its resolv.conf, then it must understand how it's related to the packets it receives, and what replies should be generated – and it needs two things for that:

For a start, your clients must use the VPN server's own address as their "DNS server", so that the server would see itself as the packets' final destination and actually interpret their contents (as UDP) rather than forwarding them somewhere else.

(That means "Client-side resolv.conf (manually set, never changes)" is a problem. If you push the dns-server option, the OpenVPN client will understand it and it should try to update the client's resolv.conf, but that depends on the system.)
Now the VPN server is receiving packets to UDP port 53, but it still doesn't automagically understand what data they contain. Just like you need a web server to understand HTTP requests, you also need a DNS server to understand DNS requests and to properly reply to them.

Technically, you can get around the 1st requirement by using iptables on the VPN server to redirect all UDP/53 packets to itself – I think that's called "transparent proxy" or -j REDIRECT in various tutorials.

But I suggest only doing that once you have a good grasp on the distinction between your server forwarding packets and handling them itself. Otherwise it would only add to the confusion.

Best Answer

Related Solutions

Openvpn client connects to server but name resolution does not work

Linux – Resolve names on OpenVPN server side

Related Question