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