After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 641593 - DNS issue when VPN active
DNS issue when VPN active
Status: RESOLVED NOTGNOME
Product: NetworkManager
Classification: Platform
Component: general
0.8.x
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2011-02-05 09:56 UTC by Yongzhi Pan
Modified: 2011-04-15 22:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Yongzhi Pan 2011-02-05 09:56:01 UTC
I am using Network Manager to connect to my OpenVPN server. When I use the openvpn command line client, DNS push is fine, resolv.conf is updated to the pushed DNS servers (old lines gone). When I use NM, resolv.conf is not written corretly. The OpenVPN server pushes 4 DNS server, but only the first one is appended to resolv.conf. It should remove the old lines and add the 4 servers from the OpenVPN server to resolv.conf.

My daemon.log after connecting:

Sep 29 18:26:13 pan-desktop NetworkManager[720]: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'...
Sep 29 18:26:13 pan-desktop NetworkManager[720]: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 5898
Sep 29 18:26:13 pan-desktop NetworkManager[720]: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' appeared, activating connections
Sep 29 18:26:13 pan-desktop NetworkManager[720]: <info> VPN plugin state changed: 1
Sep 29 18:26:13 pan-desktop NetworkManager[720]: <info> VPN plugin state changed: 3
Sep 29 18:26:13 pan-desktop NetworkManager[720]: <info> VPN connection 'VPN 连接 1' (Connect) reply received.
Sep 29 18:26:13 pan-desktop nm-openvpn[5901]: OpenVPN 2.1.0 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 12 2010
Sep 29 18:26:13 pan-desktop nm-openvpn[5901]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sep 29 18:26:13 pan-desktop nm-openvpn[5901]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 29 18:26:13 pan-desktop nm-openvpn[5901]: /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Sep 29 18:26:14 pan-desktop nm-openvpn[5901]: LZO compression initialized
Sep 29 18:26:14 pan-desktop nm-openvpn[5901]: UDPv4 link local: [undef]
Sep 29 18:26:14 pan-desktop nm-openvpn[5901]: UDPv4 link remote: [AF_INET]<server_ip>:1194
Sep 29 18:26:18 pan-desktop nm-openvpn[5901]: [server] Peer Connection Initiated with [AF_INET]<server_ip>:1194
Sep 29 18:26:20 pan-desktop modem-manager: (net/tun0): could not get port's parent device
Sep 29 18:26:20 pan-desktop NetworkManager[720]: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
Sep 29 18:26:20 pan-desktop NetworkManager[720]: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
Sep 29 18:26:21 pan-desktop nm-openvpn[5901]: TUN/TAP device tun0 opened
Sep 29 18:26:21 pan-desktop nm-openvpn[5901]: /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu 1500
Sep 29 18:26:21 pan-desktop nm-openvpn[5901]: /usr/lib/network-manager-openvpn/nm-openvpn-service-openvpn-helper tun0 1500 1542 10.8.0.6 10.8.0.5 init
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> VPN connection 'VPN 连接 1' (IP Config Get) reply received.
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> VPN Gateway: <server_ip>
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal Gateway: 10.8.0.5
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Tunnel Device: tun0
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 Address: 10.8.0.6
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 Prefix: 32
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 Point-to-Point Address: 10.8.0.5
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Maximum Segment Size (MSS): 0
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Static Route: 10.8.0.1/32 Next Hop: 10.8.0.1
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 DNS: 4.2.2.1
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 DNS: 4.2.2.2
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 DNS: 4.2.2.3
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> Internal IP4 DNS: 208.67.220.220
Sep 29 18:26:21 pan-desktop NetworkManager[720]: <info> DNS Domain: '(none)'
Sep 29 18:26:21 pan-desktop nm-openvpn[5901]: Initialization Sequence Completed
Sep 29 18:26:22 pan-desktop NetworkManager[720]: <info> (tun0): writing resolv.conf to /sbin/resolvconf
Sep 29 18:26:22 pan-desktop NetworkManager[720]: <info> VPN connection 'VPN 连接 1' (IP Config Get) complete.
Sep 29 18:26:22 pan-desktop NetworkManager[720]: <info> (tun0): writing resolv.conf to /sbin/resolvconf
Sep 29 18:26:22 pan-desktop NetworkManager[720]: <info> Policy set 'VPN 连接 1' (tun0) as default for IPv4 routing and DNS.
Sep 29 18:26:22 pan-desktop NetworkManager[720]: <info> VPN plugin state changed: 4
Sep 29 18:26:22 pan-desktop nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.

My daemon.log after disconnecting:

Sep 29 18:28:14 pan-desktop nm-openvpn[5901]: /sbin/ifconfig tun0 0.0.0.0
Sep 29 18:28:14 pan-desktop NetworkManager[720]: <info> (tun0): writing resolv.conf to /sbin/resolvconf
Sep 29 18:28:14 pan-desktop avahi-daemon[726]: Withdrawing workstation service for tun0.
Sep 29 18:28:14 pan-desktop nm-openvpn[5901]: SIGTERM[hard,] received, process exiting
Sep 29 18:28:16 pan-desktop NetworkManager[720]: <info> (ppp0): writing resolv.conf to /sbin/resolvconf
Sep 29 18:28:16 pan-desktop NetworkManager[720]: <info> Policy set 'DSL 连接 1' (ppp0) as default for IPv4 routing and DNS.
Sep 29 18:28:16 pan-desktop NetworkManager[720]: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/tun0, iface: tun0)
Sep 29 18:28:16 pan-desktop nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1.

I am using Maverick beta, NM 0.8.1. I think the problem is at this file http://is.gd/fzBN8.
Comment 1 Yongzhi Pan 2011-02-05 09:57:07 UTC
My resolv.conf before VPN connection:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 221.7.34.10
nameserver 221.7.34.11

My resolv.conf after VPN connection:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 221.7.34.10
nameserver 221.7.34.11
nameserver 4.2.2.1

This is useless, since I want to use 4.2.2.1 (DNS from VPN), but servers in effect is old ones (though available).
Comment 2 Yongzhi Pan 2011-02-05 09:58:21 UTC
The two original DNS is provided by my ISP, they poisoned youtube, facebook and twitter (at least these three) DNS records. I have to use the VPN DNS and remove the old ones.

If I use the openvpn command line client with the same client config file, My resolv.conf after VPN connection is:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 4.2.2.1
nameserver 4.2.2.2
nameserver 4.2.2.3

This is what I want. This is handled by /etc/openvpn/update-resolv-conf shell script distributed in the openvpn-client package.
Comment 3 Yongzhi Pan 2011-02-05 09:59:36 UTC
My point is NM and OpenVPN client should have a consistent way to deal with VPN DNS. This bug was reported at launchpad last October at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/651007 .
Comment 4 Dan Williams 2011-02-24 00:44:40 UTC
So the logs indicate that nm-openvpn is correctly passing back nameservers to NetworkManager.  The problem appears to be in setting resolv.conf.

First thing to try:  move /sbin/resolvconf out of the way and try connecting to the VPN.  Does that work correctly?  If so, you may want to either un-install resolvconf, or modify the resolvconf rules to ensure the NetworkManager DNS information is honored.  NetworkManager handles all DNS updates itself, and when NM is running resolvconf isn't usually required, but it's installed sometimes anyway.  resolvconf has its own configuration that can cause /etc/resolv.conf to not reflect the DNS servers that NM knows are good.
Comment 5 Fabio Durán Verdugo 2011-04-11 13:43:32 UTC
@pan any news for the report?
Comment 6 Yongzhi Pan 2011-04-12 03:14:16 UTC
Sorry for the procrastination. I thought I have to change my network cable connection to test.

Now, I am using a newly installed Ubuntu 10.10. I have not installed resolvconf on it, and the result is OK:

Before VPN connection:

$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 202.106.46.151
nameserver 202.106.195.68

After VPN connection:

$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 8.8.4.4
nameserver 8.8.8.8
nameserver 202.106.46.151
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 202.106.195.68

Then I install resolvconf and retry, the it is like what I reported:

Before VPN connection:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 202.106.46.151
nameserver 202.106.195.68

After VPN connection:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 202.106.46.151
nameserver 202.106.195.68
nameserver 8.8.4.4

When I was filing the bug, there must be resolvconf installed on the computer. I think this can be closed.
Comment 7 Dan Williams 2011-04-15 22:35:59 UTC
Ok, thanks.