Enhancement number: FB16475536

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?

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?

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?

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) ?

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?

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?

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!

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!

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

@eskimo Sure, and actually, I'm still struggling with it. I'm connecting to the VPN from the containing app (startVPNTunnel). I assume this creates a utun. I'm also adding an observer for 'NEVPNStatusDidChange'. When I'm getting the status update for 'Connecting', I'm creating an IPC connection from the containing app to the system extension. For some reason, this creates a second utun. Disconnecting the VPN will clean only one of those utuns. So each connection/disconnection, results in an extra utun remaining on the system. If I'm changing the logic a bit, and register to the IPC only when I'm getting the 'Connected' update (and not 'Connecting'), there will be only one utun, as expected. But I do need the IPC conenction ASAP, so I'm searching for a way to do it while 'Connecting', without creating another utun.

@eskimo Thanks for the quick reply (as usual)! For some reason I didn't get a notification about it, so just saw it, but I've updated that this was a bug on my app.

Update: I found the issue, which was related to my app, and not to the OS in any way.

I have the same issue, on macOS 13.4. I've implemented a sysExt custom VPN, and when connecting to the VPN, I see two new utuns. When disconnecting, only one of them is cleaned-up. While this weird behavior seems to work fine, things change when reaching a big number of utuns (around 95 utuns): Customers reported about slow connectivity, or sometimes - no connectivity at all. It seems that from that point (95 utuns) there are troubles with the DNS responses (No answers for DNS queries). Restarting the Mac will solve this problem, as it cleans the utuns. As mentioned in this thread, the IPv6 routing table looks 'weird', but the IPv4 routing table looks good. I have exit(0) at the code, after calling the stopTunnel completionHandler - so I tried to remove the exit(0), and tried to keep it but adding a 0.5 sleep before calling it - but it changed nothing. Is there any way to force clean those 'dirty' utuns? Any idea if a big num of utuns, can really cause the above (DNS/networking) problems?

Should I disable AMFI? amfi_get_out_of_my_way