DNS suffix not added to /etc/resolv.conf

[woprandi]

Hi,

The DNS suffix seems not added to /etc/resolv.conf despite being received by the server :

NetworkManager logs

déc. 03 22:47:42 william-laptop NetworkManager[3009]: INFO: Connected to gateway.
déc. 03 22:47:42 william-laptop NetworkManager[3009]: INFO: Authenticated.
déc. 03 22:47:43 william-laptop NetworkManager[3009]: INFO: Remote gateway has allocated a VPN.
déc. 03 22:47:43 william-laptop pppd[3010]: Plugin /usr/lib64/pppd/2.4.8/nm-fortisslvpn-pppd-plugin.so loaded.
déc. 03 22:47:43 william-laptop NetworkManager[3010]: Plugin /usr/lib64/pppd/2.4.8/nm-fortisslvpn-pppd-plugin.so loaded.
déc. 03 22:47:43 william-laptop pppd[3010]: pppd 2.4.8 started by root, uid 0
déc. 03 22:47:43 william-laptop pppd[3010]: Using interface ppp0
déc. 03 22:47:43 william-laptop NetworkManager[3010]: Using interface ppp0
déc. 03 22:47:43 william-laptop NetworkManager[3010]: Connect: ppp0 <--> /dev/pts/2
déc. 03 22:47:43 william-laptop NetworkManager[3010]: {/tmp/.JS23U0} {/tmp}
déc. 03 22:47:43 william-laptop NetworkManager[3010]: {/tmp/.JS23U0} {.JS23U0}
déc. 03 22:47:43 william-laptop pppd[3010]: Connect: ppp0 <--> /dev/pts/2
déc. 03 22:47:43 william-laptop NetworkManager[807]: [1607032063.2143] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/9)
déc. 03 22:47:43 william-laptop NetworkManager[3009]: INFO: Got addresses: [192.168.7.1], ns [10.64.0.2, 10.64.0.3], ns_suffix [fr.otera.lan]
déc. 03 22:47:43 william-laptop NetworkManager[3009]: INFO: Negotiation complete.
déc. 03 22:47:44 william-laptop NetworkManager[3009]: INFO: Negotiation complete.
déc. 03 22:47:44 william-laptop NetworkManager[3010]: Failed to create /var/run/ppp/resolv.conf: No such file or directory
déc. 03 22:47:44 william-laptop pppd[3010]: Failed to create /var/run/ppp/resolv.conf: No such file or directory
déc. 03 22:47:44 william-laptop pppd[3010]: local IP address 192.168.7.1
déc. 03 22:47:44 william-laptop NetworkManager[3010]: local IP address 192.168.7.1
déc. 03 22:47:44 william-laptop NetworkManager[3010]: remote IP address 192.0.2.1
déc. 03 22:47:44 william-laptop NetworkManager[3010]: primary DNS address 10.64.0.2
déc. 03 22:47:44 william-laptop NetworkManager[3010]: secondary DNS address 10.64.0.3
déc. 03 22:47:44 william-laptop pppd[3010]: remote IP address 192.0.2.1
déc. 03 22:47:44 william-laptop pppd[3010]: primary DNS address 10.64.0.2
déc. 03 22:47:44 william-laptop pppd[3010]: secondary DNS address 10.64.0.3
déc. 03 22:47:44 william-laptop pppd[3010]: Can't execute /etc/ppp/ip-up: Permission denied
déc. 03 22:47:44 william-laptop NetworkManager[807]: [1607032064.7346] device (ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
déc. 03 22:47:44 william-laptop NetworkManager[3010]: Can't execute /etc/ppp/ip-up: Permission denied
déc. 03 22:47:44 william-laptop NetworkManager[807]: [1607032064.7498] vpn-connection[0x55e82d48c340,335dd492-c1c9-4a39-b0e1-654e2c692491,"O'tera",0]: VPN connection: (IP4 Config Get) reply received from old-style plugin
déc. 03 22:47:44 william-laptop NetworkManager[3009]: INFO: Interface ppp0 is UP.
déc. 03 22:47:44 william-laptop NetworkManager[3009]: INFO: Tunnel is up and running.

/etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad
search home

I had to add suffix myself to my NetworkManager VPN connection

I tested on Windows with the official Forticlient, it works out of the box

Fedora 33
openfortivpn 1.14.1

[DimitriPapadopoulos]

Yes, these DNS issues will happen more and more often with recent versions of Linux. See all the previous tickets about that.

Even the official FortiClient does not get it right on Linux by the way, I've just noticed there are DNS leaks with FortiClient.

[DimitriPapadopoulos]

In your specific case you're using NetworkManager as far as I can see. Therefore it's not an openfortivpn issue, if needed please report this issue to NetworkManager-fortisslvpn maintainers.

However it might be OK that /etc/resolv.conf is not updated on Fedora 33. I wouldn't expect /etc/resolv.conf to be updated. What's your actual problem?

[woprandi]

Yes, these DNS issues will happen more and more often with recent versions of Linux

Why ?

/etc/resolv.conf is updated when I add suffix myself. I guess it's because of the migration to systemd-resolved

[angystardust]

@woprandi you're right. Since Fedora 33, systemd-resolved is enabled by default so you don't have to edit manually /etc/resolv.conf file. I'm also having issues with F33 and fortivpn with the DNS configuration.
My workaround was to create a resolv.conf with the parameters of my corporate DNS servers.
For example:

search mycorp.int
search mycorp.dmz
nameserver 10.10.10.1
nameserver 10.10.10.2

and then launch the following command after establishing the vpn connection (you can do them both via gnome gui or via cli):

sudo resolvconf -a ppp0 < resolv.conf

I know that ideally this should be managed automatically but it seems that there's some bad interaction between openfortivpn and systemd-resolved...

[woprandi]

@angystardust I didn't edit /etc/resolv.conf myself, I used the Plasma applet (or nmcli) and that modified /etc/NetworkManager/system-connection/<connection>.nmconnection
Anyway, I'm not able to have working VPN DNS without add this suffix. resolvectl dns returned empty otherwise.

[DimitriPapadopoulos]

@woprandi As already explained you need to talk to the NetworkManager-fortisslvpn maintainers if you are using NetworkManager, because in that case it's really not an openfortivpn issue.

On the other hand I can help you get openfortivpn to work from the command line if you're interested - but again that's different from getting NetworkManager-fortisslvpn to work.

[woprandi]

@DimitriPapadopoulos Already done https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/36

[DimitriPapadopoulos]

@woprandi Excellent! Unfortunately it may take months before NetworkManager-fortisslvpn issues are addressed.

But again I suspect /etc/resolv.conf does not necessarily need to be updated on Fedora 33. Indeed Fedora 33 uses nss-resolv instead of the traditional nss-dns:
https://fedoraproject.org/wiki/Changes/systemd-resolved

You should instead focus on the actual symptoms you experience instead. I'll follow up on in https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/36.

[woprandi]

@DimitriPapadopoulos I'd be interested to have your help to get openfortivpn work without NetworkManager to exonerate it completely

[DimitriPapadopoulos]

Sure, note however that when NetworkManager is enabled, the proper way to apply DNS changes really would be to use NetworkManager. Also note that even if we weren't able to get openfortivpn to work from the command line, it would still be a NetworkManager issue. Indeed, NetworkManager-fortisslvpn calls openfortivpn with the --no-dns option and manages changes related to routing/DNS directly.

There are two issues to consider with Fedora 33:

1. Because systemd-resolved is enabled, any direct changes to /etc/resolv.confmight be overwritten the second they're applied.
2. I consider the resolveconf executable bundled with systemd-resolved to be broken because it works only with the systemd-resolved backend. However, in the case of Fedora 33 the backend is precisely systemd-resolved so I expect resolveconf to do the right thing.

[DimitriPapadopoulos]

Let's first make sure which resolveconf is installed on your system:

which resolveconf
dnf provides `which resolveconf`

[DimitriPapadopoulos]

Then let's make sure systemd-resolved is enabled:

which resolvectl
resolvectl status
sudo systemctl is-active systemd-resolved

[woprandi]

Well, I did some investigation and I misspoke : I have dns issue only since I enabled split tunneling.
Without, resolvectl dnf display dns correctly

[DimitriPapadopoulos]

Ah, split DNS is currently not supported, see #561.

While we cannot easily fix this without adding support for NetworkManager or systemd-resolved, we can at least parse the relevant information received from the FortiGate and print it to stdout so that at least the maintainers of NetworkManager-fortivpnssl can start working on split DNS support if they wish so.

[woprandi]

It works if I define DNS suffix domain myself. I opened a issue in the RedHat bugtracker : https://bugzilla.redhat.com/show_bug.cgi?id=1905739

[DimitriPapadopoulos]

@woprandi Yet I suspect this is, at least partly, an openfortivpn issue: openfortivpn does not parse the split DNS parameters sent by the Fortigate appliance and therefore NetworkManager-fortivpnssl cannot aware be of these parameters

If you run openpfortivpn -v -v from the command line you should see an XML line with all the routing and DNS parameters from the Fortigate. What does that line look like?

As explained in #561, openfortivpn currently parses these XML elements:
<dns ip='...' />
<dns domain='... />
but not this XML element:
<split-dns domains='...,...' dnsserver1='...' dnsserver2='...' />

[woprandi]

Apparently I don't have split-dns element :

<?xml version='1.0' encoding='utf-8'?><sslvpn-tunnel ver='2' dtls='1' patch='1'><dtls-config heartbeat-interval='10' heartbeat-fail-count='10' heartbeat-idle-timeout='10' client-hello-timeout='10' /><tunnel-method value='ppp' /><tunnel-method value='tun' /><fos platform='FGT90D' major='6' minor='00' patch='6' build='0272' branch='0272' /><client-config save-password='off' keep-alive='off' auto-connect='off' /><ipv4><dns domain='fr.otera.lan' /><dns ip='10.64.0.2' /><dns ip='10.64.0.3' /><assigned-addr ipv4='192.168.7.1' /><split-tunnel-info><addr ip='....' mask='255.255.255.255' /><addr ip='10.0.0.0' mask='255.0.0.0' /></split-tunnel-info></ipv4><idle-timeout val='600' /><auth-timeout val='28800' /></sslvpn-tunnel>

[DimitriPapadopoulos]

Strange. Indeed, openfortivpn will ignore this part of the XML configuration:

<split-tunnel-info><addr ip='....' mask='255.255.255.255' /><addr ip='10.0.0.0' mask='255.0.0.0' /></split-tunnel-info>

Yet is this enough to explain the issues you're experiencing? I would be surprised because at first sight it seems unrelated to DNS.

In any case these XML elements should be taken into account and passed over to NetworkManager-fortivpnssl:
<dns domain='fr.otera.lan' />
<dns ip='10.64.0.2' />
<dns ip='10.64.0.3' />
You should be able to see them in the openfortivpn output:
INFO: Got addresses: [...], ns [10.64.0.2, 10.64.0.3], ns_suffix [fr.otera.lan]

We could try a different angle. Do you see a DNS related difference in the XML configuration sent by the Fortigate appliance between split tunnel (doesn't work) and no split tunnel (does work)?

[woprandi]

How am I supposed to enable/disable split tunnel ?

[mrbaseman]

it's a configuration option of the so-called web-portal offered by the fortigate

[DimitriPapadopoulos]

@woprandi Any news about this issue?

[woprandi]

I don't handle firewall configuration so I'd need to contact the maintainer. I'll try to do that next week. If I'd not been able to progress, I close the issue.