Forticlient linux dns problem

Fortinet Community

The Forums are a place to find answers on a range of Fortinet products from peers and product experts.

Subscribe to RSS Feed
Mark Topic as New
Mark Topic as Read
Float this Topic for Current User
Bookmark
Subscribe
Mute
Printer Friendly Page

Created on ‎04-12-2022 05:50 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

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

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

Created on ‎04-14-2022 09:52 PM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

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.

Created on ‎04-20-2022 05:43 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

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.

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

Created on ‎04-20-2022 10:49 PM Edited on ‎04-20-2022 10:49 PM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

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

Created on ‎04-26-2022 05:05 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

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.

Created on ‎09-15-2022 05:23 AM Edited on ‎09-15-2022 05:36 AM

Mark as New
Bookmark
Subscribe
Mute
Subscribe to RSS Feed
Permalink
Print
Report Inappropriate Content

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.

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

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 🙁

Источник