[SOLVED] Having problems with DNS on one of multiple OpenVPN client connections

skubik · 11-15-2016, 12:14 AM

I'm using OpenVPN in a Linux VM to connect to two different VPNs at the same time. I am typically always connected to both VPNs at all times.

VPN1 uses 10.8.0.0/24 IP's, and VPN2 uses 10.9.0.0/24 IP's.

I have no problem connecting to either one and can easily ping other machines on either VPN using the IP.

VPN1 recently got moved to a router running dd-wrt. It seems to be working fine and I have dnsmasq configured to handle DNS requests for 10.8.0.0/24.

VPN2 is running on another x86 machine and has named/bind setup for DNS requests from 10.9.0.0/24 and it's been working fine for years.

On my Linux VM, /etc/resolv.conf looks like:

Code:

nameserver 10.8.0.1
nameserver 10.9.0.1
domain mynet.lan
nameserver 192.168.0.1

On my Linux VM I *am* able to ping machines on VPN1 by name, ie:

Code:

> ping box1.vpn1.vpn
64 bytes from box1.vpn1.vpn (10.8.0.11): icmp_seq=1 ttl=64 time=2.12 ms
64 bytes from box1.vpn1.vpn (10.8.0.11): icmp_seq=2 ttl=64 time=2.38 ms
64 bytes from box1.vpn1.vpn (10.8.0.11): icmp_seq=3 ttl=64 time=5.05 ms

But when I go to ping machines on VPN2 by name, I get:

Code:

> ping box1.vpn2.vpn
ping: unknown host vpn2.vpn

When I try and ping Internet addresses (ie: Google), it seems to work fine.

I then started looking at what 'nslookup' gave me and got these results:

Code:

> nslookup vpn1.vpn
Server:         10.8.0.1
Address:        10.8.0.1#53

Name:   vpn1.vpn
Address: 10.8.0.1

Code:

> nslookup vpn2.vpn
Server:         10.8.0.1
Address:        10.8.0.1#53

** server can't find vpn2.vpn: NXDOMAIN

Code:

> nslookup google.com
Server:         10.8.0.1
Address:        10.8.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.216.238

It looks to me like each request is going to 10.8.0.1 for resolution. That's fine for vpn1.vpn and even for Internet addresses since the DNS at 10.8.0.1 and 192.168.0.1 are the same; the dd-wrt router, but I don't understand why a search for anything under vpn2.vpn fails.

If it isn't found on the first nameserver in /etc/resolv.conf, shouldn't it (my Linux VM) subsequently query the nameserver at 10.9.0.1, where it *would* find the requested address?

This used to work prior to moving VPN1 to dd-wrt because the old server for VPN1 was also a client for VPN2, so named/bind would jump to 10.9.0.1 if it didn't find it locally. I don't remember off-hand how I set this up; I could dig it up if requested.
But I don't have any explicit forwarding setup in dnsmasq on 10.8.0.1 on the dd-wrt router, and I don't *want* it to interact with VPN2 anyway; if the requested address isn't found on 10.8.0.1, it should look for it on 10.9.0.1, before going out to the Internet to look for it.

Can someone help shed some light on this for me?

tshikose · 11-15-2016, 05:42 AM

Hi,

Please results of the following commands.

ip addr show
ip route show
dig box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org
dig @10.8.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org
dig @10.9.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org

skubik · 11-16-2016, 05:01 PM

Thanks for responding!
Output as requested...

ip addr show

Code:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:04:65:59 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.101/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5b88:a157:4824:bcb9/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 08:00:27:1a:01:4b brd ff:ff:ff:ff:ff:ff
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.9.0.155 peer 255.255.255.0/32 scope global tun0
       valid_lft forever preferred_lft forever
9: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.37/24 brd 10.8.0.255 scope global tun1
       valid_lft forever preferred_lft forever

ip route show

Code:

default via 192.168.0.1 dev eth0  metric 202 
10.8.0.0/24 dev tun1  proto kernel  scope link  src 10.8.0.37 
10.9.0.0/24 via 255.255.255.0 dev tun0 
10.9.0.1 via 255.255.255.0 dev tun0 
10.9.1.0/24 via 255.255.255.0 dev tun0 
127.0.0.0/8 dev lo  scope link 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.101  metric 202 
255.255.255.0 dev tun0  proto kernel  scope link  src 10.9.0.155

dig box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org

Code:

; <<>> DiG 9.10.4-P2 <<>> box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63258
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;box1.vpn1.vpn.     IN      A

;; ANSWER SECTION:
box1.vpn1.vpn. 0    IN      A       10.8.0.37

;; Query time: 3 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Wed Nov 16 15:39:14 MST 2016
;; MSG SIZE  rcvd: 70

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49681
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;box1.vpn2.vpn.    IN      A

;; Query time: 2 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Wed Nov 16 15:39:14 MST 2016
;; MSG SIZE  rcvd: 55

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37315
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.linuxquestions.org.                IN      A

;; ANSWER SECTION:
www.linuxquestions.org. 278     IN      A       75.126.162.205

;; Query time: 54 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Wed Nov 16 15:39:14 MST 2016
;; MSG SIZE  rcvd: 67

dig @10.8.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org

Code:

; <<>> DiG 9.10.4-P2 <<>> @10.8.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43365
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;box1.vpn1.vpn.     IN      A

;; ANSWER SECTION:
box1.vpn1.vpn. 0    IN      A       10.8.0.37

;; Query time: 4 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Wed Nov 16 15:44:02 MST 2016
;; MSG SIZE  rcvd: 70

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49482
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;box1.vpn2.vpn.    IN      A

;; Query time: 2 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Wed Nov 16 15:44:02 MST 2016
;; MSG SIZE  rcvd: 55

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62684
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.linuxquestions.org.                IN      A

;; ANSWER SECTION:
www.linuxquestions.org. 150     IN      A       75.126.162.205

;; Query time: 65 msec
;; SERVER: 10.8.0.1#53(10.8.0.1)
;; WHEN: Wed Nov 16 15:44:02 MST 2016
;; MSG SIZE  rcvd: 67

dig @10.9.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org

Code:

; <<>> DiG 9.10.4-P2 <<>> @10.9.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31740
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;box1.vpn1.vpn.     IN      A

;; AUTHORITY SECTION:
.                       10800   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2016111601 1800 900 604800 86400

;; Query time: 125 msec
;; SERVER: 10.9.0.1#53(10.9.0.1)
;; WHEN: Wed Nov 16 15:47:07 MST 2016
;; MSG SIZE  rcvd: 129

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49020
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;box1.vpn2.vpn.    IN      A

;; ANSWER SECTION:
box1.vpn2.vpn. 86400 IN    A       10.9.0.73

;; AUTHORITY SECTION:
vpn2.vpn.        86400   IN      NS      dns.vpn2.vpn.

;; ADDITIONAL SECTION:
dns.vpn2.vpn.          86400   IN      A       10.9.0.1

;; Query time: 2 msec
;; SERVER: 10.9.0.1#53(10.9.0.1)
;; WHEN: Wed Nov 16 15:47:07 MST 2016
;; MSG SIZE  rcvd: 105

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48985
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.linuxquestions.org.                IN      A

;; ANSWER SECTION:
www.linuxquestions.org. 300     IN      A       75.126.162.205

;; AUTHORITY SECTION:
linuxquestions.org.     625     IN      NS      ns3.systemdns.com.
linuxquestions.org.     625     IN      NS      ns1.systemdns.com.
linuxquestions.org.     625     IN      NS      ns2.systemdns.com.

;; ADDITIONAL SECTION:
ns1.systemdns.com.      1200    IN      A       216.40.47.90
ns2.systemdns.com.      1200    IN      A       64.98.148.16
ns3.systemdns.com.      1200    IN      A       64.99.96.36

;; Query time: 156 msec
;; SERVER: 10.9.0.1#53(10.9.0.1)
;; WHEN: Wed Nov 16 15:47:08 MST 2016
;; MSG SIZE  rcvd: 182

Note that I've changed the domain names to something generic here (vpn1.vpn and vpn2.vpn aren't the actual domains I'm using), so if there's something that looks wrong (mismatched IP's or something), that's why.

It looks like there's some differences in the routing output (ip route show). Not sure how to move forward with it though.
Any thoughts?

Thanks!

tshikose · 11-17-2016, 02:28 AM

Hi,

The DNS order in /etc/resolv.conf matters, and the fallback is in case the referenced one fails to respond, not that it does not know the answer.
So while the first is up and running, the second is never queried.
See http://serverfault.com/questions/172...ext-nameserver and http://serverfault.com/questions/562...isted-in-resol

A solution, is to back to what you did in the past making the first DNS server client of the second one for the second one domain.

Yes, to me also the ip route show output looks suspicious.
I was expecting similarities between your two OpenVPN networks.
Which flavor and version of Linux are you using?
Are you using network service or NetworkManager service?

tshikose · 11-17-2016, 02:34 AM

Hi,

I think the discrepancy in the network routing is related to the way the OpenVPN servers are set up.
It seems to me that they are implementing different kind of networks.

Is it possible to post relevant part of the OpenVPN servers configurations?

skubik · 11-18-2016, 05:37 PM

Sorry for the delayed response.

Regarding which Linux versions are being used:
VPN1 is on a D-Link DIR-880L router running DD-WRT v3.0-r30432 (kernel 4.4.17)
VPN2 is on a dedicated PC server running Slackware64 14.1
My client Linux VM is Slackware64 14.2.

I should note that the resolv.conf entries for both VPNs are added via entries in resolv.conf.head that I entered manually myself.
I am not using NetworkManager to connect, but rather my own scripts that bring up my network according to what I need (my VM has 2 eth devices; one for a direct/bridged connection to a router, and another to use NAT routing via my VM; which is used primarily when connecting to public wifi).

As for how the OpenVPN servers are configured, there isn't a simple conf file from DD-WRT (for VPN1) that I can post, so I've taken screengrabs from the router's web admin.

They can be seen here: http://imgur.com/a/UPEPr

The VPN2 server config, however, is below:

Code:

port 9697
proto tcp
dev tun
ca /usr/local/openvpn/vpn2/keys/ca.crt
cert /usr/local/openvpn/vpn2/keys/server.crt
key /usr/local/openvpn/vpn2/keys/server.key
dh /usr/local/openvpn/vpn2/keys/dh1024.pem
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/vpn2/ipp.txt

client-config-dir /usr/local/openvpn/vpn2/clients
route 10.9.0.0 255.255.255.0
route 10.9.1.0 255.255.255.0
push "dhcp-option DNS 10.9.0.1"

keepalive 10 120

tls-auth /usr/local/openvpn/vpn2/keys/ta.key 0

comp-lzo

user nobody
group nobody

persist-key
persist-tun

status /var/log/openvpn/vpn2/connections.log

log-append /var/log/openvpn/vpn2/openvpn.log
verb 5

This is the OpenVPN server ccd client file for my client VM for VPN2:

Code:

ifconfig-push 10.9.0.155 255.255.255.0
push "route 10.9.0.0 255.255.255.0"
push "route 10.9.1.0 255.255.255.0"

tshikose · 11-19-2016, 04:55 AM

Hi,

I think the route commands in the OpenVPN server configuration should be as below.

route 10.9.0.0 255.255.255.0 10.9.0.1
route 10.9.1.0 255.255.255.0 10.9.1.1

And maybe the corresponding push commands.

Personally, I have always avoided pushing things to OpenVPN clients.
I prefer letting the client decide how to set up its routes while bringing up the network interface.
Generally the default (go via interface to go to sub network) is enough.

skubik · 11-22-2016, 04:28 PM

So I tried changing the route settings on the server as you suggested, but it didn't resolve anything; still getting 'unknown host' when I try pinging that domain.

Output of route while connected to both VPN1 & VPN2:

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.2.1        0.0.0.0         UG    203    0        0 eth1
10.0.2.0        *               255.255.255.0   U     203    0        0 eth1
10.8.0.0        *               255.255.255.0   U     0      0        0 tun1
10.9.0.1        255.255.255.0   255.255.255.255 UGH   0      0        0 tun0
loopback        *               255.0.0.0       U     0      0        0 lo
255.255.255.0   *               255.255.255.255 UH    0      0        0 tun0

I've also tried playing around with those settings. First I commented them out in the server config; relying on a push in the client ccd file. Then I reversed it; enabled the routes in the server config and removed them from the client ccd file. Didn't seem to make any difference.

I've also tried manually deleting the routes for VPN2 and re-adding them.

Code:

> route del 255.255.255.0
> route del 10.9.0.1
> route add -net 10.9.0.0 netmask 255.255.255.0 dev tun0

> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.2.1        0.0.0.0         UG    203    0        0 eth1
10.0.2.0        *               255.255.255.0   U     203    0        0 eth1
10.8.0.0        *               255.255.255.0   U     0      0        0 tun1
10.9.0.0        *               255.255.255.0   U     0      0        0 tun0
loopback        *               255.0.0.0       U     0      0        0 lo

Still no change. Still getting 'unknown host' when pinging a VPN2 box.

I took a look at the results for 'ip route show' and got this:

Code:

default via 10.0.2.1 dev eth1  metric 203 
10.0.2.0/24 dev eth1  proto kernel  scope link  src 10.0.2.4  metric 203 
10.8.0.0/24 dev tun1  proto kernel  scope link  src 10.8.0.37 
10.9.0.0/24 dev tun0  scope link 
127.0.0.0/8 dev lo  scope link

I notice that VPN2 (10.9.0.0/24) has no 'proto kernel' or 'src' in it's line like VPN1 (10.8.0.0/24) does.

Am I missing something here?

Also, it's my understanding that when a DNS request is made, it'll traverse all the nameserver entries in /etc/resolv.conf. That is, if the request isn't found from the first nameserver, it'll go to the next one, and so on. Am I incorrect in this understanding? Is the reason why I can't ping anything on my VPN2 because the first entry in my /etc/resolv.conf (nameserver 10.8.0.1) *is* available, so then all other nameserver entries are disregarded? They would only be used if 10.8.0.1 wasn't reachable?

tshikose · 11-23-2016, 02:06 AM

Hi,

This is a quick reply.
I look at the routing later this week.
Sorry, if you are in a hurry.
But for the DNS "ordering" you got it right.
If the first nameserver responds, even with a "I do not know the IP of the fully qualified name you are interested with", your resolver will not go to the next nameserver in /etc/hosts.
It is only if one fails to respond that it goes through the list.

skubik · 11-28-2016, 11:45 PM

So, I solved my problem. Once you explained that /etc/hosts only goes onto the next defined nameserver if the previous one fails to respond instead of failing to find the requested domain, I turned my attention to adding a local DNS server under my Linux VM, and adding the root zones for each VPN to named.conf of type 'forward', then pointed everything else to Google's DNS to keep things simple (since I tend to use a lot of public hotspots and don't want the hassle of using their DNS).

Code:

acl "trusted" {
        127.0.0.1;
        192.168.0.0/24;
        10.8.0.0/24;
        10.9.0.0/24;
};



options {
        pid-file "/var/run/bind/run/named.pid";
        directory "/usr/local/etc/bind";

        auth-nxdomain yes;
        datasize default;

        recursion yes;
        allow-recursion { any; };
        allow-transfer { none; };
        allow-update { none; };

        version none;
        hostname none;
        server-id none;
};



logging {
        channel xfer-log {
                file "/var/log/named.log";
                print-category yes;
                print-severity yes;
                print-time yes;
                severity info;
        };

        category xfer-in { xfer-log; };
        category xfer-out { xfer-log; };
        category notify { xfer-log; };
};




zone "vpn2.vpn" {
        type forward;
        forwarders { 10.9.0.1; };
};

zone "vpn1.vpn" {
        type forward;
        forwarders { 10.8.0.1; };
};

zone "." IN {
        type forward;
        forwarders { 8.8.8.8; 8.8.4.4; };
};

I replaced the nameserver entries in /etc/resolv.conf.head to point to the local DNS instead of the VPN DNS's, which is reflected when /etc/resolv.conf gets generated

Code:

nameserver 127.0.0.1

Then I simply started my bind service and reconnected my network and VPN connections just to make sure, and voila! Everything works great!

I still have some route oddities on VPN2, but that's an OpenVPN thing and has been working fine up to now, so I'm not going to shake that cage unless I need to, and really, is outside the scope of my initial problem anyway.

So I've marked this thread as solved. Thank you so much for all your insight!