Here is a solution that seems to work for me. Note that I use a simple openvpn client configuration file that I run directly from the console. I don't use a GUI for my vpn connection, but I assume you can do the same via a gui interface.
Within my openvpn client config file, I call a script called update- systemd-resolved as a replacement to the standard update-resolv-conf used previously. That script is available here: https://github.com/jonathanio/update- systemd-resolved After that, after connecting, when I run systemd-resolve --status I can see that a new link is added for tun0 with the proper dns entries. But that's only a first step, because it seems that with systemd.resolved.service (I quote) "Multi-label names are routed to all local interfaces that have a DNS sever configured (...) If lookups are routed to multiple interfaces, the first successful response is returned". So basically it's still sending requests on all interfaces, including the main eth0 or whatever it is on your system, and the fastest one wins (in my case because eth0 points to my router that acts as a dns server, it always wins). To avoid leaks, we want only requests to go to the tun0 link. Then I read that "Routing of lookups may be influenced by configuring per-interface domain names". If you read the instructions in the update-systemd-resolved, you'll see that it allows to specify dhcp- options DOMAIN-ROUTE to force a specific domain to go through that interface. You can use a single dot to mean all domains. So basically I added dhcp-option DOMAIN-ROUTE . to my clienf config to send everything exclusively to tun0 and that seems to do the trick. So combined with the instructions from the github page, this is what I have on my config: # avoid dns leak when using systemd-resolved dhcp-option DOMAIN-ROUTE . script-security 2 setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin up /etc/openvpn/update-systemd-resolved down /etc/openvpn/update-systemd-resolved down-pre -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp