Bug found with new Forticlient Update! 7.2.5

[raffaeledp]

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:

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

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!

 

[Atul_S]

Hi There,

I hope your issue is resolved by now.

Thanks,

[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>

[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.

[raffaeledp · Accepted solution]

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. 

[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!!!