Tim, I have a question for you. When you connect through network-manager-openconnect-gnome, and type systemd-resolve --status, what is your link name called? Something like 'tun0' or 'tap1' or the like?
Because I've been looking around at the openconnect wiki at http://www.infradead.org/openconnect/building.html, and it seems like openconnect requires tun/tap drivers. So theoretically, it should have worked with the original patch containing just the conditional expression: if (link_type == NM_LINK_TYPE_TUN || link_type == NM_LINK_TYPE_TAP) As in, this should evaluate to true as the link should be of type tun or tap. It seems like the updated patch containing the conditional expression if (link_type == NM_LINK_TYPE_TUN || link_type == NM_LINK_TYPE_TAP || link_type == NM_LINK_TYPE_GRE || link_type == NM_LINK_TYPE_GRETAP) might, however, help address users of network-manager-vpnc/network-manager-vpnc-gnome. If anyone uses network-manager-vpnc/network-manager-vpnc-gnome, let me know if the newer patch containing the cases for NM_LINK_TYPE_GRE and NM_LINK_TYPE_GRETAP fixes DNS leaks for you on a Cisco PPTP/IPsec VPN. I am unable to test this out as I don't have access to any such Cisco VPN services. Anyway, if the network manager doesn't correctly register the openconnect interface as being link type TUN or TAP, I don't really know how to fix it as that could be a problem on network-manager- openconnect's end or the result of some way it doesn't properly notify the network manager. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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
