Having problems with DNS on one of multiple OpenVPN client connections
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 Code:
> ping box1.vpn1.vpn Code:
> ping box1.vpn2.vpn I then started looking at what 'nslookup' gave me and got these results: Code:
> nslookup vpn1.vpn Code:
> nslookup vpn2.vpn Code:
> nslookup google.com 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? |
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 |
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 Code:
default via 192.168.0.1 dev eth0 metric 202 Code:
; <<>> DiG 9.10.4-P2 <<>> box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org 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 Code:
; <<>> DiG 9.10.4-P2 <<>> @10.9.0.1 box1.vpn1.vpn box1.vpn2.vpn www.linuxquestions.org 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! |
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? |
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? |
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 Code:
ifconfig-push 10.9.0.155 255.255.255.0 |
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. |
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 I've also tried manually deleting the routes for VPN2 and re-adding them. Code:
> route del 255.255.255.0 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 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? |
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. |
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" { Code:
nameserver 127.0.0.1 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! |
All times are GMT -5. The time now is 11:35 PM. |