Debian: Order of DNS servers when using VPN

Question

My notebook gets its DNS servers via DHCP.

When I start a VPN session (pptp, managed my networkmanager), the DNS servers received from that VPN session are queried first.

I'd like to use the DNS servers of the VPN only if my primary DNS returns NXDOMAIN.

How do I do that?

/etc/resolv.conf

# Generated by NetworkManager
domain homesweethome
search homesweethome
nameserver 192.168.1.1

traceroute 8.8.8.8 when connected to VPN

 1  sheldon.homesweethome (192.168.1.1)  0.714 ms  0.880 ms  1.001 ms
 2  * * *
 3  172.30.12.49 (172.30.12.49)  13.693 ms  14.181 ms  14.316 ms
 4  84.116.191.49 (84.116.191.49)  15.067 ms  15.199 ms  15.336 ms
 5  * * *
 6  216.239.56.106 (216.239.56.106)  22.409 ms  14.401 ms  14.447 ms
 7  216.239.57.192 (216.239.57.192)  14.414 ms 216.239.57.188 (216.239.57.188)  22.950 ms 216.239.57.127 (216.239.57.127)  22.846 ms
 8  66.249.95.23 (66.249.95.23)  22.992 ms 66.249.95.39 (66.249.95.39)  23.832 ms 209.85.253.216 (209.85.253.216)  23.556 ms
 9  74.125.37.150 (74.125.37.150)  28.828 ms  28.571 ms  24.278 ms
10  209.85.246.160 (209.85.246.160)  21.975 ms 216.239.42.98 (216.239.42.98)  21.467 ms 216.239.51.207 (216.239.51.207)  23.297 ms
11  * * *
12  google-public-dns-a.google.com (8.8.8.8)  22.556 ms  23.421 ms  23.266 ms

traceroute 8.8.8.8 when not connected

 1  sheldon.homesweethome (192.168.1.1)  0.651 ms  3.098 ms  4.927 ms
 2  * * *
 3  172.30.12.49 (172.30.12.49)  16.504 ms  16.791 ms  17.125 ms
 4  84.116.191.49 (84.116.191.49)  17.186 ms  23.111 ms  23.277 ms
 5  * * *
 6  216.239.56.22 (216.239.56.22)  25.766 ms 216.239.56.178 (216.239.56.178)  17.433 ms 216.239.56.22 (216.239.56.22)  18.432 ms
 7  216.239.57.182 (216.239.57.182)  17.526 ms  14.840 ms 216.239.57.190 (216.239.57.190)  15.748 ms
 8  209.85.253.216 (209.85.253.216)  17.661 ms 66.249.95.39 (66.249.95.39)  17.786 ms  18.213 ms
 9  74.125.37.154 (74.125.37.154)  29.039 ms 74.125.37.103 (74.125.37.103)  28.667 ms 74.125.37.97 (74.125.37.97)  25.168 ms
10  209.85.250.165 (209.85.250.165)  25.532 ms  24.350 ms 216.239.51.149 (216.239.51.149)  25.776 ms
11  * * *
12  google-public-dns-a.google.com (8.8.8.8)  22.513 ms  22.979 ms  22.484 ms

/etc/ppp/resolv.conf

nameserver 10.11.10.101
nameserver 10.11.10.102

Answer 1

The access for internal resources when having a active VPN connection is only supposed to work if you have Split Tunneling active.

Split tunneling

Split tunneling is a computer networking concept which allows a mobile user to access dissimilar security domains like a public network (e.g., the Internet) and a local LAN or WAN at the same time, using the same or different network connections.

With split tunneling, it is then a matter of the DNS order server having the DNS of the VPN at the top and your normal DNS servers at the end. By the normal inner workings of DNS, the top ones failing the request will trickle down to the bottom ones.

You seem to have already split tunnelling active per our debugging, so as a quick fix, it is a matter of adding your DNS to /etc/ppp/resolv.conf.

As for having a more generic approach, this page talks about using dnsmasq.

DNS routing after PPTP connection

A solution would be to run a local DNS server that can forward queries to other DNS servers based on subdomain/domain.

Ubuntu's network-manager already runs a local DNS server (dnsmasq-base) however the required options are not available so disable it then install and configure the full dnsmasq package as follows:

1) Comment out dns=dnsmasq from /etc/NetworkManager/NetworkManager.conf
2) Restart network-manager: sudo service network-manager restart
3) Install dnsmasq package: sudo apt-get install dnsmasq
4) Edit /etc/dnsmasq.conf and add: address=/.mywork/VPN_DNS_IP address=/#/INTERNET_DNS_IP
5) Restart dnsmaq: sudo service dnsmasq restart

I will also leave here a link concerning security with VPN protocols.

PPTP VS L2TP/IPSEC VS OPENVPN

The Microsoft implementation of PPTP has serious security vulnerabilities. MSCHAP-v2 is vulnerable to dictionary attack and the RC4 algorithm is subject to a bit-flipping attack. Microsoft strongly recommends upgrading to IPSec where confidentiality is a concern.