Just got hit with the classic "patch Tuesday" surprise from Palo Alto. The new critical CVE (CVE-2024-XXXX, the one for GlobalProtect) meant we had to patch our PA-5200 series ASAP last night.
Patch applied fine, but now a subset of our remote users on macOS Sonoma can't establish VPN connections. The client authenticates, but the tunnel never establishes. No useful logs on the client side, and the firewall logs just show a generic "phase 1 failure." Rolling back the patch isn't an option per security. We're digging into IKEv2 configs, but nothing changed there.
Quick side-by-side of our configs pre/post-patch shows zero differences in the VPN settings. We're testing a theory about a specific cipher suite being deprecated in the patch.
Anyone else in the same boat? Specifically:
* Seeing issues **only with macOS clients** after this PAN-OS patch?
* Found a workaround **without** downgrading or disabling the fix for the CVE?
* Noticed any changes to **IKE or IPSec config defaults** in the new version?
Our infosec team is breathing down our necks to stay patched, but the helpdesk is flooded with VPN tickets. Any insights would save my sanity 🙏.
ā alex
Data > opinions
Oh classic Palo Alto, trading one critical issue for another operational nightmare. Your cipher suite theory is probably warm, but I'd bet it's less about deprecation and more about the patch aggressively tightening parameters without updating the compatibility matrix.
We saw something similar last year with a different PAN-OS "security hardening" update. It silently enforced a stricter IKEv2 DH group for macOS clients specifically. The configs looked identical side-by-side too. The workaround wasn't in the GlobalProtect portal, it was buried in a device group security rule that got its defaults nudged.
Have you checked if the phase 1 proposal order got reshuffled? Sometimes the "no change" log is the biggest lie of all.
But what about the edge case?
Oh Alex, I feel your pain. The macOS-specific flavor of this screams compatibility matrix mismatch.
> the firewall logs just show a generic "phase 1 failure."
This is the worst. Have you checked the IKE crypto profiles assigned to your gateway, not just the main VPN settings? In a past update, ours defaulted to a new, stricter profile that didn't include DH Group 14, which some macOS clients stubbornly prefer. The portal config looked untouched, but the effective policy changed.
My quick checklist for this:
* Verify the exact IKEv2 proposal order on the firewall. Sometimes the patch reorders them, and macOS picks the first one it doesn't like.
* Look for any new "Security" sub-settings in the Network > GlobalProtect > Portals config that might have appeared with the patch, especially around Suite B compliance.
* Can you test with a single user and force the client to use IKEv1? It's a terrible long-term fix, but it can confirm if it's purely an IKEv2 negotiation issue.
Hang in there. Let us know if the cipher suite theory pans out.
Oh man, this is exactly why I'm terrified of pushing critical patches after hours. 😅 I'm new to managing Palo Alto gear, but even I know "phase 1 failure" is the most frustrating log entry.
You mentioned the side-by-side configs look identical. Could it be that the patch changed something in the *default* IKE proposal, but only if your portal or gateway was set to use the system defaults instead of a custom one? I've heard sometimes the patch notes don't mention those subtle changes.
Our team is watching this thread because we're about to apply the same update. Sorry to ask a basic question, but are you using a custom crypto profile for the gateway, or did you leave it on the Palo Alto default?