Skip to content
GitLab
Closed
Issue created by François Kooman@fkooman

DNS leak when using systemd-resolved

When the system uses systemd-resolved, like Ubuntu 18.04 LTS (network-manager-openvpn 1.8.2-1), connecting to the VPN where all traffic is supposed to go over the VPN, will potentially lead to DNS leaks.

This is because systemd-resolved will just add the VPN DNS servers to its list of available DNS servers. This is documented here in poettering's comment.

Example output of systemd-resolve --status:

Link 3 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.87.106.106
                      192.87.36.36
                      2001:610:1:800a:192:87:106:106
                      2001:610:3:200a:192:87:36:36

Link 2 (ens3)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.122.1

You can see that tun0 properly has the DNS servers configured, but that 192.168.122.1 is also still a valid DNS server. It will be used as systemd-resolved will send out DNS queries in parallel and take the fastest answer.

In order to prevent this, on systems using systemd-resolved it is necessary to set the "DNS Domain" to ~. using systemd-resolve -i tun0 --set-domain=~. where tun0 is the VPN interface.

Link 3 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.87.106.106
                      192.87.36.36
                      2001:610:1:800a:192:87:106:106
                      2001:610:3:200a:192:87:36:36
          DNS Domain: ~.

Now the DNS leak is prevented as all DNS queries will go over tun0.

In order to resolve this, I guess it would make sense for this plugin to detect if systemd-resolved is used, if that is true, and the VPN connection is used as "default gateway", the DNS Domain should be set to ~..

Another approach would be to support re-using the Windows DHCP option --block-outside-dns, but that may require patching OpenVPN as well as it currently shows a warning in the OpenVPN log when pushed to Linux clients, so not sure if this option is then available to e.g. NM-openvpn.

An even different approach could be to 'natively' support the DHCP option DOMAIN-ROUTE as is done by the often recommended openvpn-systemd-resolved script.

Edited by François Kooman