Personal VPN or packet tunnel: two iPhone VPN models
One model configures iOS's built-in IPsec or IKEv2; the other ships a provider implementing its own protocol. The product name does not say which you got.
Two iPhone apps can both place a VPN entry in Settings, both call themselves VPN clients, and share almost no implementation. Apple names one of those integrations Personal VPN, and that name produces most of the confusion. Personal VPN is an API for creating and managing configurations that use the built-in IPsec or IKEv2 implementation. A packet-tunnel provider is the other model: the app ships an extension that implements the client side of its own protocol. Everything people infer from the label afterwards, from ciphers to ownership to whether the phone must be managed, is inference rather than statement.
Who implements the tunnel
The split decides who is responsible when something breaks. With built-in IPsec or IKEv2, iOS owns the tunnel state machine and the app's owns the configuration and the buttons. With a provider, the app's owns both, so a protocol bug becomes an app update instead of an OS update.
The comparison is short if you ask who implements the protocol.
| Integration | Apple interface | Protocol implementation |
|---|---|---|
| Personal VPN | NEVPNManager with a Personal VPN configuration | The system IPsec or IKEv2 client |
| Packet tunnel | NETunnelProviderManager plus the provider extension | Whatever the extension implements |
The Personal VPN documentation also notes the explicit user authorization prompt when an app first saves a configuration, which belongs to that model rather than to VPN apps in general.
Two claims about the label worth retiring
The first is that Personal VPN selects a cipher. It does not; the negotiated suite comes from the protocol and its configuration, and a Personal label says nothing about which one you will get. The second is that Personal VPN implies a proxy or a limited tunnel. It implies built-in IPsec or IKEv2, which is a full tunnel whenever the routes say so.
The presence of an app is therefore no evidence about the wire protocol. A third-party client speaking WireGuard or OpenVPN is a provider app by construction, because iOS does not implement those protocols natively.
Why the enterprise wording misleads
Apple's documentation classifies NETunnelProviderManager configurations as regular enterprise VPN configurations. That phrasing is an API category, and it pushes people toward two opposite errors: assuming a consumer app cannot use the provider model, and assuming the phone must be supervised for it. Neither follows. Consumer apps ship providers routinely, and supervision is a separate question about who may enforce policy.
Management ownership is that fourth question, and it is independent of both models. A configuration installed by an organization carries its own identity, traffic scope and lifecycle rules, and those travel with the profile rather than with whichever app happens to be installed. Read them alongside the integration model, because a managed built-in profile and an unmanaged provider profile can sit on one phone at the same time.
Check the evidence instead of the screenshot
Screenshots are the worst evidence available, because the Settings grouping changes between releases. A managed profile names its own payload type: a built-in profile declares a VPN type such as IKEv2 or IPsec, while a provider profile carries a subtype naming the provider's bundle identifier. That is checkable on the device in front of you, and it survives the next redesign.
For the app itself, the class in use answers the same question from the other side: configuration objects from the Personal VPN API, or a provider manager and its extension.
Then choose by what the operator actually supplies. Where a compatible native profile exists, the built-in path has fewer moving parts and one less thing to update. Where the service needs a protocol iOS does not ship, a provider app is the only option and its release cadence becomes part of your risk.
Keep the record with the connection
Attach authentication and resource policy to the connection record rather than to the app, so a reinstall does not take the authorization model with it. That record is also what a support engineer needs when the tunnel comes up and nothing else works.
The question worth asking at the end is not which model is better. It is which model your operator supports, and which one you can debug at two in the morning with the tools you actually have.