DNS settings on Ubuntu 22.04 and FortiClient VPN 7.0.0.0018

[no_one]

I have a strange problem when I connect to a company VPN with forticlient application. First, I did not know what was wrong. After spending some time, I figured out that DNS is not working as it should have. Unfortunately, I have no idea, who's fault is that. It may be FortiClient VPN, systemd-resolved, or something else. I am using Ubuntu 22.04, which is not an official version yet, but I have doubts it will get any better until official release in a week or two.

This is output from resolvectl before VPN is established:

username@hostname:~$ resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

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

Link 3 (wlp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1 2a00:ee0:d::13 2a00:ee0:e::13
        DNS Domain: --

After VPN is established resolvectl reports additional link called vpn:

username@hostname:~$ resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

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

Link 3 (wlp1s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
DNSSEC=no/unsupported
Current DNS Server: 172.20.1.21
       DNS Servers: 172.20.1.16 172.20.1.21 2a00:ee0:d::13 2a00:ee0:e::13
        DNS Domain: company.com

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

As you can see additional DNS servers are added to Link 3, which should help me resolve internal names when connected to VPN. Strange thing is that when I write

username@hostname:~$ resolvectl query name.company.com
name.company.com: resolve call failed: 'name.company.com' not found

I do not get anything. If I try with nslookup like this

username@hostname:~$ nslookup
> server 172.20.1.16
Default server: 172.20.1.16
Address: 171.20.1.16#53
> name.company.com
Server:     172.20.1.16
Address:    172.20.1.16#53

Name:   name.company.com
Address: 172.20.38.251

I get the correct answer. Since this was strange I traced network traffic to see what does nslookup differently than resolvectl query.

It turned out that nslookup uses a VPN assigned address for the source IP when asking DNS for a name. On the other hand, resolvectl query uses all other addresses for source IP except the one assigned by VPN. Because of that I guess DNS server does not have the route to send back an answer correctly to my computer, or DNS queries may even not reach the newly added DNS servers.

Because of that none of the programs I need can resolve the names correctly. The result is that I cannot connect anywhere within a VPN with a domain name.

Does anybody have an idea how to make resolvectl realize there is newly assigned VPN address, and it should use it as the source IP. Should FortiClient do some additional configutation on establishing a connection? Probably not.

I tried to restart systemd-resolved after VPN is established, but it does not help. Should I restart some other service? Which one?

I have checked how DNS is setup in network settings, and they are correct. Without VPN the network interface wlp1s0 shows:

username@hostname:~$ nmcli device show wlp1s0 | grep DNS
IP4.DNS[1]:                             192.168.1.1
IP6.DNS[1]:                             2a00:ee0:d::13
IP6.DNS[2]:                             2a00:ee0:e::13

After VPN is connected:

username@hostname:~$ nmcli device show wlp1s0 | grep DNS
IP4.DNS[1]:                             172.20.1.16
IP4.DNS[2]:                             172.20.1.21
username@hostname:~$ nmcli device show vpn | grep DNS
IP4.DNS[1]:                             172.20.1.16
IP4.DNS[2]:                             172.20.1.21

[Anonymous]

Hello no_one, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Thanks, 

 Fortinet Community Team 

[birendrakumar]

Hello no_one,

The mentioned issue was reported as BUG and fixed in the latest FCT version 7.0.3.

Since the latest FCT version is not available on forticlient.com (We have informed the concerned team to verify and upload the correct latest FCT build).

I am uploading the latest FCTVPN only 7.0.3 for Linux, This URL will have validity for 2 days.

FreeFCTVPN
Password: t4B4ESQN
https://fortinet.egnyte.com/fl/lAZ125F2WG

Please install it on a few devices and let us know how it goes.

[mgolvers]

Hello, will this one be fixed in 6.4.8 version, because it has the same issues?

[jmichels]

7.0.3 does not fix the issue for me either. As well, I don't think it has been mentioned here, but 7.0.0 and 7.0.3 cause systemd-resolved to be restarted every few minutes.

[reiniger]

I also see the periodic systemd-resolved restart - right now it's about every 2 minutes. Each time something adds the IPv6 address of my home router to the list of DNS servers (in addition to the VPN's DNS servers already present) and subsequent DNS lookups use that as default. Since my home network DNS doesn't know about the private hosts behind the VPN, all lookups for VPN hosts fail after that.

Excerpt from /var/log/syslog (IPs etc redacted):

Sep 15 14:13:40 (HOSTNAME) systemd-resolved[273804]: wlp1s0: Bus client set DNS server list to: (VPN_DNS_1), (VPN_DNS_2)
Sep 15 14:13:49 (HOSTNAME) systemd-resolved[273804]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server (VPN_DNS_2).
Sep 15 14:13:49 (HOSTNAME) systemd-resolved[273804]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server (VPN_DNS_1).
Sep 15 14:14:00 (HOSTNAME) systemd-resolved[273804]: Using degraded feature set TCP instead of UDP for DNS server (VPN_DNS_2).
Sep 15 14:14:25 (HOSTNAME) systemd[1]: systemd-resolved.service: Deactivated successfully.
Sep 15 14:14:26 (HOSTNAME) systemd-resolved[274760]: Positive Trust Anchors:
Sep 15 14:14:26 (HOSTNAME) systemd-resolved[274760]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Sep 15 14:14:26 (HOSTNAME) systemd-resolved[274760]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Sep 15 14:14:26 (HOSTNAME) systemd-resolved[274760]: Using system hostname '(HOSTNAME).(DOMAIN)'.
Sep 15 14:14:26 (HOSTNAME) systemd-resolved[274760]: wlp1s0: Bus client set DNS server list to: (VPN_DNS_1), (VPN_DNS_2), (HOME_DNS_V6)

The first line is triggered by me setting the DNS servers manually: "resolvectl dns (VPN_DNS_1) (VPN_DNS_2)",
the next three seem to be a consequence of that,
the "systemd-resolved.service: Deactivated successfully" is what happens every ~2 minutes and the final line is what messes up my DNS.

Reconnecting the VPN fixes the problem for a (very) short time.

Edit:

When backing up the forticlient configuration and looking into it I found this setting:

<vpn>
  <options>
    <!-- ... -->
    <inherit_local_dns>0</inherit_local_dns>
    <dns_service_resetting_interval>120</dns_service_resetting_interval>
  </options>
  <!-- ... -->
</vpn>
 

This certainly explains the periodic reset. I assume increasing that to a high number will fix the problem, but I'll have to rely on IT to change it :(

[f_sfetea]

I was just wondering what could trigger that
"Each time something adds the IPv6 address of my home router
"
Now we know.

[reiniger]

Actually that's only part of the answer. Today (after a system suspend) the periodic reset happens as before, but the home router IP is almost never set on it (I've counted only 2 occurrences in the logs today). So it seems like the reset triggered by forticlient provides the opportunity for the wrong IP to be added, but something else is also required for it to actually happen. And I haven't been able to track that down yet.

BTW: the suspend doesn't fix anything. I've had the previous problems both before and after suspends (I usually only shut down the system for the weekend), as well as before and after a dist-upgrade (Ubuntu 20.04 -> 22.04) including 2+ reboots.

[michelmzs]

Hi @birendrakumar , could you upload the latest FCTVPN 7.0.x for Linux (deb/rpm) again ? We are facing the same issue, forticlient does not configure DNS servers in the systemd-resolve when using split DNS. Also if we use the push DNS Server to clients config, DNS servers are being configured in the wrong interface (local LAN or Wifi instead of the vpn interface)

[michelmzs]

Same problem with 7.0.4 builds...