creating a correct <chroot>/etc/resolv.conf does not appear to solve as
later a failure executing up/down script is logged, probably for the
same reason, missing necessary commands in chrooted environment

Feb  5 19:04:56 gubuntu nm-openvpn[10195]: [myserver.vpn.net] Peer Connection 
Initiated with [AF_INET]300.380.432.561:1300
Feb  5 19:04:58 gubuntu nm-openvpn[10195]: Preserving previous TUN/TAP 
instance: tun0
Feb  5 19:04:58 gubuntu nm-openvpn[10195]: 
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --bus-name 
org.freedesktop.NetworkManager.openvpn.Connection_8 --tun -- tun
0 1500 1558 10.10.0.36 255.255.0.0 restart
Feb  5 19:04:58 gubuntu nm-openvpn[10195]: WARNING: Failed running command 
(--up/--down): could not execute external program
Feb  5 19:04:58 gubuntu nm-openvpn[10195]: Exiting due to fatal error

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

Reply via email to