Skip to main content
Satory
Satory
Explorer
October 10, 2023
Solved

FortiClient lost ZTNA Destinations after upgrade

  • October 10, 2023
  • 3 replies
  • 5578 views

We have upgraded our EMS server to 7.2.2 build 0879.

After that we upgraded few of our FortiClient to 7.2.2.0864.

 

The result:

- all our FortiClient endpoints with 7.0.9 receive the ZTNA destinations and create successfully the virtual hosts in the Windows \drivers\etc\hosts file.

- all our FortiClient endpoints with 7.2.2 did not change anything in the hosts file. Also the features status in the EMS console for that clients says: "ZTNA enabled (hidden)", although there is no such setting in the assigned profile. The user do not see the "ZTNA destinations" tab on the client side.

 

How may I change the behavior of the 7.2.2 client, so it can use the ZTNA as intended?

Best answer by Satory

I have found the solution, if anyone has the same issue.

Our FortiGate had no DNS Database feature enabled: go to System -> Feature Visibility -> DNS Database.


Or in cli:
config system settings
set gui-dns-database enable

3 replies

amouawad
Staff
amouawad
Staff
October 10, 2023

So there's been improvements in FortiClient 7.2.X with the ZNTA where it now doesn't change anything in the hosts file, instead it uses a DNS proxy to intercept ZTNA requests, this is why you won't see any changes in FortiClients running 7.2 but will still see the host file updated in 7.0.

 

You can confirm this by pinging the hostname for one of the ZTNA configured services, you should see it resolve to a 10.235.0.X address if it's working correctly.

 

In regards to why the users on FortiClient 7.2 can't see the ZTNA tab, with EMS 7.2 there is a feature to enable ZTNA yet hide if from users. To unhide it from users goto 1. Endpoint Profile > ZTNA Destinations and edit your ZTNA profile. 2. Select Advanced, 3. click the eye icon to unhide it from users.

 

ztna.png

    Satory
    SatoryAuthor
    Explorer
    October 10, 2023

    The hostnames are not resolved to anything - it says unable to resolve.

    Probably there is a misconfiguration issue, because we use FortiGate 7.0.12, which does not support such ghost DNS service or I am unaware how to configure it. 

    Is it possible to achieve this with 7.0.12 at all?

     

    On the second topic - the profile is set up exactly that way, but the tab is hidden:

    fortiems.png

     

     

    The profile is 

    amouawad
    Staff
    amouawad
    Staff
    October 11, 2023

    So the client being unable to resolve the ZTNA address has nothing to do with the FortiGate, this configuration comes from the EMS server that is then pushed to the FortiClient, so first thing is to check the ZTNA configuration there. Are you able to share the ZTNA profile you've configured?

     

    FortiGate 7.0.12 is supported in EMS 7.2.2/FCT 7.2.2, you can check this out here: https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/afec3249-ed3f-11ea-96b9-00505692583a/FortiClient_ems-compatibility-matrix.pdf

    Satory
    SatoryAuthor
    Explorer
    October 11, 2023

    There is no shadow DNS in FortiGate 7.0.12 and that is why I mentioned it.

    The configuration is simple:
    - one https VIP on the FortiGate

    - one RDP target behind it, lets say dc.local

     

    On FortiClient 7.0.9 when I ping dc.local I get ping to IP: 10.235.0.1

    On FortiClient 7.2.2 when I ping dc.local I get unknown host.

     

    Satory
    SatoryAuthorAnswer
    Explorer
    October 12, 2023

    I have found the solution, if anyone has the same issue.

    Our FortiGate had no DNS Database feature enabled: go to System -> Feature Visibility -> DNS Database.


    Or in cli:
    config system settings
    set gui-dns-database enable

    Terms & ConditionsAccessibility statement