stopTunnel of NEPacketTunnelProvider randomly called with NEProviderStopReasonUserInitiated

We have a VPN solution that is intended to be long-running, so normally we just use a simple on-demand-rule: a single 'connect on any interface' rule. This lets us automatically reconnect the VPN after reboots.


However one of our users is reporting that sometimes the VPN will stay connected for days (up to a week even), but will still randomly disconnect with NEProviderStopReasonUserInitiated. And clearly he did not manually disconnect it. This has happened quite a few times now, always with the same stop reason.


Sometimes this happens when the device is in sleep for a long enough time, but not always.


Does anyone know what actually causes this to happen? and if there is any way around it?
@eskimo maybe?

To start, read this post about the interaction between VPN and sleep.

Next, it’s hard to say what’s triggering this disconnect. My recommendation is that you trigger a sysdiagnose log after the disconnect, then look through the enclosed system log to see if there any any hints as to what triggered it.

Some notes:

  • See our Bug Reporting > Profiles and Logs page for information on how to trigger a sysdiagnose log.

  • If the user might not notice the disconnect, post a local notification that says ‘take a sysdiagnose now’.

  • System logs are huge. To help narrow your search, make a system log entry in your stop tunnel method so that you can search back from that. Use

    <os/log.h>
    (or
    os.log
    in Swift) to do that. See WWDC 2016 Session 721 Unified Logging and Activity Tracing for more on this.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

@DerekMa we are seeing this happen on our VPN solution, did you ever find out what causes this to happen? Thanks!

stopTunnel of NEPacketTunnelProvider randomly called with NEProviderStopReasonUserInitiated
 
 
Q