Bug 632116 - order of nameservers in /etc/resolv.conf after connecting to VPN is still wrong
Summary: order of nameservers in /etc/resolv.conf after connecting to VPN is still wrong
Keywords:
Status: CLOSED DUPLICATE of bug 459961
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-09 08:12 UTC by Matěj Cepl
Modified: 2018-04-11 16:24 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-09-09 15:34:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.