I reported the feedback regarding this unexpected behavior: FB14897323

Hey! Does this happen when the device is not connected to power? Yes, it does. I'm not worried about the scenario when the device is connected to the power. I checked, and the wakeups happen in both scenarios. More often when connected to the power source and less often when disconnected. For example, are you able to measure some sort of battery drain that you believe is caused by this? Yes, I can measure the battery drain caused by this, and the impact is evident when the device is on the cellular network. Example results came from overnight tests when the device was just lying untouched and being on cellular: iPhone 13 mini: 13 mA of average power consumption with VPN off 35 mA of average power consumption with VPN on and hundreds of wake/sleep cycles iPad Air 5th gen: 22 mA of average power consumption with VPN off 38 mA of average power consumption with VPN on and hundreds of wake/sleep cycles This is a significant increase, and I'm concerned about what can cause such wake/sleep cycles on the device. Also, the results do not come from a single test; I realize that the device might do some updates, indexing, and other things like that overnight. I couldn't believe my results, so I repeated those tests many times, and the results were unequivocal.

Any chance that TestFlight is in this mix? We tried to reproduce it very hard by performing updates with TestFlight but have had no luck so far. Our only reports are from regular users who are not using TestFlight. Amazingly, I just had a similar occurrence on my Mac this morning. We use a third-party app in a work-from-home setup, and just this morning, it went crazy and was flickering "connecting->disconnected" very quickly. I see that the state was changed every 100 milliseconds in the system logs. The NetworkExtension complains: 2024-02-21 10:36:31.676860+0100 0x1a427 Default 0x0 518 0 nesessionmanager: [com.apple.networkextension:] Found 0 (0 active) registrations for <tunnel provider> (com.apple.networkextension.packet-tunnel) 2024-02-21 10:36:31.677349+0100 0x1a427 Default 0x0 518 0 nesessionmanager: [com.apple.networkextension:] NESMVPNSession[Primary Tunnel:<provider>:496B2DE4-FD7D-482F-9607-4B3021283266:(null)]: Leaving state NESMVPNSessionStatePreparingNetwork 2024-02-21 10:36:31.677522+0100 0x1a427 Default 0x0 518 0 nesessionmanager: [com.apple.networkextension:] NESMVPNSession[Primary Tunnel:<provider>:496B2DE4-FD7D-482F-9607-4B3021283266:(null)]: Entering state NESMVPNSessionStateStarting, timeout 300 seconds 2024-02-21 10:36:31.678820+0100 0x1a429 Default 0x0 518 0 nesessionmanager: [com.apple.networkextension:] NESMVPNSession[Primary Tunnel:<provider>:496B2DE4-FD7D-482F-9607-4B3021283266:(null)] in state NESMVPNSessionStateStarting: plugin NEVPNTunnelPlugin(<plugin>[inactive]) started with PID 0 error Error Domain=NEAgentErrorDomain Code=2 "(null)" 2024-02-21 10:36:31.678897+0100 0x19c0e Default 0x0 15325 0 VPN: (NetworkExtension) [com.apple.networkextension:] Last disconnect error for <3rd party app> changed from "none" to "The VPN app used by the VPN configuration is not installed" I obfuscated the name of the app, since I'm not sure I should share that publicly. Does the error The VPN app used by the VPN configuration is not installed ring any bell? I tried to Google it quickly, but no luck so far. I'm not sure if it's related to the issues we observe, but from the user perspective, the issue looks exactly the same.

Thank you for the link to the Profiles and Logs page; I didn't know that one! Yeah, on macOS, we are kind of able to reproduce the issue (at least something that looks like the issue we are chasing) by first installing our app from XCode and then installing it from the AppStore (without removing the old profile). We see then in the system logs that the certificates of the profiles do not match and the system does not start the Network Extension. I'm just having a hard time figuring out how this can happen for our regular users or on iOS...

This seems to suggest that the system is starting your extension in the on-demand case but not when you start the VPN manually. Is that right? Ah, that was a mental shortcut from my side. Our application always sets the OnDemand rules upon starting the tunnel, and we deactivate it only when the user explicitly disconnects. After setting onDemand rules to true, our application starts the tunnel process. As far as we know (as I said, we have very little data to work on, only a couple of confirmed cases), the OnDemand rules do not cause the issue per se; they are only responsible for the strange state of "flickering" our users experience - the system is not able to start the tunnel process for some reason. Because of onDemand rules, it tries again, and again, and again... We are currently developing telemetrics to learn how widespread this issue is for our users, but we have run out of ideas on how to reproduce it, and we don't want to ask our users for full sysdiagnose due to privacy concerns. I would greatly appreciate any theory you might have so we can experiment with it and maybe finally reproduce it. Also, without clear steps of reproduction we cannot actually file a bug report and hope it will be fixed.

Thanks for your quick reply! I will take a look at the documentation you provided and see if that helps. Anyway, for now it seems it's not a bug since you do not support modifying State domain directly.

Yes, exactly, to this particular key: let en0ServiceIPv4 = "State:/Network/Service/***/IPv4" as CFString Naturally, *** are replaced with my device id.

I will file the enhancement request, it would really nice feature to have. EDIT: Enhancement request created - https://feedbackassistant.apple.com/feedback/12817005 As the API is designed, an app can only message its embedded NE extensions, and vice versa. Do you know if the message itself is somehow encrypted so no 3rd party app can sniff the message? I'm investigating the viability of sending some sensitive information through such a channel and I'm concerned about security of such solution.

Do you know if I can consider messages send via sendProviderMessage secure? I cannot find any information if this channel is safe for sensitive data or not.

Thanks for your answer. I'm trying to understand how NWTCPConnection can possibly help in my case? Even if I use Apple API only for establishing the connection I don't see a way to nicely switch the connection to the new (possibly better) interface. Let's take as an example the NWConnection API. I see there is an API to handle a better path: var betterPathUpdateHandler: (Bool) -> Void)? A handler that receives updates when an alternative network path is preferred over the current path. Better path events are an indication that a more preferable network path is available. If you can migrate your work to a new connection, try establishing a new connection. Once that new connection is ready, cancel the original connection. But I don't know how to really use it? It says that I should establish new connection. Does that mean that I should create new NWConnection instance and cancel the old one? If so, it is much less efficient than using simply bind to bind the socket to a new interface. As to the suggestion of using NWTCPConnection I don't see anything in the API documentation which might help in my case? Maybe do you have some example code which uses its API?