Thanks, for the feedback. I have attached the configuration profile we tested with (credentials and hostnames redacted). It is a bare IKEv2 payload: EAP-MSCHAPv2, no on-demand, no idle keys. With this profile the tunnel stays up. We ran it three times and each session ran until we stopped it ourselves, with "Stop command received" as the stop reason and no idle teardown in the logs. Our app, using NEVPNManager with NEVPNProtocolIKEv2 against the same server and account, does get torn down with NEIKEv2ErrorDomain Code=15 "IdleTimeout" after about 120 seconds of no traffic. The differences we are aware of between the profile and what our app sets are: The app enables Connect On Demand (NEOnDemandRuleConnect with interfaceTypeMatch .any). The profile above has OnDemandEnabled = 0. The capture that showed the teardowns had onDemandEnabled = YES. The profile is installed as a managed payload, the app configuration is created through the Personal VPN API. Two questions, if you are able: Is there anything in this profile that would not survive a port to the Personal VPN API? We noticed that the runtime configuration dump lists disconnectOnIdle and disconnectOnIdleTimeout inside the protocol dictionary, but there is no corresponding property on the public NEVPNProtocol, so we cannot set them from the app either way. Would you expect a Personal VPN with Connect On Demand enabled to be subject to an idle teardown that a profile without on-demand is not? That is currently our leading hypothesis for the difference. I can supply a full sysdiagnose showing the teardown, along with the gateway side logs, privately if that is useful. Working.mobileconfig