Global Secure Access macOS client — tunnel extension becomes unrecoverable after secd outage (full network blackhole, only reboot recovers)

Severity: B (recurring, user completely loses network connectivity until reboot)

Product: Microsoft Entra Global Secure Access — macOS client

Environment

ItemValueGSA client version1.1.25111702 (system extension com.microsoft.globalsecureaccess.tunnel 1.1.25111702)----------------GSA client version1.1.25111702 (system extension com.microsoft.globalsecureaccess.tunnel 1.1.25111702)macOS26.5 (build 25F71), Apple SiliconTenant IDbd7fcbc4-12e6-476d-a09e-899d84b6c9baDeviceBRG-N-016 (Microsoft Intune managed)Affected [email protected] — at least 2026-07-01 and 2026-07-04 (~08:53 CEST), likely earlier undiagnosed## Summary

After a transient outage of the macOS keychain daemon (secd), the GSA tunnel network extension enters a permanently broken state: its main thread exits, it stops retrying policy download, and it keeps capturing all traffic while dropping every new flow (established flows continue to work). The device loses all new connectivity — DNS, TCP, even ICMP to the local LAN gateway. The extension process cannot be restarted by any supported or unsupported means (SIP protects it) and does not recover on its own. The only full recovery is a reboot.

Observed sequence (unified log, process com.microsoft.globalsecureaccess.tunnel, 2026-07-04)

1. Extension repeatedly fails to reach the keychain daemon (56 occurrences in the captured window):

(Security) [com.apple.securityd:SecCritical] Failed to talk to secd after 4 attempts.

1. Without keychain access, policy download fails (32 occurrences) — note this is the client failing to build/parse the request/response, not a tenant-side policy issue:

[XplatCommon][NAAS_BL]: Failed deserializing policy - "exceptionMessage":"[json.exception.out_of_range.403] key 'policy' not found"
[XplatCommon][NAAS_POLICY_UTILS]: Policy deserialization failed with error : No policy found

1. The extension's main thread exits — after this the process is a zombie (no further policy retries are logged):

(CoreFoundation) [com.apple.foundation:general] Attempting to use the main runloop, but the main thread has exited. This message will only log once.

1. From this point the extension still holds the tunnel (utun) and flow capture, but rejects every new flow — 2,196 occurrences in the captured window:

[XplatCommon][NaaSPacketController]: Got a packet from unknown flow

Impact: all new connections fail (system DNS, direct DNS to 8.8.8.8, HTTPS, even ICMP to the local gateway 100 % loss). Long-lived connections established before the failure keep working, which confirms flow-level capture by the dead extension rather than an uplink outage.

Remediation attempts (all failed to restore the extension)

AttemptResultRestart of the menu-bar client (launchctl kickstart -k gui/<uid>/com.microsoft.globalsecureaccess)Client restarts, extension unchanged----------------Restart of the menu-bar client (launchctl kickstart -k gui/<uid>/com.microsoft.globalsecureaccess)Client restarts, extension unchangedRestart of secd (sudo killall secd, respawned by launchd)secd healthy again, but extension never retries (main thread already exited)sudo pkill -f com.microsoft.globalsecureaccess.tunnel.systemextension``Operation not permitted (SIP)sudo launchctl kickstart -k "system/NetworkExtension.com.microsoft.globalsecureaccess.tunnel.1.1.25111702.1.1.25111702"``Could not kickstart service … 1: Operation not permittedDisable → Enable from the client menu bar (quick toggle)Extension PID unchanged, blackhole persistsDeleting extension caches / policy files + restart of all componentsNo effect (process survives, state unchanged)Disable and leave disabledTraffic capture is finally released — network works again, but device runs without GSA protection until rebootRebootFull recovery (both on 2026-07-01 and 2026-07-04)## Expected behavior

1. The tunnel extension should tolerate a transient secd outage (retry with backoff) instead of terminating its main thread and turning into a permanent traffic blackhole.
2. If the extension is in a failed state, it should fail open or closed consistently — not keep flow capture while dropping all new flows.
3. A watchdog (client or extension) should detect the dead main thread and restart/recover the extension.
4. Disable from the client UI should reliably tear down the broken extension, not just release capture while leaving a zombie process.

Questions for support

1. Is this a known issue in client 1.1.25111702, and is a fixed build available?
2. Is there a supported way to restart the tunnel extension without a reboot when it reaches this state?
3. Root cause of the secd communication failure — is the client doing anything unusual with keychain access that could wedge secd?

Attachments

• GlobalSecureAccessLogs-1.1.25111702-2026-07-04--09-19-35.zip — official client diagnostic bundle (collect_and_export_logs), collected while the extension was still in the broken zombie state (before reboot).
• gsa-tunnel-log.zip — unified log for process com.microsoft.globalsecureaccess.tunnel, 3-hour window covering the 2026-07-04 incident (234k lines; key signatures: 56× secd failure, 32× policy deserialization failure, 2× main-thread-exited, 2196× "unknown flow" drops).
• gsa-tunnel-log-key-excerpts.txt — 60 key log lines for quick triage.