Ubuntu
network-manager package

networkmanager IKE VPN connection causes DNS leak

Bug #1880864 reported by Fabrice Meyer on 2020-05-27

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	network-manager (Ubuntu)	New	Undecided	Unassigned

Bug Description

Description: Ubuntu 20.04 LTS
Release: 20.04

network-manager:
  Installé : 1.22.10-1ubuntu1
  Candidat : 1.22.10-1ubuntu1
Table de version :
*** 1.22.10-1ubuntu1 500
        500 http://fr.archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

Connecting to a IPSEC IKE VPN does not update correctly update systemd-resolve dns parameters: DNS provided by the VPN tunnel is seen by systemd-resolve but not use to resolve dns queries resulting to a DNS leak. I tried to play with network manager priority which as no effect: default setting seems to be fine as the dns provided by the vpn appears on top of dns list provided by "systemd-resolve --status" result bellow.

I found out a way to get it working by restarting systemd-resolve service after the vpn connection is established. I think (pure speculation, I don't know how systemd-resolve works) systemd-resolve evaluate which dns use, the one provided by the vpn is the first one then it decide to use it. This evaluation should be triggered when tunnel is bringed up.

Bringing up an IPSEC IKE VPN does not create a new interface, it will use the same used by the default network interface where is configured the gateway. I think a fix would be to find out a way to triggered the dns election of systemd-resolve to update the "Current DNS Server".

Maybe it is a bug with systemd-resolve but as I don't know how everything work together, I choose to report this here.

You will find my network manager config for this particular ipsec tunnel bellow.

Before systemctl restart systemd-resolved.service

Global
       LLMNR setting: no
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 2 (eno1)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.10.1
         DNS Servers: 192.168.1.1 #DNS from VPN
                      192.168.10.1 #DNS from DHCP
          DNS Domain: lan
                      ~.

after systemctl restart systemd-resolved.service

Link 2 (eno1)
      Current Scopes: DNS
DefaultRoute setting: yes
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1 #DNS from VPN
                      192.168.10.1 #DNS from DHCP
          DNS Domain: lan
                      ~.

Network Manager config

[connection]
id=SomeNameForThisConnection
uuid=XXXXXXXXXXXX
type=vpn
autoconnect=false
permissions=user:someuser:;
timestamp=1590573570

[vpn]
address=some.vpn.address.com
certificate=/some/cert/for/some.vpn.address.com
encap=no
esp=aes256gcm16-ecp384
ike=aes256-sha256-prfsha256-ecp384
ipcomp=no
method=eap
password-flags=2
proposal=yes
user=some_login
virtual=yes
service-type=org.freedesktop.NetworkManager.strongswan

[ipv4]
dns-search=lan;
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=ignore

[proxy]

Revision history for this message

Fabrice Meyer (faboulous973) wrote on 2020-05-27:

As a workaround, I placed the following script in /etc/NetworkManager/dispatcher.d/02-vpnupdown location. It will restart systemd-resolved service everytime you bring up a vpn connection allowing to use as current dns the one provided by the vpn. I tried to send a SIGRTMIN+1 signal to systemd-resolve to flush dns server but it randomly have the desired effect by cli but never by a script triggered by a vpn-up event from network-manager. On vpn-down event, dns configuration is fine so I won't restart the service to avoid restarting it too often.

Hope this will help someone while this issue is being fixed.

#!/bin/bash

STATUS=$2

case "$STATUS" in
'vpn-up') systemctl restart systemd-resolved;;
esac

Revision history for this message

Sebastien Bacher (seb128) wrote on 2020-06-03:

Thank you for your bug report, could you perhaps report it upstream on

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/ ?