I am seeing this with 64-bit 14.04.5 (even though 'grheard' did not have
this problem with 14.04) using OpenVPN via the network manager. Seems to
happen independently of DHCP renewals as several were logged before this
last bit:
Feb 23 19:31:03 paul-ubuntu dhclient: DHCPREQUEST of 192.168.1.100 on eth1 to
192.168.1.1 port 67 (xid=0xacb31f1)
Feb 23 19:31:03 paul-ubuntu dhclient: DHCPACK of 192.168.1.100 from 192.168.1.1
Feb 23 19:31:03 paul-ubuntu dhclient: bound to 192.168.1.100 -- renewal in 1379
seconds.
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> (eth1): DHCPv4 state
changed renew -> renew
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> address 192.168.1.100
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> prefix 24
(255.255.255.0)
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> gateway 192.168.1.1
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> hostname 'Desktop'
Feb 23 19:31:03 paul-ubuntu NetworkManager[1577]: <info> nameserver
'192.168.1.1'
Feb 23 19:31:03 paul-ubuntu dbus[1306]: [system] Activating service
name='org.freedesktop.nm_dispatcher' (using servicehelper)
Feb 23 19:31:03 paul-ubuntu dbus[1306]: [system] Successfully activated service
'org.freedesktop.nm_dispatcher'
Feb 23 19:34:32 paul-ubuntu nm-openvpn[2357]: [server] Inactivity timeout
(--ping-restart), restarting
Feb 23 19:34:32 paul-ubuntu nm-openvpn[2357]: SIGUSR1[soft,ping-restart]
received, process restarting
Feb 23 19:34:34 paul-ubuntu nm-openvpn[2357]: NOTE: the current
--script-security setting may allow this configuration to call user-defined
scripts
Feb 23 19:34:54 paul-ubuntu nm-openvpn[2357]: RESOLVE: Cannot resolve host
address: <redacted>: Temporary failure in name resolution
This fault continued through several more DHCP renewals until I manually
reset the link:
Feb 23 23:04:11 paul-ubuntu nm-openvpn[2357]: message repeated 502 times: [
RESOLVE: Cannot resolve host address: <redacted>: Temporary failure in name
resolution]
Feb 23 23:04:26 paul-ubuntu nm-openvpn[2357]: RESOLVE: signal received during
DNS resolution attempt
Feb 23 23:04:26 paul-ubuntu avahi-daemon[1439]: Withdrawing workstation service
for tun0.
Feb 23 23:04:26 paul-ubuntu NetworkManager[1577]: SCPlugin-Ifupdown: devices
removed (path: /sys/devices/virtual/net/tun0, iface: tun0)
So manually disconnecting and reconnecting the VPN works, but is
obviously not a satisfactory solution for machines that are normally
unattended or if you wish to maintain privacy!
System details:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
$ apt-cache policy openvpn
openvpn:
Installed: 2.3.2-7ubuntu3.1
Candidate: 2.3.2-7ubuntu3.1
Version table:
*** 2.3.2-7ubuntu3.1 0
500 http://gb.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64
Packages
500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64
Packages
100 /var/lib/dpkg/status
2.3.2-7ubuntu3 0
500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager-openvpn in Ubuntu.
https://bugs.launchpad.net/bugs/1586570
Title:
openvpn chroot does not have a valid resolv.conf
Status in network-manager-openvpn package in Ubuntu:
Confirmed
Bug description:
If you leave openvpn running for long enough it will eventually begin
to fail with output like:
May 27 19:16:54 wakko nm-openvpn[16480]: RESOLVE: Cannot resolve host
address: XXXX: Temporary failure in name resolution
Analysis shows this is because openvpn is sending DNS queries to
127.0.0.1:
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 8
connect(8, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
poll([{fd=8, events=POLLOUT}], 1, 0) = 1 ([{fd=8, revents=POLLOUT}])
sendto(8, ..., 30, MSG_NOSIGNAL, NULL, 0) = 30
However, this is not correct, dnsmasq listens on 127.0.1.1.
It appears the a cause of this is the chroot, the chroot has no
resolv.conf in it and the glibc default is to use 127.0.0.1
openvpn does a DNS query before chroot'ing which used to be enough to
cache resolv.conf forever. I wonder if something has changed in glibc
recently to cause the resolv.conf to be reloaded (eg Debian apparently
has a patch that does this)
A work around would be to copy the system resolv.conf into
/var/lib/openvpn/chroot before starting openvpn
Seen on Xenial and a few prior versions.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1586570/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
