When updating a VPN app with `includeAllNetworks`, the newer instance of the packet tunnel is not started via on-demand rules

When installing a new version the app while a tunnel is connected, seemingly the old packet tunnel process gets stopped but the new one does not come back up. Reportedly, a path monitor is reporting that the device has no connectivity. Is this the expected behavior?

When installing an update from TestFlight or the App store, the packet tunnel instance from the old tunnel is stopped, but, due to the profile being on-demand and incldueAllNetworks, the path monitoring believes the device has no connectivity - so the new app is never downloaded. Is this the expected behavior?

During development, the old packet tunnel gets stopped, the new app is installed, but the new packet tunnel is never started. To start it, the user has to toggle the VPN twice from the Settings app. The tunnel could be started from the VPN app too, if we chose to not take the path monitor into account, but then the user still needs to attempt to start the tunnel twice - it only works on the second try. As far as we can tell, the first time around, the packet tunnel never gets started, the app receives an update about NEVPNStatus being set to disconnecting yet NEVPNConnection does not throw.

The behavior I was naively expecting was that the packet tunnel process would be stopped only when the new app is fully downloaded and when the update is installed, Are we doing something horribly wrong here?

Answered by DTS Engineer in 824915022
Written by emilsp in 774231021
Are we doing something horribly wrong here?

Unlikely. There’s a long history of problems similar to this, and a long history of us fixing them (-:

My general advice is to add a ‘first light’ log point to your packet tunnel provider [1]. If you don’t see that after the update then none of your code is running, and thus there’s nothing you can do to improve things.

Once you’ve confirmed the above, I recommend that you file a bug with the details. Add a sysdiagnose log per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs.

Please post your bug number, just for the record.

Share and Enjoy

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

[1] I talk about this concept in Debugging a Network Extension Provider.

What platform is this on?

Share and Enjoy

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

This is happening on iOS. Further, it is not just that the app update fails to download, there is no network connectivity on the phone again. Cancelling the update, deleting the app or the VPN profile does not bring back connectivity.

Written by emilsp in 774231021
Are we doing something horribly wrong here?

Unlikely. There’s a long history of problems similar to this, and a long history of us fixing them (-:

My general advice is to add a ‘first light’ log point to your packet tunnel provider [1]. If you don’t see that after the update then none of your code is running, and thus there’s nothing you can do to improve things.

Once you’ve confirmed the above, I recommend that you file a bug with the details. Add a sysdiagnose log per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs.

Please post your bug number, just for the record.

Share and Enjoy

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

[1] I talk about this concept in Debugging a Network Extension Provider.

Thank you for the timely response!

I added an extra log call early in the constructor of our packet tunnel provider class, and saw no logs. We also tried a dummy implementation of a packet tunnel and also saw the same symptoms. We pontificated that it could be due to on-demand rules - if we disable those and try and update the app whilst our tunnel is connected we get the same results. That is not to say that we'd be happy to use a workaround that relies on not using on-demand rules.

The issue number is FB16482585 and I've updated it with a sysdiagnosed that was collected with the appropriate VPN logging profile now.

Not that we could do anything about the system not finding any route to the internet with includeAllNetworks set and the packet tunnel being shut down, but should a packet tunnel provider ever anticipate stopTunnel to be called with the appUpdate stop reason? Whilst on the topic of calls we've never seen in the wild, are there any circumstances we should be seeing a call to sleep? If the latter deserves a seperate thread, I'll make one :)

Written by emilsp in 824998022
The issue number is FB16482585

Thanks!

Written by emilsp in 824998022
are there any circumstances we should be seeing a call to sleep?

That depends on how you’ve configured disconnectOnSleep. I explain that in this post. And, yeah, if you have more questions about that, a new thread would be welcome. It’d help keep this thread focused on app update issue.

Share and Enjoy

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

When updating a VPN app with `includeAllNetworks`, the newer instance of the packet tunnel is not started via on-demand rules
 
 
Q