Problems connecting to Globalprotect after users install latest windows Cumulative updates

[jclements]

There seems to be a bit of an issue connecting to Globalprotect after our windows machines have the latest microsoft cumulative updates, KB5018410 (windows 10) and KB5018418 (windows 11).

Looking in reddit it looks like other users are seeing the same problem as well, anyone got any ideas on how to fix this going forward? The only way we've been able to get users to connect is by uninstalling the latest update.

I've raised a call with our partner support but havent got anything back yet.

thanks

[mlinsemier]

My settings for the GlobalProtect portal are currently TLS 1.2/Max and we still are having issues.  I can also confirm that I can browse to the FQDN of our portal address in Chrome (normal and incognito) and SSO authenticates correctly and shows TLS1.2.   I'm thinking that this is a GlobalProtect client issue with the SSO implementation that could be using TLS1.0/1.1 still or its a Windows security change interop issue.  Continuing to troubleshoot to see if I can find a workaround.

[TedMay]

So there are two issues listed under this version:

1) Devices with Windows installations created from custom offline media or custom ISO image might have Microsoft Edge Legacy removed by this update, but not automatically replaced by the new Microsoft Edge. This issue is only encountered when custom offline media or ISO images are created by slipstreaming this update into the image without having first installed the standalone servicing stack update (SSU) released March 29, 2021 or later.

2) After installing this update, file copies using Group Policy Preferences might fail or might create empty shortcuts or files using 0 (zero) bytes. Known affected Group Policy Objects are related to files and shortcuts in User Configuration > Preferences > Windows Settings in Group Policy Editor.

Can anyone confirm that either of these are the causes for the issue they're experiencing?

https://support.microsoft.com/en-gb/topic/october-11-2022-kb5018410-os-builds-19042-2130-19043-2130-...

[matt_pierce]

I'm wondering why none of our test clients seem affected.  The only major difference I see form known problem cases is we have FIPS enabled at the OS and in GB.  Anyone affected feel like experimenting?

[jclements]

yup, exactly the same with me.  I've confirmed we're on min TLS 1.2/Max on our ssl/tls profile on gateway and portal and if I go ti the portal address I can authenticate and shows tls1.2.  We're using kerberos auth but it doesn't even look like the global protect client can start authenticating.  Can't think why some people are working fine and others, very strange. 

[TedMay]

I think it has to do with a potential update in edge on this KB.

[mlinsemier]

An interesting tidbit to have is that we seem to only be experiencing the issues on wired connections on the corporate network where we are doing internal host detection.  When we move it to wireless hosts don't behave the same way and fail.  Could be a plethora of reasons but was something to note.  Continuing to troubleshoot.

[TUH_IT]

All seems to point to SAML auth and the updates to Edge which GP relies on. Radio silence from TAC

[jasonrakers]

any updates on this?  I saw on reddit someone thought that setting gateway's SSL service profile with a minimum version of TLSv1.2 might mitigate.  

[jclements]

I saw that last night, we're on PanOS 10 and confirmed that all our ssl/tls service profiles are set to tls1.2 minumum so it hasn't had an effect in our case but worth trying to see if it works for you.  Its very puzzling though why its working for some people but not others, I can only think it must be some difference in group policy settings or something local on the users devices.  Not had any update from my partner support, TAC or my Palo Alto rep on any mitigation other than uninstalling the Cumulative update.

[ChrisCon2355]

Hi,
we are having the same issue, tested with GP 5.2.10-6 and 5.2.12.
Capturing on firewall shows just, that client closes the TCP-session with FIN after the key-exchange.
And the client shows certificate error.
10/14/22 10:45:37:610 error = ERROR_WINHTTP_SECURE_FAILURE
10/14/22 10:45:37:610 Server cert query failed with error 12019, ERROR_WINHTTP_INCORRECT_HANDLE_STATE
10/14/22 10:45:37:610 do not enforce 1.2, retry it now
10/14/22 10:45:37:610 winhttpObj, SendRequest, m_clientCertName=(null), bIngoreClientCert=0
10/14/22 10:45:37:673 WINHTTP_CALLBACK_STATUS_REQUEST_ERROR, error=12175, result=5, dwCertificateError=-2147483648
10/14/22 10:45:37:673 we get cert error, so remove previousCertificate
10/14/22 10:45:37:720 send alive message now 3
10/14/22 10:45:37:720 Send command to Pan Service
10/14/22 10:45:37:720 Command = <request><type>pan_msg_ping</type><result>3</result></request>
10/14/22 10:45:37:720 winhttpObj, get WINHTTP_CALLBACK_STATUS_REQUEST_ERROR
10/14/22 10:45:37:720 winhttpObj, ERROR_WINHTTP_SECURE_FAILURE set
10/14/22 10:45:37:720 Server cert query failed with error 12019
10/14/22 10:45:37:720 DC, dump server certificate now

[144296]

I've deployed a stock Win10 21H2 iso (from MS website), off our corp network (so no group/intune policy or domain account), and GP connects.  Updated with KB5018410 and GP fails.  It's still with TAC.

[LFura]

I think I found the solution.  For anyone having this issue check how long ago the ssl certificate was issued that you are using on your firewall.  Mine was more than 365 days old.  It was issued on 9/22/2021 so 387 days ago.  I am betting with the latest update Microsoft is enforcing a 1 year limit or something along that line to get in line with other tech companies that have shortened the length of time they will consider a cert valid.

I just went and created a new cert for my firewall with GoDaddy and now a client with the update can connect no problem.

Let me know if this was the fix for you?

[jclements]

I’m not sure if it’s to do with the cert being older than 365 days, ours was just renewed for a year in both gateways a month or so ago. Interesting though, wonder if creating a new ssl/tls profile with a new cert might work? If I can muster the will might have a play on my test firewall at the weekend.

[mlinsemier]

Our public GlobalProtect VPN certificates were generated in June 2022 so my certificates are well under the 365 day mark so I cant see it being a time related issue.  I am able to access the GlobalProtect portal, internal and external, and can authenticate to it via Chrome or Edge using SSO with no issues and the certificate seems fine.

[BSwientoniowski]

With the certificates, I think the primary concern is the validity period (is it good for 1 year or 2?) rather than how old they are.