GlobalProtect portal unresponsive error after upgrade to OSX 15.4

[nc_engineering]

PA-820

GlobalProtect version: 6.3.2

PanOS 10.1.14-h10

Mac OSX version: 15.4

On attempting to connect with GlobalProtect, the error message "The network connection is unreachable or the portal is unresponsive. Check the network connection and reconnect." appears.

• All users on OSX 15.3 are still able to connect without any errors or issues.
• An uninstall and reinstall of Global Protect on affected machines running OSX 15.4 does not correct the issue.
• The portal uses a Palo generated cert which is locally imported and trusted on all client machines, including the 15.4 machines.
• The portal itself is up and reachable in Firefox on affected machines running OSX 15.4, but not Chrome/Safari (complaints about the Palo generated cert, which we have also seen on 15.3 machines).
• We have tried generating a new cert from the Palo GUI and attaching that to the GP portal and gateway and trusting on local machines, but no change.

Any suggestions on further ways to troubleshoot the issue or possibly correct it would be much appreciated.

Thank you!

===================================

Relevant log snippets:

The PanGPS logs show:

P 786-T10251 04/06/2025 11:57:42:576 Info ( 703): Server is trusted <portal IP address> (<portal IP address>) P 786-T17155 04/06/2025 11:57:42:613 Error( 580): Connection error Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={_kCFStreamErrorCodeKey=-9824, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, NSUnderlyingError=0x600002437090 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9824, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9824, _NSURLErrorNWPathKey=satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, dns, uses wifi}}, NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made., NSErrorFailingURLKey=https://<portal IP address>:443/global-protect/prelogin.esp?kerberos-support=yes&, NSErrorFailingURLStringKey=https://<portal IP address>:443/global-protect/prelogin.esp?kerberos-support=yes&, _kCFStreamErrorDomainKey=3} response:(null) connection: 0x600001300000, type: 1, host: [<portal IP address>:443], original host: [<portal IP address>], alwaysTrust: 0 session: <__NSURLSessionLocal: 0x13b504c80> -[GPURLConnection session] <NSOperationQueue: 0x13b006c70>{name = 'NSOperationQueue 0x13b006c70'} identity: (null) scepIdentity: (null) clientCertLookupPolicy: 0 usageOID: (null) noUserInteraction: 0 responseData(0): P 786-T17155 04/06/2025 11:57:42:613 Debug( 530): error detail is An SSL error has occurred and a secure connection to the server cannot be made.

The pan_gp_event.log shows:

04/06/2025 11:57:42:470 [Info ]: Started the Portal pre-login 04/06/2025 11:57:42:470 [Info ]: CPanMSService::PreloginPortal CheckServerCert return 0x2000 04/06/2025 11:57:42:615 [Info ]: Portal pre-login result received 04/06/2025 11:57:42:615 [Info ]: Failed to pre - login to the portal <portal IP address> 04/06/2025 11:57:42:615 [Info ]: portal status is Invalid portal. 04/06/2025 11:57:42:615 [Error]: No Network Connectivity. Please verify your network connection and try again. 04/06/2025 11:57:42:615 [Error]: The network connection is unreachable or the portal is unresponsive. Check the network connection and reconnect.

[BPry]

@nc_engineering,

Any real reason that you aren't using a publicly trusted certificate? Certificates are readily available for a minimal fee every year and even if your budget is free you can utilize something like acme.sh and LetsEncrypt to generate free publicly trusted certificates with a little bit of a setup process and some automation.

Your PanGPS logs would indicate that the certificate trust is causing the issue here. I can't say that I've passively seen any increased reports of 15.4 causing self-signed certificate issues, but it wouldn't be the first time that macOS updates had an effect on certificates only being trusted by keychain.

[nc_engineering · Accepted solution]

Thanks for the reply.

We originally used a self signed cert because our setup is for remote connection to a private intranet (no public facing anything for DNS verification).

We ended up creating an internal CA and generating a cert off of that, and it appears to have resolved the issue in OSX 15.4 (while still working on 15.3). Internal CA wasn't our first choice, but because it's a private intranet, a 3rd party public CA didn't seem like a fit. If that doesn't sound correct, def open to some other process that's a best practice.