Skip to main content
no_one
no_one
New Member
April 12, 2022
Question

DNS settings on Ubuntu 22.04 and FortiClient VPN 7.0.0.0018

  • April 12, 2022
  • 14 replies
  • 81106 views

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

 

14 replies

A
Anonymous_User
Contributor
April 15, 2022

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
Staff
birendrakumar
Staff
April 20, 2022

@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
mgolvers
New Member
April 21, 2022

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

no_one
no_oneAuthor
New Member
April 21, 2022

Unfortunately, the 7.0.3 version does not fix it for me.

 

I have further observed the behaviour and found out an interesting detail. Most of the time DNS is not working correctly. However, on rare occasions, it resolves. On that occasions there is a line in /var/log/syslog:

 

Apr 21 07:59:45 hostname systemd-resolved[5415]: Using degraded feature set TCP instead of UDP for DNS server 172.20.1.21.

 

Wireshark shows in that case the correct source IP address. In all other DNS lookups UDP is used, and the source address is my local IP address and not VPN assigned IP. With TCP the VPN source address is used and then it works.

 

I still have no idea where the error should be fixed (systemd-resolved, fortinet client,...???).

sw2090
SuperUser
sw2090
SuperUser
April 26, 2022

Just as additional information: I use strongswan for ipsec to fortigate here. It still worked in 22.04 but still failed to push dns settings to me. I found out that was due to an old bug that was reported in debian buglist in 2018 already. It is not directly a bug in strongswan, it is more a "bug" in the apparmor profiles in ubuntu. Those are too restrictive and prevent strongswan from writing anything into /etc/resolv.conf and in consequence hostnames that can only be reolved over the ipsec cannot be resolved at all.

fixing the permissions by adding the missing line to the apparmor profile made it working with strongswan here.

Maybe the apparmor profile for forticlient has a similar issue?

lmaranzano
lmaranzano
New Member
June 13, 2022

Hello, we are facing the same issue here with forticlient 7.0.0.0018 installed on Ubuntu 20.04.

DNS are not injected at all in the local resolver, we also tried to disable completely apparmor but without any successful result.

Is it possible to have an ETA for the public release of the fixed version?

Thanks in advance.

Regards

Luca

 

mgolvers
mgolvers
New Member
June 13, 2022

The same issue is present on Fedora 36 with systemd-resolved-250.7-1 and Forticlient 6.4.8

XAC
XAC
New Member
August 5, 2022

I feel very frustrated to see how Ubuntu users are completely ignored on that situation. I spend days and days searching for a solution by all means... NO SOLUTION. I have indeed seen how in several threads it is said that the next version solves the problem. But it is repeatedly false. This is very embarrassing.

lmaranzano
lmaranzano
New Member
August 6, 2022

We are adopting openfortivpn for Ubuntu desktops and I can say that it works without any issue, even with MFA authentication. It is perfectly integrated with systemd-resolve, so DNS is working as expected.

I also find it embarrassing that Fortinet is unable to release a working client for linux desktop.

HTH

Regards

Luca

 

 

    XAC
    XAC
    New Member
    August 6, 2022

    Thank you for sharing with me this option. I have been trying to use it several times, but my institution use SAML SSO and I have deduces that it is impossible. Do you have an idea if openfortivpn can be used in this case? What about the certificates? I tried to use openssl against my fortinet gate server.

    f_sfetea
    f_sfetea
    Visitor III
    August 22, 2022

    Perhaps is related:
    Our workaround for FCT 7.0.4 & 7.0.6 SSO with build-in Chrome based browser is:

    you need to edit NM config

    sudo vi /etc/NetworkManager/NetworkManager.conf

    and append the

    [keyfile]
    unmanaged-devices=interface-name:vpn*,except:interface-name:enp0s3;interface-name:wlan*

    then restart your service

    $ sudo systemctl restart NetworkManager.service

     

    the External Browser(default own OS browser) option for SSO does not seem to work for the moment and presents an JS error sendSslvpnAuthId is not a function

    f_sfetea_0-1661170142631.png

     

      SlavaS
      SlavaS
      Visitor III
      August 23, 2022

      Your solution worked, thanks !!

        jw-websensa
        jw-websensa
        New Member
        October 17, 2022

        I am struggling with DNS on FortiClient in multiple versions (7.0.0, 7.0.7)

        Firstly I tried to set up split DNS, but ofc it did not work on any Ubuntu machine.

        I tried to talk about it with support, even received some unreleased build of client, but it is still not working properly.

        Now I deceided to manually set DNS server for connection (no split), which worked on Ubuntu 20.04, but (of course) not on 22.04.

        I find it extremly frustrating and I spent definitely too much time on that.

          anushty
          anushty
          New Member
          November 3, 2022

          good post like it

          Show more replies
          Terms & ConditionsAccessibility statement