Bug 632116

Summary: order of nameservers in /etc/resolv.conf after connecting to VPN is still wrong
Product: [Fedora] Fedora Reporter: Matěj Cepl <mcepl>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dcbw, mcepl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-09 15:34:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matěj Cepl 2010-09-09 08:12:50 UTC 
While reading http://thread.gmane.org/gmane.linux.network.networkmanager.devel/12056/focus=12210 I've got a feeling that NetworkManager should be able to create a sensible order of nameservers in /etc/resolv.conf. If the order of nameservers should be (I have checked that VPN routes should be used only for VPN traffic):

VPN (if VPN all traffic is routed over the VPN)
Primary connection
Others 

# after using NM-vpnc
jakoubek:~$ cat /etc/resolv.conf
# Generated by NetworkManager
domain redhat.com
search redhat.com Kaprova ceplovi.cz
nameserver 10.32.63.5
nameserver 10.33.63.7
nameserver 192.168.1.1

# after using NM-openswan
jakoubek:~$ cat /etc/resolv.conf
# Generated by NetworkManager
domain redhat.com
search redhat.com Kaprova ceplovi.cz
nameserver 10.32.63.5
nameserver 10.33.63.7
nameserver 192.168.1.1
jakoubek:~$ ip route 
209.132.186.250 via 192.168.1.1 dev eth0  proto static 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
192.168.0.0/17 dev eth0  proto kernel  scope link  src 192.168.1.3  metric 1 
10.36.0.0/16 dev eth0  proto kernel  scope link  src 10.36.8.203 
172.16.0.0/16 dev eth0  scope link  src 10.36.8.203 
10.0.0.0/8 dev eth0  scope link  src 10.36.8.203 
default via 192.168.1.1 dev eth0  proto static 
jakoubek:~$ 

jakoubek:~$ rpm -qa NetworkManager\*
NetworkManager-openswan-0.8.0-5.20100411git.fc14.x86_64
NetworkManager-gnome-0.8.1-6.git20100831.fc14.x86_64
NetworkManager-debuginfo-0.8.1-6.git20100831.fc14.x86_64
NetworkManager-vpnc-0.8.1-1.fc14.x86_64
NetworkManager-0.8.1-6.git20100831.fc14.x86_64
NetworkManager-glib-0.8.1-6.git20100831.fc14.x86_64

Expected result:
NetworkManager should recognize that 192.168.1.1 is the local DNS server and generate this resolv.conf:
jakoubek:~$ cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 10.32.63.5
nameserver 10.33.63.7
Comment 1 Dan Williams 2010-09-09 15:34:26 UTC 
Right now VPN nameservers always win.  What you really want is local caching nameserver support, which I'm actually working on now.  Given that this support will hit soon, it doesn't make sense to add a hack to always put 127.0.0.1 first.

*** This bug has been marked as a duplicate of bug 459961 ***