Project

General

Profile

Bug #3615

DNS resolution not via VPN when using systemd-resolved and the NetworkManager plugin

Added by Peter Beurle 9 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Category:
networkmanager (charon-nm)
Target version:
Start date:
Due date:
Estimated time:
Affected version:
5.9.0
Resolution:
Fixed

Description

I am using a Fedora 33 road warrior laptop that connects to a pfsense strongSwan based ipsec VPN implementation. On the laptop the strongSwan NetworkManager packages are installed and it I use the gnome gui to turn VPN on and off. Since the upgrade to 33 VPN DNS names will not resolve. This is the same for a couple of years with Ubuntu [[https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1783377]]

After some reading it seems that the resolver (systemd-resolved) will select any DNS server, not the VPN one. Restarting resolved after connecting to the VPN puts the VPN DNS at the top of the list and it works. Poettering believes all DNS servers should be equal.

You can have different DNS per interface and this seems to be done to stop dns leaks.

It seems to me that we need to create a XFRM interface and associate the VPN domain to that interface so DNS works again?

Associated revisions

Revision aa3d5bf7 (diff)
Added by Tobias Brunner 7 months ago

Revert "nm: Remove dummy TUN device"

This reverts commit a28c6269a4aeb5369fed8933fa1baf0cd8847622.

We add a dummy TUN device again because systemd-resolved insists on
managing DNS servers per interface.

Fixes #3615.

History

#1 Updated by Tobias Brunner 9 months ago

  • Category set to networkmanager (charon-nm)
  • Status changed from New to Feedback

While some aspects of systemd-resolved are OK, associating DNS servers with interfaces make no sense, you need a destination IP to select a route/interface in the first place.

From my experience, configuring ~. in "Additional search domains" in the IPv4 settings of the VPN connection (e.g. via nmcli connection modify <name> ipv4.dns-search '~.') and restarting systemd-resolved when the VPN is established via script in /etc/NetworkManager/dispatcher.d/pre-up.d e.g.

#!/bin/bash
if [ "$2" == "vpn-pre-up" ]; then
   echo "Restart systemd-resolved to fix VPN DNS lookups" 
   /bin/systemctl restart systemd-resolved
fi

seems to work.

#2 Updated by Tobias Brunner 8 months ago

I pushed a commit to the 3615-nm-interface branch that reintroduces the dummy TUN device in our NM plugin that was removed with 5.5.2 (after being added with 5.0.3 as a workaround for NM issues). At least older NM versions still need manually setting search domains to ~., but then it seems to work fine without script and systemd-resolved associates the DNS servers with the TUN device and uses them as expected.

#3 Updated by Tobias Brunner 7 months ago

  • Tracker changed from Issue to Bug
  • Subject changed from systemd resolved to DNS resolution not via VPN when using systemd-resolved and the NetworkManager plugin
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Target version set to 5.9.2
  • Resolution set to Fixed

#4 Updated by Mirek Svoboda 5 months ago

Another workaround for this issue in Fedora 33 is to bypass systemd-resolved resolver, while still letting it set DNS servers.
It is done with the following command:

sudo ln -sfv /run/systemd/resolve/resolv.conf /etc/resolv.conf

Explanation from

man systemd-resolved

is this:
systemd-resolved maintains the /run/systemd/resolve/resolv.conf file for compatibility with traditional Linux programs. This
           file may be symlinked from /etc/resolv.conf and is always kept up-to-date, containing information about all known DNS
           servers. Note the file format's limitations: it does not know a concept of per-interface DNS servers and hence only contains
           system-wide DNS server definitions. Note that /run/systemd/resolve/resolv.conf should not be used directly by applications,
           but only through a symlink from /etc/resolv.conf. If this mode of operation is used local clients that bypass any local DNS
           API will also bypass systemd-resolved and will talk directly to the known DNS servers.

#5 Updated by Peter Beurle about 2 months ago

Fedora finally got strongswan 5.9.2 into the testing repository in the last few days and I can confirm everything works with VPN name resolution again (without any workarounds).

Thanks for getting this fixed.

Also available in: Atom PDF