NEPacketTunnelProvider died unexpectedly, no crash dump

If you need any information I'll be glad to provide it.

This is the first time I’ve seen this reported against the built-in VPN transports, although that doesn’t surprise me given the common underlying infrastructure. However, it is a new wrinkle and that definitely makes it worthwhile for you to file a new bug about it.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

OK, I've filled a report: FB7716038.

Hope this will be fixed soon, because all the VPN clients that are using native IKEv2 implementation suffer from this issue.

I also encountered this bug while creating a transparent proxy (NEAppProxyProvider in extension, NETransparentProxyManager in host app). Although the solution provided by zx2c4 works to stop the proxy from crashing 15-20 seconds after it starts, it leads to another problem: when the proxy is disconnected gracefully (e.g. user clicks "Disconnect" in System Preferences), the proxy will hang on "Disconnecting" for about 5 seconds before finally exiting.

I don't know what exactly causes this "Disconnecting" problem, but my guess is that calling exit(0) immediately after completionHandler() in stopProxy does not give sufficient time for the proxy to communicate its successful close to the remote network service manager before the proxy exits. Therefore, the network service manager just waits a certain amount of time before assuming the proxy crashed and moving it to the "Not Connected" state.

My solution is to call exit(0) as suggested by zx2c4, but immediately before that, sleep for half a second with Darwin.usleep(500000). Of course, that adds a ~0.5 second delay on exit, but it's much better than ~5 seconds. I'm aware this is even more filthy than the already self-described "filthy hack" by zx2c4, but... it seems to work.

So the final code should look something like:

Code Block 
override func stopProxy(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) {
	/* ... shutdown work... */
	completionHandler()
	#if os(macOS)
	/* Workaround for apple bug 32073323. */
	Darwin.usleep(500000)
	exit(0)
	#endif
}

This workaround is also needed for Network System Extension?

I haven’t tested it but, based on my understanding of how NE uses the underlying system support for app and system extensions, I suspect that the workaround isn’t necessary for an NE sysex. However, that’s just a guess. You should suck it and see.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Once in a while we get back to this thread and I would like to report that we are not able to reproduce this issue anymore (will update this post if things change).

• We use NEPacketTunnelProvider
• All our testing was done on macOS 14

Anyone else experienced improvements or are we just lucky in our testing so far?