What does that rls-bb-notfixing tag mean? This is just a bug that won't be fixed? Split tunnel DNS with openconnect is still completely broken in 19.04 and it would be very nice to have this working. The last couple years of Ubuntu releases have required me to ditch systemd- resolved in order to access my company's internal services while remote.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1726124 Title: DNS domain search paths not updated when VPN started Status in network-manager package in Ubuntu: Confirmed Status in network-manager-openvpn package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I connect to work with openvpn through network-manager-openvpn. I'm selecting automatic (DHCP) to get an IP address, and "Use this connection only for resources on its network" to support split tunneling. In the last few versions of Ubuntu I used, this all worked fine. In Ubuntu 17.10 (fresh install, not upgrade) I can access hosts on both my VPN network and the internet, BUT I have to use FQDN for my VPN network hosts: the updates to the DNS search path provided by my VPN DHCP server are never being applied. Investigating the system I see that /etc/resolv.conf is pointing to /run/systemd/resolve/stub-resolv.conf and that resolv.conf does not have any of the VPN's search path settings in it: # This file is managed by man:systemd-resolved(8). Do not edit. # # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 search home In previous versions of Ubuntu, where NetworkManager controlled the resolver not systemd, /etc/resolv.conf pointed to /run/NetworkManager/resolv.conf and there was a local dnsmasq instance that managed all the complexity. In Ubuntu 17.10 when I look in /run/NetworkManager/resolv.conf file, I see that the search paths ARE properly updated there: $ cat /run/NetworkManager/resolv.conf # Generated by NetworkManager search internal.mycorp.com other.mycorp.com home nameserver 127.0.1.1 However this file isn't being used, and also there's no dnsmasq running on the system so if I switch my /etc/resolv.conf to point to this file instead, then all lookups fail. Strangely, if I look at the systemd-resolv status I see that in theory systemd-resolve does seem to know about the proper search paths: $ systemd-resolve --status ... Link 3 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.3.0.10 10.8.42.2 DNS Domain: ~internal.mycorp.com ~other.mycorp.com but for whatever reason the search domains are not getting put into the resolv.conf file: $ host mydesk ;; connection timed out; no servers could be reached $ host mydesk.internal.mycorp.com mydesk.internal.mycorp.com has address 10.8.37.74 (BTW, the timeout in the failed attempt above takes 10s: it is SUPER frustrating when all your host lookups are taking that long just to fail). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: systemd 234-2ubuntu12 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 22 15:08:57 2017 InstallationDate: Installed on 2017-10-21 (1 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) MachineType: System manufacturer System Product Name ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic root=UUID=4384306c-5fed-4b48-97a6-a6d594c4f72b ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/02/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2101 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M/USB3 dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr2101:bd12/02/2014:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-M/USB3:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1726124/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp