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

Bug found with new Forticlient Update! 7.2.5

Hello everybody,

regarding ZTNA, we found a bug after yesterday Forticlient EMS 7.2.5 upgrade.

This is happening only on macOS devices.

We have a ZTNA destination profile:

Screenshot 2024-10-11 alle 17.07.52.png

On Windows device, rule are correctly retrivied. But, on macOS, I can see no destination (I have all the tags I need):

Screenshot 2024-10-11 alle 17.09.07.png

Debbuging this problem, I was looking at the Forticlient ztna.logs, and I found (I removed some rules for simplification):

 

2024-10-11T16:24:28.238 TZ=+0200 info ztna mergeCfg:{"enabled":1,"rules":[{"name":"EMS","mode":"transparent","enabled":0,"destination":"10.1.0.217:3389","gateway":"ztna.ntditalia.com:13389","encryption":1,"local_port":"7788","type":"private"},{"name":"VMAgostini","mode":"transparent","enabled":0,"destination":"10.1.0.215:3389","gateway":"ztna.ntditalia.com:13389","encryption":1,"local_port":"7788","type":"private"}],"portals":null,"gateways":null,"notify_on_error":1,"portals_enabled":1,"gateways_enabled":1}
2024-10-11T16:24:57.148 TZ=+0200 info ztna sync portal select portal err:errPortalNotExisted

 

If we look at this logs, the rules are found, but are not enable (enable is 0). 

In fact, if I look at the ztnaconfig.json:

{"enabled":1,"rules":[]}

 

if I manually add my desinations inside the rules array, I can reach them correctly. So, the problem is that forticlient can't receive correctly the rules (am I wrong?). The only error I can see is info ztna sync portal select portal err:errPortalNotExisted.

What does it mean? I can't find anything regarding this error. This only happens for macOS system.

Thank you!

 

 

RDP
RDP
1 Solution
raffaeledp

I solved the problem. The solution was to create manually the XML ZTNA configuration. I had to shift down the "gateways" tag, in order to be correctly recognized by the Forticlient on macOS. 

RDP

View solution in original post

RDP
7 REPLIES 7
Atul_S
Staff
Staff

Hi There,

 

I hope your issue is resolved by now.

 

 

Thanks,

 

Atul Srivastava
raffaeledp

No, it's not. 

I investigated the problem and I think it is simply a bug.

Looking at the XML configuration of the ZTNA:

 

<?xml version="1.0" ?>
<forticlient_configuration>
<ztna>
<allow_personal_rules>1</allow_personal_rules>
<gateways uid="E26376A0-8370-4CFF-B5B6-1B6392F0D512">
<alias>ZTNA</alias>
<addr>ztna.ntditalia.com:13389</addr>
<redirect>1</redirect>
<rules uid="ED97CC71-E402-4A25-9B1C-01D7E29A8DDF">
<name>EMS</name>
<type>private</type>
<destination>10.1.0.217:3389</destination>
<encryption>1</encryption>
<enabled>1</enabled>
<mode>transparent</mode>
<local_port>7788</local_port>
</rules>
<rules uid="2D866340-9E8D-4CF3-A0C0-1200C546C56E">
<name>VMAgostini</name>
<type>private</type>
<destination>10.1.0.215:3389</destination>
<encryption>1</encryption>
<enabled>1</enabled>
<mode>transparent</mode>
<local_port>7788</local_port>
</rules>
</gateways>
<notify_on_error>1</notify_on_error>
<enabled>1</enabled>
<gateways_enabled>1</gateways_enabled>
<portals_enabled>0</portals_enabled>
<disallow_invalid_server_certificate>0</disallow_invalid_server_certificate>
<rules>
<rule uid="ED97CC71-E402-4A25-9B1C-01D7E29A8DDF">
<name>EMS</name>
<type>private</type>
<app_uid>43d246a131aed47e7c733b0fecab70c0</app_uid>
<allow_all_gateways>0</allow_all_gateways>
<mask/>
<encryption>1</encryption>
<mode>transparent</mode>
<destination>10.1.0.217:3389</destination>
<local_port>7788</local_port>
<gateway>ztna.ntditalia.com:13389</gateway>
<redirect>1</redirect>
</rule>
<rule uid="2D866340-9E8D-4CF3-A0C0-1200C546C56E">
<name>VMAgostini</name>
<type>private</type>
<app_uid>bcd3fa59a2e38084e53b76fbe619630a</app_uid>
<allow_all_gateways>0</allow_all_gateways>
<mask/>
<encryption>1</encryption>
<mode>transparent</mode>
<destination>10.1.0.215:3389</destination>
<local_port>7788</local_port>
<gateway>ztna.ntditalia.com:13389</gateway>
<redirect>1</redirect>
</rule>
<disabled_rules/>
</ztna>
<endpoint_control>
<ui>
<display_ztna>1</display_ztna>
</ui>
</endpoint_control>
</forticlient_configuration>
 
It seems to be correct, in fact, before the upgrade, in the ztna.logs I received this configuration:
2024-09-25T09: 40: 04.065 TZ=+0200 info ztna mergeCfg: {
    "enabled": 0,
    "rules": [
        {
            "name": "Contopet SSH",
            "mode": "transparent",
            "enabled": 0,
            "destination": "10.1.0.110:22",
            "gateway": "ztna.ntditalia.com:13389",
            "encryption": 1,
            "local_port": "7788",
            "type": "private"
        },
        {
            "name": "VMAgostini",
            "mode": "transparent",
            "enabled": 0,
            "destination": "10.1.0.215:3389",
            "gateway": "ztna.ntditalia.com:13389",
            "encryption": 1,
            "local_port": "7788",
            "type": "private"
        }
    ],
    "portals": null,
    "gateways": [
        {
            "redirect": "1",
            "addr": "ztna.ntditalia.com:13389",
            "alias": "ZTNA",
            "rules": [
                {
                    "name": "Contopet SSH",
                    "mode": "transparent",
                    "enabled": 1,
                    "destination": "10.1.0.110:22",
                    "gateway": "",
                    "encryption": 1,
                    "local_port": "7788",
                    "type": "private"
                },
                {
                    "name": "VMAgostini",
                    "mode": "transparent",
                    "enabled": 1,
                    "destination": "10.1.0.215:3389",
                    "gateway": "",
                    "encryption": 1,
                    "local_port": "7788",
                    "type": "private"
                }            
]
        }
    ],
    "notify_on_error": 1,
    "portals_enabled": 1,
    "gateways_enabled": 1
}
but, after the upgrade, the same configuration, generates this log:
 
2024-10-11T19: 21: 40.995 TZ=+0200 info ztna mergeCfg: {
"enabled": 1,
"rules": [
{
"name": "EMS",
"mode": "transparent",
"enabled": 0,
"destination": "10.1.0.217:3389",
"gateway": "ztna.ntditalia.com:13389",
"encryption": 1,
"local_port": "7788",
"type": "private"
},
{
"name": "VMAgostini",
"mode": "transparent",
"enabled": 0,
"destination": "10.1.0.215:3389",
"gateway": "ztna.ntditalia.com:13389",
"encryption": 1,
"local_port": "7788",
"type": "private"
} ],
"portals": null,
"gateways": null,
"notify_on_error": 1,
"portals_enabled": 0,
"gateways_enabled": 1
the gateways now is null, so the destination enabled have been deleted. How is that possibile? I tried also to modify the XML file, for example with this configuration, that in my opinion is correct:
<?xml version="1.0" ?>
<forticlient_configuration>
<ztna>
<allow_personal_rules>1</allow_personal_rules>
<gateways uid="E26376A0-8370-4CFF-B5B6-1B6392F0D512">
<alias>ZTNA</alias>
<addr>ztna.ntditalia.com:13389</addr>
<redirect>1</redirect>
<rules uid="ED97CC71-E402-4A25-9B1C-01D7E29A8DDF">
<name>EMS</name>
<type>private</type>
<destination>10.1.0.217:3389</destination>
<encryption>1</encryption>
<enabled>1</enabled>
<mode>transparent</mode>
<local_port>7788</local_port>
</rules>
<rules uid="2D866340-9E8D-4CF3-A0C0-1200C546C56E">
<name>VMAgostini</name>
<type>private</type>
<destination>10.1.0.215:3389</destination>
<encryption>1</encryption>
<enabled>1</enabled>
<mode>transparent</mode>
<local_port>7788</local_port>
</rules>
</gateways>
<notify_on_error>1</notify_on_error>
<enabled>0</enabled>
<gateways_enabled>1</gateways_enabled>
<portals_enabled>0</portals_enabled>
<disallow_invalid_server_certificate>0</disallow_invalid_server_certificate>
<disabled_rules/>
</ztna>
<endpoint_control>
<ui>
<display_ztna>1</display_ztna>
</ui>
</endpoint_control>
</forticlient_configuration>

 

RDP
RDP
raffaeledp

As you can see, the problem is the problem is that whatever the configuration, the destinations arrive with the enable parameter set to 0.

RDP
RDP
raffaeledp

I solved the problem. The solution was to create manually the XML ZTNA configuration. I had to shift down the "gateways" tag, in order to be correctly recognized by the Forticlient on macOS. 

RDP
RDP
fishhbot

Hello! We're having the exact same issue...but I don't quite understand your fix. Could you give me a little more info/detail on what you meant by "shift down the 'gateways' tag"? Thanks!!!

MaJa1
New Contributor

don't know if you have still this problem - try ems upgrade to 7.2.9, for me it worked

MaJa1
New Contributor

Hi, I had exactly the same problem.

EMS server was 7.2.8 

- my macos clients didnt even receive ZTNA rules

- when i upgraded macos clients to 7.2.9, then they saw rules, but still has the problem with Null gateways and connection problems

 

My solution was to upgrade EMS server to 7.2.9 then after client update everything is fixed and macos clients are able to connect again. After the upgrade there was problem with current tokens on fortigate, but you can either wait or delete them to receive new.

 

I was looking at Release notes and didnt find any mentions of this problem:(

Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors