Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • NetworkManager-openvpn NetworkManager-openvpn
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 38
    • Issues 38
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • NetworkManager-openvpnNetworkManager-openvpn
  • Issues
  • #10
Closed
Open
Issue created Oct 03, 2018 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 Oct 03, 2018 by François Kooman
Assignee
Assign to
Time tracking