Project

General

Profile

Bug #3615

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

Added by Peter Beurle 3 months ago. Updated 6 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
networkmanager (charon-nm)
Target version:
5.9.2
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 6 days 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 3 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 about 2 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 6 days 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

Also available in: Atom PDF