DNS from VPN not being added properly to resolv.conf on Ubuntu 22.04

[Shadowfury22]

First of all, I should probably note that I'm running openfortivpn version 1.20.5 as it's the latest one I could find for Ubuntu 22.04.

For reference, I'm using the uplink mode of resolvectl instead of the default one (stub) due to unrelated reasons:

juanmi@juanmi-t14:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: uplink

Link 2 (enp0s31f6)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp0s20f3)
Current Scopes: DNS
     Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 1.1.1.1 1.0.0.1 2606:4700:4700::1111

juanmi@juanmi-t14:~$ ll /etc/resolv.conf
lrwxrwxrwx 1 root root 34 dic 15 09:44 /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf

juanmi@juanmi-t14:~$ cat /etc/resolv.conf
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 2606:4700:4700::1111
search .

All of my Ubuntu network config is set to automatic/default - those cloudflare DNS are getting grabbed directly from my router.

So here's what happens to the file once I connect through openfortivpn:

juanmi@juanmi-t14:~$ cat /etc/resolv.conf 
nameserver 192.168.xxx.xxx
nameserver 192.168.yyy.yyy
search xxxxxxxxx.com 168.192.in-addr.arpa
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 2606:4700:4700::1111
search .

As you can see, the lines are getting added on top of the file. This is fine for the nameservers but not for the search domains. With this resulting file I cannot ping most of the servers I need to connect to. However, if I remove the very last line, then it works perfectly fine.

So the problem here seems to be that openfortivpn is not replacing the "search" line with the new one, but instead adding an additional line which can lead to faulty DNS behaviour.

[DimitriPapadopoulos]

Ideally you should build openfortivpn 1.21 from sources, although I doubt that would change anything on Ubuntu 22.04.

As explained elsewhere, there are 3 ways openfortivpn handles DNS settings:

1. With --set-dns=1 openfortivpn may try to directly modify /etc/resolv.conf which is a bad idea on contemporary Linux distributions but still works, more or less.
2. With --set-dns=1 and /usr/sbin/resolvconf will let resolvconf handle DNS settings.
3. With --pppd-use-peerdns=1 openfortivpn will let pppd handle DNS settings.

I understand you're in case 1. Verbose logs would help confirm such details. What is the output of the following?

ls -l /usr/sbin/resolvconf
dpkg -S /usr/sbin/resolvconf

I would recommend case 2, in which case it's up to resolvconf to set DNS properly. Actually, 3 different versions of resolvconf exist:
a. Usually systemd-resolved provides its own version of resolvconf, as a symlink to resolvectl. I believe it is not available on Debian and Ubuntu.
b. Debian and Ubuntu have their own version of resolvconf, packaged as resolvconf.
c. An alternative available on all or most Linux distributions is openresolv.

On Ubuntu, I would recommend you try case 2, with resolvconf provided by resolvconf (b) or openresolv (c).

[DimitriPapadopoulos]

With that said, what is wrong with adding the following at the top of /etc/resolv.conf?

nameserver 192.168.xxx.xxx
nameserver 192.168.yyy.yyy
search xxxxxxxxx.com 168.192.in-addr.arpa

In theory, we only add what the the FortiGate instructs us to. A verbose log, redacted if needed, as suggested in Reporting issues, would show the XML configuration sent by the FortiGate. Chances are the FortiGate is not properly configured.

[Shadowfury22]

Oh, the lines that are being added to my resolv.conf by openfortivpn are fine themselves. The problem is that nothing else is being done to the file, which ends up having two lines with a search.

See, when I was using FortiClient, it replaced the default search line with the new one upon connecting, which made everything work for me out of the box. The behaviour I'm observing here after having switched to openfortivpn is a different one and I've confirmed that getting rid of the old search line fixes the VPN DNS.

The only way I'm currently able to connect to my servers via openfortivpn is by manually editing resolv.conf (replacing the last line with the 3rd one) every time after connecting to the VPN.

All I'm asking you is to please consider this scenario. If you think emulating the FortiClient behaviour by properly replacing the existing search line on resolv.conf would be a good addition to openfortivpn, it will save me having to manually edit the file everyday 🙏

[Shadowfury22]

Oh, I'm sorry, I didn't notice your previous comment and only read the latest one.

I actually tried the snap version from the latest/edge channel, which seemed to be the most updated of them all (1.21.0), but it was giving me permission errors when trying to access any file (not only /etc/resolv.conf but also /etc/openfortivpn/config) so I gave up with that one. If push comes to shove, I'll look into building the thing from the latest source myself.

I'm indeed in case 1. Getting the resolvconf package sounds interesting. I'll definitely give that a try and report back.

Thanks!

[DimitriPapadopoulos]

It looks like the last and previous line:

search .

takes precedence over the new one:

search xxxxxxxxx.com 168.192.in-addr.arpa

Does that sound right? Not sure why this is not a problem on my own Ubuntu 22.04 machine. I will have to compare.

Do not use openfortivpn snaps. It's impossible to package software so tightly coupled to the OS this way. I have given up and https://snapcraft.io/openfortivpn is completely obsolete.

[Shadowfury22]

I just did some quick testing and it seems like you're completely right.

If I leave both search lines in the file but I move the new one down below the old one, everything works.

Strangely enough though, it seems to be the other way around for the nameserver lines. My DNS only works by having the new nameserver lines up above the old ones.

This file is such a mess. I'm gonna try getting resolvconf and see if that makes it easier.

[Shadowfury22]

Installing resolvconf worked like a charm! (I also had to add "use-resolvconf = 1" to my openfortivpn config file)

The VPN entries are now being properly added and removed into the resolv.conf file (now on foreign mode).

Thanks again for your suggestion!

[sleepmac]

@Shadowfury22 @DimitriPapadopoulos
I have a similar problem. running resolvectl

Link 21 (ppp0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Also added "use-resolvconf = 1" to the config
On successful connection I get the following message
WARN: Ignoring option "use-resolvconf".
But I still can't connect to my working applications.

Can you please tell me if I missed something?

[Shadowfury22]

@sleepmac Did you install resolvconf?