Global Protect - Issue with switching to a different gateway

[VishwasAkbilwam]

We are piloting 6.1.2-83 client version. With new version we are seeing below behavior.

After connecting to Global Protect VPN if we try to switch to another gateway manually, the client is throwing error "Matching client config not found. Connecting to Best available gateway" and it fails to connect to other gateway and ends up connecting to previous gateway where it was connected before.

From the logs I can see that the gateway authentication is happening successfully but not connecting and throwing the error.

Any thoughts ?

[Mick_Ball]

This will probably be because you have users or groups listed in the Gateway/agent/client settings\config that do not match the user login names..  check in Monitor/GlobalProtect to ensure the user matches username in the Gateway config.

check also any settings for OS, Regions or IP addresses in the same Gateway config...

[VishwasAkbilwam]

Thank  you Mic for your reply. We are seeing the problem when we are manually switching the gateway, example if my  client connected to X gateway but I wanted to switch to  Y gateway because of any reason, we are seeing this problem.  However if the client selects gateway Y then we don't see this problem. 

I have verified the group settings and users are in the group

[Mick_Ball]

what is your authentication method for both portal and gateways?

what happens if you remove users/groups from the gateways?

[VishwasAkbilwam]

We are using LDAP authentication for the portal and Radius + Azure MFA for Gateway authentication.

I have not tried removing users/groups as it is in production and users don't have issues directly connecting to the gateway, it is only while switching manually.

[Chance-Edwards]

Any solution. This is affecting my company as well. Same issue. 

[Mick_Ball]

Are users prompted to re authenticate when switching gateways or are you using cookie generation??

And may be a daft question but are you sure the username for a good gateway connection matches exactly with one of a failed gateway connection in  monitor/globalprotect.

And having asked that, for our similar setup with OTP we have this on the portal which then generates an override cookie for the gateways, would this not work for you??