OpenVPN DNS resolution problem on Ubuntu

It has been a while since I had this problem, and I was a little sleepy because of travelling so it gave me a hard time for a few minutes.  In trying to resolve the problem I noticed that there are no good answers about this that can be googled.  Everyone seems to suggest extreme changes to your system.  So, let me cover this quickly and easily.

 

Problem:

You are using Linux to connect to an OpenVPN server.  You are using hotel or other free WiFi. You can connect to OpenVPN but cannot resolve DNS correctly. You are using Ubuntu 16.04, 17.04, etc. or similar kernel level Linux OS distribution with SystemD.

 

Mountains above San Diego, Pixel 2XL, Copyright Djinnsour.com 2018

So I am travelling for a few weeks.  Last night I stayed at a Days Inn in San Diego. I didn’t pick this over-priced noisy hotel with bad WiFi, but I have to live with it for a few days.  Once I got to my room I needed to fix something at the office.  So, I connected to their slow WiFi and then to our OpenVPN server using my new laptop. No problem connecting to the VPN server but I could not resolve resources on our network.

My brain was a little fuzzy so I tried to figure it out for a few minutes, gave up and went to sleep.  This morning I tackled the problem again.

 

The problem is DNS resolution. When you try to connect to an internal server, with the hostname instead of the FQDN, you won’t be able to connect or you might get a Google search result instead of the actual server.  If you try to ping the hostname you get no resolution.  But, if you ping the FQDN you get the correct result, through the OpenVPN server.

Resolution:

First, lets see what our system thinks its current DNS settings are.

If you Google for “how to check DNS servers on Ubuntu” or something similar you will get a lot of answers telling you to check resolv.conf, use the GUI tool, etc. but nothing telling you a quick an easy answer on how to show your current DNS servers similar to how ipconfig /all does on a Windows system.  I’d suggest the easiest way to do this on a modern SystemD Linux distribution is systemd-resolve.


$systemd-resolve --status

Global
 DNS Domain: gateway.innflux.com
 djinnsour.domain
 DNSSEC NTA: 10.in-addr.arpa
 16.172.in-addr.arpa
 168.192.in-addr.arpa
 17.172.in-addr.arpa
 18.172.in-addr.arpa
 19.172.in-addr.arpa
 20.172.in-addr.arpa
 21.172.in-addr.arpa
 22.172.in-addr.arpa
 23.172.in-addr.arpa
 24.172.in-addr.arpa
 25.172.in-addr.arpa
 26.172.in-addr.arpa
 27.172.in-addr.arpa
 28.172.in-addr.arpa
 29.172.in-addr.arpa
 30.172.in-addr.arpa
 31.172.in-addr.arpa
 corp
 d.f.ip6.arpa
 home
 internal
 intranet
 lan
 local
 private
 test

Link 7 (tun0)
 Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
 LLMNR setting: yes
MulticastDNS setting: no
 DNSSEC setting: no
 DNSSEC supported: no
 DNS Servers: 192.168.1.1
 DNS Domain: djinnsour.domain

Link 2 (wlp2s0)
 Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
 LLMNR setting: yes
MulticastDNS setting: no
 DNSSEC setting: no
 DNSSEC supported: no
 DNS Servers: 172.20.0.1
 DNS Domain: gateway.innflux.com

 

 

If you take a look at the output of systemd-resolve above you’ll see I have highlighted a few lines.  These are showing my current DNS servers and the DNS Domain assigned to my system. They also show the order they have been assigned. So, what is happening when I try to connect to something like fileserver1 over OpenVPN is that the system is trying to connect to fileserver1.gateway.influx.com because the local DHCP server assigned me a domain name. I’m not sure why they would do this, but it obviously causes a small problem.

To test this theory I changed my network settings so that it does not pull anything but the IP address and gateway using DHCP.  I also assigned the DNS servers 8.8.8.8 and 8.8.4.4 but that isn’t necessary to resolve this problem.  Now, if I check the output of systemd-resolve I show the following:

 

$systgemd-resolve --status

Global
 DNS Domain: gateway.innflux.com
 djinnsour.domain
 DNSSEC NTA: 10.in-addr.arpa
 16.172.in-addr.arpa
 168.192.in-addr.arpa
 17.172.in-addr.arpa
 18.172.in-addr.arpa
 19.172.in-addr.arpa
 20.172.in-addr.arpa
 21.172.in-addr.arpa
 22.172.in-addr.arpa
 23.172.in-addr.arpa
 24.172.in-addr.arpa
 25.172.in-addr.arpa
 26.172.in-addr.arpa
 27.172.in-addr.arpa
 28.172.in-addr.arpa
 29.172.in-addr.arpa
 30.172.in-addr.arpa
 31.172.in-addr.arpa
 corp
 d.f.ip6.arpa
 home
 internal
 intranet
 lan
 local
 private
 test

Link 8 (tun0)
 Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
 LLMNR setting: yes
MulticastDNS setting: no
 DNSSEC setting: no
 DNSSEC supported: no
 DNS Servers: 192.168.1.1
 DNS Domain: djinnsour.domain

Link 2 (wlp2s0)
 Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
 LLMNR setting: yes
MulticastDNS setting: no
 DNSSEC setting: no
 DNSSEC supported: no
 DNS Servers: 8.8.8.8
 8.8.4.4

The free WiFi is no longer assigning a default domain and the domain assigned to my OpenVPN connection will be the default.

So, the easy answer on how to resolve this problem on a public WiFi connection is to change your DHCP settings so that it only pulls the IP info.

This is probably not the best solution, that would be something like using OpenVPN’s update-resolve as a push but I’ve found this doesn’t always work.  I’ll make another post detailing this in the future, for now this is probably the easiest way to get you online.

 

Share: