14

I'm using a VPN client which adds two name servers to /etc/resolv.conf. All my connections are managed by Network-Manager.

I have to use this VPN client for my work VPN but after Ubuntu went to systemd-resolved in 16.10 I am having problems with my connection and DNS. Looks like systemd-resolved changes /etc/resolv.conf back to default name servers for some reason which makes internal pages not resolve. I looked into this some more and ended up replacing resolvconf with openresolv. That helped a lot, but still systemd-resolved resets /etc/resolv.conf after the VPN has been up for a while.

It could be just as the connection is up or after a few minutes or sometimes not at all. I then disabled systemd-resolved and the systemd resolvconf.service and only run openresolv. It all works well it seems.

However, this is all very confusing. Is there a reason for using systemd-resolved with one of the others? It was enabled in Ubuntu 16.10 so I thought there must be a reason for it but it seems to cause a fight over /etc/resolv.conf.

It would be great if I could just run operesolv and get this explained. I have done quite a bit of reading on it but I still do not understand why /etc/resolv.conf is managed like it is, only that when I use systemd for it I can't use my VPN client.

1
  • FWIW resolvconf.service is just how systemd operates resolvconf. Which VPN client are you using? If you used systemd-resolved it makes resolv.conf a symlink to it's private /run/systemd/resolve/resolv.conf file. You might want to try having systemd-networkd manage your connections.
    – pbhj
    Commented Jun 10, 2017 at 15:41

3 Answers 3

1

I managed to change the script that handles these configuration items in OpenVPN in Ubuntu (tested on 18.04). Here is a patch for that:

--- /etc/openvpn/update-resolv-conf.orig    2019-03-13 19:14:16.163914424 +0400
+++ /etc/openvpn/update-resolv-conf 2019-03-13 19:29:30.380420708 +0400
@@ -15,7 +15,7 @@
 #     foreign_option_3='dhcp-option DOMAIN be.bnc.ch'
 #

-[ -x /sbin/resolvconf ] || exit 0
+[ -x /usr/bin/systemd-resolve ] || exit 0
 [ "$script_type" ] || exit 0
 [ "$dev" ] || exit 0

@@ -43,16 +43,16 @@
        fi
    done
    R=""
-   [ "$SRCHS" ] && R="search $SRCHS
-"
+   for SRCH in $SRCHS ; do
+       R="${R}--set-domain=$SRCH "
+   done
    for NS in $NMSRVRS ; do
-           R="${R}nameserver $NS
-"
+       R="${R}--set-dns=$NS "
    done
-   echo -n "$R" | /sbin/resolvconf -a "${dev}.openvpn"
+   /usr/bin/systemd-resolve -i ${dev} ${R}
    ;;
   down)
-   /sbin/resolvconf -d "${dev}.openvpn"
+   echo "Doing nothing, interface disappears."
    ;;
 esac

You will need to add the following items to your OpenVPN configuration file:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
0

Which VPN client are you using? I was having trouble with straight OpenVPN, but installing the NM version of the client cleared up the problems. Well, most of them, I could not prevent a route being pushed, but that's a completely different issue.

The point is: your VPN client has to know about how to interact with systemd's idea of how to manage DNS service. I don't recommend this, but you may try to disabling the resolvd service (systemctl disable systemd-resolved.service) to see if it improves things, but ultimately you will have to get a client that understands how to submit to systemd's caprices :)

(The systemd ship sailed a long time ago, let's not open a discussion on why some things were done.)

1
  • This problem got resolved in an update of the VPN client. It was the OpenFortiGui client for my work Fortinet VPN. So you are absolutely right, the client has now learned systemd! :)
    – Christian
    Commented Mar 7, 2019 at 2:34
0

An update to the VPN client I used resolved (pun intended) the problem. It was the OpenFortiGui client for Fortinet VPN.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .