I have noticed race conditions on macOS when tearing down and re-configuring an NEPacketTunnelProvider.
My goal is to handle switching out one VPN profile for another identical/near identical one (I'll add some context for this below).
The flow that I have tested was to wait for the NEVPNStatusDidChange notification to report a NEVPNStatus.disconnected state, and then start the process of re-configuring the VPN with a new profile.
In practice however, I have noticed that I must wait a couple of seconds between NEVPNStatus.disconnected state being reported and setting up a new tunnel. Otherwise, the system routing table gets messed up but the VPN reports being in NEVPNStatus.connected state, resulting in a tunnel that appears healthy but can't be accessed.
With this, I wanted to ask if you have any suggestions on any OS items I can observer, in order to deterministically know that the system has fully cleaned up my packet tunnel, and that I am safe to configure another? This would be much more optimal than a hard-coded delay.
Additional context:
Jamf is a common solution for deploying MDM configuration profiles. However, in my tests, it doesn't support Apple's recommended approach of using the PayloadIdentifier to mark profiles for replacement, as PayloadIdentifiers are automatically updated to match the PayloadUUID of that same profile on upload. Although given what I've observed, I'm not sure the Apple recommended approach would work here in any case.
Additionally, it would be nice to transition from non-MDM to MDM cleanly, however, this also requires an indeterminate wait time between the non-MDM configuration being disconnected and subsequently removed, and the MDM one being configured.
With these scenarios, we need to be able to add a second configuration, with possibly identical VPN settings, then remove the old one, allowing the system to transition to the new configuration.
For the MDM case, the pattern I've noticed on the system is that when the current profile is suddenly deleted, the connection will go into disconnected state, then NEVPNConfigurationChange will fire. The new profile can be configured from NEVPNConfigurationChange, however some time is needed to avoid races.
For non-MDM, I had experimented with an approach of polling for MDM configurations appearing. When they do, I'd remove my previous notification observers, and set up a new NEVPNStatusDidChange notification observer, to remove the non-MDM VPN configuration after. it enters a disconnected state. Following the removal, I would call a function to reconfigure the VPN with new configuration. When this logic is in place, the call to stopVPNTunnel() is made. Again, a hardcoded delay is required between stopping and removing the old configuration and setting up a new one.
Thanks!