How to know when `NEPacketTunnelProvider` has been cleaned up?

I want to get a better understanding of what you’re actually doing. Lemme summarise my understanding so far:

• You have a VPN app for macOS.
• It contains an Network Extension packet tunnel provider.
• From the app, you want to change the app’s VPN configuration.

Is that right?

If so, some questions:

• Is the provider packaged as an appex? Or a sysex? Or have you tried both and seen no difference?
• I presume you’re doing this configuration using NETunnelProviderManager from the container app. If so, what sequence of APIs are you calling?

I’m asking because the usual way to change a tunnel’s settings from the container app is:

1. Load the preferences.
2. Make the changes.
3. Save the preferences.

That last operation doesn’t necessarily tear down the packet tunnel provider. Rather, the provider is expected to observe its configuration — via KVO on the protocolConfiguration property — and adjust accordingly, meaning that no tear down is necessary.

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

Thanks for the quick response, and apologies for my extra-long answer -- I thought it best to be thorough here! Admittedly, I'm still learning the ropes a little with these APIs, so you may be able to spot some key detail I'm missing.

Is that right?

Your understanding is mostly correct. However, from the container app, I'm specifically interested in being able to dynamically switch configurations (NETunnelProviderManager instances), e.g., going from a non-MDM configuration to an MDM configuration. Outside of starting and stopping connections, I don't care to modify the configurations themselves, like for example, changing the server address of a configuration.

Is the provider packaged as an appex? Or a sysex? Or have you tried both and seen no difference?

Sorry, I should have specified. It's packaged as a sysex; I haven't experimented with an appex.

I presume you’re doing this configuration using NETunnelProviderManager from the container app. If so, what sequence of APIs are you calling?

Yes, the non-async NETunnelProviderManager APIs are being used from the container app.

I'll provide the example of transitioning from a non-MDM configuration to an MDM configuration as it feels like I have tighter control over it. The sequence is:

1. Call NETunnelProviderManager.loadAllFromPreferences, then parse the managers to detect if an MDM configuration exists -- our MDM profile has a key to detect this.

2. (from step 1 load completion handler) If found, call loadAllFromPreferences again, grabbing a reference to the VPN profile to be removed. From the completion handler, remove NEVPNStatusDidChange and NEVPNConfigurationChange observers temporarily, to ensure they're not affecting upcoming logic.

3. (still in step 2 load completion handler) Confirm that the NEVPNConnection associated with the manager is not in NEVPNStatus.disconnected state -- in the problem path, it is not.

4. (still in step 2 completion handler) Set up a temporary NEVPNStatusDidChange notification handler, to watch for NEVPNStatus.disconnected state -- this notification only observes changes to the manager to be removed.

   • When the notification triggers with NEVPNStatus.disconnected state, call oldManager.removeFromPreferences().

     • Within the removal completion handler, call loadAllFromPreferences, re-register handlers for previously removed VPN notifications, and call startVPNTunnel() on the MDM-added manager.

5. (Back to step 2 completion handler) Call oldManager.connection.stopVPNTunnel(), to eventually trigger the code in step 4.

In practice, when I do this, I'll end up with a routing table that's missing the route for my VPN network. To "fix" this, I've been adding a hard-coded delay between entering the removeFromPreferences() callback, and beginning the logic to start the new VPN tunnel.

I’m asking because the usual way to change a tunnel’s settings from the container app is: ... 3. Save the preferences

Note: Since the newly added profile is added to the system preferences by MDM, I do not call saveToPreferences() after loading it and prior to calling startVPNTunnel() on it. I only call saveToPreferences when setting up non-MDM configurations.

The steps for transitioning from one MDM-managed VPN configuration to another is shorter and more crude, since it deals with yanking an active configuration out of the system:

1. Set up observer NEVPNConfigurationChange, which will call loadAllFromPreferences() followed by startVPNTunnel() (from callback).
2. With one MDM-added configuration already active and connected on the system, add another MDM configuration (with Jamf in this case), so that there are now two VPN configurations in the system settings -- the current one in .connected state and the new one in .disconnected state.
3. Use MDM management tool (Jamf) to remove currently .connected profile, causing the system to put it into disconnected state (from what I've observed) and at the same time triggering the NEVPNConfigurationChange handler from step 1.

In this case, I've noticed a five second wait is the rough margin I need after the NEVPNConfigurationChange notification, in order to successfully configure and start the new tunnel, without the aforementioned routing table issues. Since the profile is just being yanked out in this case, I definitely understand why there's more room for error when taking down one configuration and adding another.

Thanks for all that info.

apologies for my extra-long answer

Au contraire, that’s exactly the sort of info I need (-:

First up, let’s talk about how the API should work. The NETunnelProviderManager APIs are asynchronous for a reason: They’re not supposed to complete until they’re done. In your first example, either one of the following should be true:

• Either removeFromPreferences() should not return [1] until the tunnel is closed.
• Or the open tunnel shouldn’t get in the way of the system establishing the new settings.

The fact that you have to add arbitrary delays is clearly a bug IMO, and I encourage you to file it as such.

Given that you can easily reproduce this, I recommend that you enable extra NE logging via the VPN (Network Extension) for macOS instructions on our page Bug Reporting > Profiles and Logs and attach a sysdiagnose log taken shortly after seeing the issue.

Please post your bug number, just for the record.

As to a workaround, it’s hard to say anything definitive without seeing it in action, and that’s gonna be hard given that your neck deep in MDM stuff. However, my best suggestion is to monitor the state of the System Configuration dynamic store during this process. It’s likely that the system state that’s causing you problems in reflected there and, if so, you can use its notification mechanism to wait for it to stabilise.

The dynamic store is pretty obscure. I have some general background and links to documentation in this post. For tests like this I usually start out by prototyping my work with the scutil command-line tool. That gives me some assurance that dealing with this gnarly CF-level API will be worth it (-:

For more about this tool, see the scutil man page.

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

[1] I’m using the Swift async function terminology here because that it’s much more convient. I realise that you’re using the completion handler variant. And that’s fine. Just read complete for return.