We've received logs and have spuriously reproduced the following behavior:
- calls to
setTunnelNetworkSettingscompleting withNETunnelProviderErrorwhere the code is networkSettingsInvalid, and the error domain string is empty. - After subsequent calls to
setTunnelNetworkSettings, the tunnel is stopped via theuserInitiatedstop reason within around 1 second from the first failure.
This happens after a number of successful calls to setTunnelNetworkSettings have been made in the lifetime of a given packet tunnel process.
We can confirm that no user ever initiates the disconnection. We can confirm that the only significant changes between the different calls to setTunnelNetworkSettings are that the parameters contain different private IPs for the tunnel settings - the routes and DNS settings remain the same.
In our limited testing, it seems that we can replicate the behavior we're observing by removing the VPN profile while the tunnel is up. However, we are certain the same behavior happens under other circumstances without any user interaction. Is this what memory starvation looks like? Or is this something else?
Our main concern is that the tunnel is killed and it is not brought back up even though our profile is set to be on-demand. It's difficult to give any promises about leaks to our users if the tunnel can be killed at any point and not be brought back.
The spurious disconnections are a security issue for our app, we'd like to know if there's anything we can do differently so that this does not happen.
We tried to get DTS, but given that we have no way to reproduce this issue with a minimal project. But we can reproduce the behavior (kill the tunnel by removing it's profile) from a minimal Xcode project, is that considered good enough for a reproduction?