Addon: It seems that even calling to sendProviderMessage while at the 'connecting' phase will create an additional utun

True - production, macOS 13. I'll do both options (bug + DTS) a bit later and will update here the relevant ticket. Thanks for the help!

If you push multiple VPN configuration payloads then all of their associated digital identities end up in com.apple.managed.vpn.shared. I can’t see anything that’d prevent you from querying the keychain for them all and then choosing between them. This is exactly what I've ended up with, just wanted to check if there's an option to do it all in a single payload. Thanks!

Thanks eskimo, but please let me rephrase the question: 'includeAllNetworks' is disabled. At the provider, all routes are included: [NEIPv4Route.default()] In this case, should the LAN traffic go via the VPN? Or is the LAN traffic excluded from the VPN?

Thanks eskimo! if you’re not using NWConnection, can you try it? Sure. I'm not working with NWConnection, and I'll try it soon. A related question to the above: I'll add the code to the wake() function. I assume I should wait for '.ready' and only then to start establishing the tunnel. But what if the check will stuck in '.waiting'? Should I, at any point in the wake() function, set the 'reasserting' variable?

If if you’re not using NWConnection, can you try it? I’m not suggesting that you rewrite all the networking code (well, not yet :-) but instead just try starting a parallel NWConnection and see how it behaves. For that, I'll have to add 'import Network' at the Packet Tunnel Provider. Then, my code to monitor path-change won't compile: let oldPathOpt = change?[.oldKey] as? NWPath //'NWPath' is ambiguous for type lookup in this context I also tried this one let oldPathOpt = change?[.oldKey] as? NetworkExtension.NWPath //Ambiguous type name 'NWPath' in module 'NetworkExtension' So, instead of NWConnection, would it be okay to use something like let configuration = URLSessionConfiguration.ephemeral configuration.waitsForConnectivity = true let session = URLSession(configuration: configuration) ?

I'm guessing it's this one - "Should the wake function be called because of the on-demand rule?" But if so, each request to APNs will wake the VPN from sleep. Is there any way to prevent it, and still start the VPN for any other traffic?

Bump. Is there any way to create on-demand rules, so that any traffic initiated by the user would trigger the VPN, but any other traffic won't?

Sorry I didn’t reply earlier. I made a note to reply but somehow I missed it. Weird. NP, and thanks for the detailed reply! So I’d expect to see the first behaviour Okay, but let me rephrase a bit my question: This is what I was trying to get to: Is there any way to create on-demand rules, so that any traffic initiated by the user would trigger the VPN, but any other traffic won't?: And more specifically: Let's say that it's a night time, so both the Mac and the user went to sleep.. I noticed that during this 8 hours sleep, the VPN awakes multiple times, so I'm guessing it's related to APNs traffic. I would like that such traffic won't need to wake the VPN, and so I'll prevent a multiple wake-sleep events. Is something like that is possible with the above On-Demand rules I described earlier?

Enhancement number: FB16475536

BUMP?

Thanks for the answer! For that we have Always-on VPN. IIRC, always-on is for managed iPhones/iPads only, and not for Macs, even when using a native VPN. Is this in reference to the includeAllNetworks property? If so, then you should definitely explore that option. Yes, that's what I was referring to. The basic scenario worked, but I have two issues with it: With this flag enabled, what would happen in the test I described: VPN is enabled, disconnect the WiFi and reboot the Mac, after the reboot, bring back the WiFi - would the traffic be blocked until the VPN starts, or is there some 'race', where some packets can be routed before the VPN starts? A bigger problem is there's no split-tunnel when this flag is enabled

However, that’s really just a guess. Are you able to reproduce this yourself? Or are you just going on logs returned from this user? I'm unable to reproduce it; all the above info is from the user's logs. That is, the systen thinks that the tunnel is connecting, so it can’t act on the connection immediately. Eventually the first connection attempt times out and then it connects again. It sounds reasonable, but from the logs, the extension isn't running. Is there any way to solve or detect such cases? Is there any data I can ask the user to help understand what happened?

And what about this error: RunningBoard doesn't recognize submitted process - treating as a anonymous process. Isn't it problematic that the extension is considered as an 'anonymous process'?