Hi All, is anyone using the above client sucessfully?. I have had to revert our clients to 6.3.0 as the above version hangs on “finding best available gateway”.
Could just be us, but i have replicated the issue across different devices and O/S versions.
Its probably worth mentioning that we use Duo MFA on our Portal and Gateway too.
I’ve got about 300 clients on 6.30 and about 16 on 6.31, haven’t seen this issue yet, but am looking at upgrading my 6.30’s to 6.31 soon, so will keep an eye out.
My head end portal / gateways are running PanOS 10.2.11 and I have two gateways, using best available with one set to high priority and one low.
Sounds like youre running into GPC-20983. We’ve seen it in our testing, and they’ve confirmed working on/ fixing it for next release (not sure if it will be hot fix or 6.3.2 yet)
While it mentions from sleep, we see it in testing on reboot/changing portals as well.
Tried it two days ago and ran into the same issue over multiple different devices. Had to downgrade to 6.2.3.
We had MAJOR issues with 6.2.4 and DNS. We tunnel all traffic and only saw the issue on those devices.Split tunnels didn’t have the issue. We ended up upgrading to 6.3.0 to resolve the issue. Just finished that upgrade last week and all seems to be good. Windows clients and AZURE SAML.
I reverted due to hanging on redirecting to a browser for SAML auth.
I have been planning to upgrade to 6.0.10 but its still not preferred to get the new embedded browser based on Edge. Might just jump to 6.2 or 6.3 but the double window opening bug has me stalling.
I’m running 6.3.1, but only in a small subset.
Pre-logon machine cert always on with Azure SAML for the user.
I’ve not had issues yet.
But have only one centrally located 5k in ha.
I’m needing the upgraded embedded browser.
6.2.4 w native browser here on Mac & windows
We are on PanOS 11.1.2-h3 with two units in a HA Pair.
I tried the client on a machine that never had it, fresh install same issue. Hopefully the fix will still apply though. Thanks for the heads up.
Anyone know of Mac clients having this exact issue?
Can you elaborate on what the DNS issues were? We’ve just started moving our users to 6.2.4 and would prefer no surprises.
Sure, So it was not immediately obvious but after a random amount of time as user would start having weird access problems. They would reboot and it would go away. I only noticed this on Windows 10 & 11 as we don’t have a MAC user base. Oh, we also tunnel all traffic HOWEVER this would even occur when the user was on the LAN and GP was “internal”. We do not have an internal GW so it it just flips itself to “internal” and the traffic is not tunneled so it should not be playing with the packets but it definitely did in same sort of fashion. Perhaps it was corruption of the network stack, not sure. The sure fire way to diagnose if the user was having the problem when they called was simply drop to the CLI and attempt an nslookup. If it showed "timed out’ they were affected. As you know if you can’t do a DNS lookup you are screwed.
The only change was the client was upgraded from 6.0.7 & 6.23 to 6.2.4 and boom! No other changes were made and this setup has been in place for about 4 years. If I rolled the client back to one of the other 2 versions they were fine again immediately. So, being it is rather difficult using the Portal to downgrade clients we tested 6.3.0 and that worked totally fine so we just did an upgrade to the clients via the portal and all is well. I thought I was smart by avoiding a .0 release however instead it was my savior in this case.
*one other thing to note, I did notice using the portal to upgrade a client from 6.0.7 to 6.3.0 doesn’t work it just says installing forever but if you copy the client to the workstation and install it then she works fine. In case you are dealing with those versions. This doesn’t apply to 6.2.3 & 6.2.4 as that upgrade to 6.3.0 works fine via the portal.
Thanks for the info. We haven’t seen any similar issues so far, but keeping a close eye on it as there’s much larger set of clients upgrading to 6.2.4 later today.
Anyone else reading this looks like it is fixed in 6.2.5
||
||
|GPC-20988|Fixed an issue where GlobalProtect failed to resolve DNS queries when the ‘Allow traffic to specified FQDN when Enforce GlobalProtect Connection for Network Access is enabled and GlobalProtect Connection is not established’ configuration is set.|
Anyone else reading this it appears they fix the bug in 6.2.5
GPC-20988
||
||
|Fixed an issue where GlobalProtect failed to resolve DNS queries when the ‘Allow traffic to specified FQDN when Enforce GlobalProtect Connection for Network Access is enabled and GlobalProtect Connection is not established’ configuration is set.|
Anyone else reading this it appears they fix the bug in 6.2.5
GPC-20988
Fixed an issue where GlobalProtect failed to resolve DNS queries when the ‘Allow traffic to specified FQDN when Enforce GlobalProtect Connection for Network Access is enabled and GlobalProtect Connection is not established’ configuration is set.