Since upgrading to macOS Sonoma, the Always-On VPN feature has been unreliable. It disconnects without warning and fails to auto-reconnect, which breaks our zero-trust access model for engineering pods.
Here's what I've gathered so far:
* The Perimeter 81 daemon (`p81d`) shows as running, but the tunnel is down.
* No errors in the GUI client logs. The only useful data comes from the system's built-in VPN logging.
* Issue is intermittent but consistent across multiple M1 and Intel MacBooks on the team.
I ran a packet capture during a failure event. The daemon is still attempting IKEv2 handshakes, but it looks like the network stack isn't routing traffic through the tunnel after a wake-from-sleep event.
```bash
sudo log show --predicate 'subsystem == "com.apple.networkextension"' --last 1h | grep -E "(NEVPN|IKEv2|Status)"
```
Has anyone else validated this behavior? More importantly, have you found a workaround beyond manually toggling the connection or rolling back the OS? I need a fix that doesn't require user intervention.
-shift
shift left or go home
Sounds like a classic network extension bug after a major OS update. Been burned by that before.
But this is where your zero-trust vendor's support contract gets tested. You're paying for that "always-on" promise. Have you opened a ticket? What's their SLA for a regression that breaks their core feature?
I'd be curious if they try to bill you for "premium support" to fix an issue their app introduced.
always ask for a multi-year discount
> The only useful data comes from the system's built-in VPN logging.
That's the key signal. The system's NetworkExtension framework logs are far more reliable for debugging tunnel state than any third-party GUI. Your `log show` command is the right approach.
I've seen similar behavior with other VPN providers on Sonoma. The tunnel appears administratively "up" but the routing table doesn't get updated correctly after sleep, causing a silent split-tunnel. The IKEv2 handshake completes, but the associated `utun` interface isn't assigned as the default route.
Try filtering for `NEPacketTunnelProvider` in your logs. You might see a discrepancy between the daemon's status and the packet tunnel's actual configuration state. A temporary workaround I've used is a launch agent that runs `scutil --nc` commands to query the routing configuration, but it's not a real fix.
Have you checked if forcing the daemon to use the `always-on` configuration profile, rather than the user-initiated one, makes a difference?
Data is not optional.
Good call on the `NEPacketTunnelProvider` filter, that's where I usually spot the real failure. The routing table discrepancy is so frustrating because the UI gives you false confidence.
My team ran into the same silent split-tunnel problem on Sonoma with a different zero-trust provider. Our workaround was less elegant - we ended up writing a small script that bounces the network service on wake. It's hacky, but it's kept our devs unblocked while we wait for a proper fix from the vendor.
Have you noticed if the issue happens more often on Wi-Fi versus Ethernet? We've only seen it consistently on wireless.
Always testing.