Hello, I’ve run into some strange behavior with the macOS System Extension using a Packet Tunnel. The issue showed up after the device went to sleep while the VPN was running. When I woke the computer, the VPN tried to reconnect but never succeeded — it just stayed stuck in the “connecting” state. I was able to turn the VPN off, but every attempt to turn it back on failed and got stuck at “connecting” again. Even removing the VPN configuration from Settings didn’t help. The only thing that worked was disabling the system extension completely. While checking the logs, I noticed thousands of identical log messages appearing within just a few seconds: nesessionmanager(562) deny(1) system-fsctl (_IO "h" 47) 17:11:52.481498+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5454 com.apple.networkextension 17:11:52.481568+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5454 com.apple.networkextension 17:11:52.481580+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5454 com.apple.networkextension 17:11:52.481587+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5454 com.apple.networkextension 17:11:52.481646+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5446 com.apple.networkextension 17:11:52.481664+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5446 com.apple.networkextension 17:11:52.481671+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5446 com.apple.networkextension 17:11:52.481676+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5446 com.apple.networkextension 17:11:52.481682+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5446 com.apple.networkextension 17:11:52.481687+0200 NESMVPNSession[Primary Tunnel:Secure DNS: got On Demand start message from pid 5446 com.apple.networkextension After the burst of these repeated messages, I started seeing logs like the following: 17:11:52.481759+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Spotify Helper[69038] com.apple.networkextension 17:11:52.481790+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Spotify Helper[69038]: session in state connecting com.apple.networkextension 17:11:52.481949+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Spotify Helper[69038] com.apple.networkextension 17:11:52.481966+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Spotify Helper[69038]: session in state connecting com.apple.networkextension 17:11:52.481986+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Spotify Helper[69038] com.apple.networkextension 17:11:52.481992+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Spotify Helper[69038]: session in state connecting com.apple.networkextension 17:11:52.482003+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Spotify Helper[69038] com.apple.networkextension 17:11:52.482011+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Spotify Helper[69038]: session in state connecting com.apple.networkextension 17:11:52.482022+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Spotify Helper[69038] com.apple.networkextension 17:11:52.482028+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Spotify Helper[69038]: session in state connecting com.apple.networkextension 17:11:52.482039+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Spotify Helper[69038] com.apple.networkextension 17:11:52.482049+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Spotify Helper[69038]: session in state connecting com.apple.networkextension 17:11:52.482060+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from Slack Helper[84828] com.apple.networkextension 17:11:52.482069+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from Slack Helper[84828]: session in state connecting com.apple.networkextension 17:11:52.482079+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Received a start command from sharingd[764] com.apple.networkextension 17:11:52.482086+0200 NESMVPNSession[Primary Tunnel:Secure DNS: Skip a start command from sharingd[764]: session in state connecting com.apple.networkextension It is clear that the connection is in a loop of submitting request to start and then failing. This problem occured only after sleep on macOS 26.0 and 15.6. This issue only occured after the system woke up from sleep. macOS 15.6 and 26.0. Is this a known problem, and how should I go about troubleshooting or resolving it?

We are developing a macOS application for distribution outside the Mac App Store. This application requires additional entitlements, including Keychain access groups, Network Extension, App Groups, and Sandbox. Both the app and the network extension import a custom framework. After creating the .app via Xcode, I ensured that a new Developer ID Application provisioning profile was generated. These profiles were then injected into the Contents folder of the .app and Plugins/.netappex as embedded.provisionprofile. Next, .entitlements files were created with the necessary "-systemextension" entitlement for the network extension and used for code signing. When inspecting the extracted entitlements from the .provisioningprofile as described in TN3125, everything appears correct. Code signing flow: codesign --force --options runtime --timestamp --sign "Developer ID Application: <team>" <.app>/Contents/Frameworks/<sdk>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <team>" <.app>/Contents/PlugIns/vpn.appex/Contents/Frameworks/<sdk>.framework/Versions/A/<sdk> codesign --force --options runtime --entitlements <vpn-plist>.entitlements --timestamp --sign "Developer ID Application: <team>" <.app>/Contents/PlugIns/vpn.appex/ codesign --force --options runtime --entitlements <app-plist>.entitlements --timestamp --sign "Developer ID Application: <team>" <.app> The .app is then zipped with ditto -c -k --keepParent and set off for notarization, which is succesful and the .app is stapled. After that, a .dmg or .pkg is created, which is then sent for notarization and subsequently stapled. The problem occurs when the app is distributed to the client. Opening the extracted .app fails, as Gatekeeper refuses to launch it with the following error message: 661 debug staticCode syspolicyd Security 0x88d68d818 done serializing <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string><teamid.bundleid></string><key>com.apple.developer.networking.networkextension</key><array><string>packet-tunnel-provider-systemextension</string></array><key>com.apple.developer.team-identifier</key><string>team-id</string><key>com.apple.security.app-sandbox</key><true/><key>com.apple.security.application-groups</key><array><string>teamid.group.appgroup</string></array><key>com.apple.security.files.user-selected.read-write</key><true/><key>com.apple.security.network.client</key><true/><key>com.apple.security.network.server</key><true/><key>keychain-access-groups</key><array><string>teamid.group.appgroup</string></array></dict></plist> com.apple.securityd 22207 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: { "com.apple.developer.networking.networkextension" = ( "packet-tunnel-provider-systemextension" ); "com.apple.developer.team-identifier" = team-id; "keychain-access-groups" = ( “teamid.group.appgroup” ); } com.apple.ManagedClient 22207 error ProvisioningProfiles taskgated-helper ConfigurationProfiles <bundle-id>: Unsatisfied entitlements: com.apple.developer.team-identifier, com.apple.developer.networking.networkextension, keychain-access-groups com.apple.ManagedClient After encountering this problem every time, we tried using a different development team with a new bundle ID, app groups, developer ID, developer ID certificate, and provisioning profiles. The .entitlements file remained the same (with different IDs), as did the capabilities for the App IDs in App Store Connect. With this new development team, we were successful, and the gatekeeper did not block the launch job. From a configuration standpoint, everything appears identical. Updating the App Store Connect App ID capabilities and generating new provisioning profiles for the first development team did not resolve the issue. Thank you for your help.