Android IKEv2 VPN Profiles Are Per-User, Not Per-Device

The phrase built-in VPN covers two unrelated things on Android: a protocol implementation the platform runs on your behalf, and whichever settings form the manufacturer decided to expose. Those are not the same object, and neither one guarantees that the tunnel belongs to the user whose apps need it. Provisioning happens in a specific user with a specific calling package, and everything that follows inherits that context. Read the ownership chain before you read the settings screen.

What the platform builds for you

Since Android 11 the platform exposes VPN provisioning through VpnManager. An approved app describes an IKEv2 profile, and the platform runs the IPsec and IKE exchange itself, so the app never touches packets. That is the meaningful difference from a custom VPN app, which implements VpnService and builds the tunnel in its own process.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

The call above is a sketch of the shape rather than a copy-paste block: the builder has several authentication overloads, they differ by API level, and the profile also carries the server certificate trust material. What matters for the ownership question is narrower than the syntax.

Two properties follow from this design. The profile is data, so it can be provisioned by an administrator instead of typed by hand. And the tunnel is a platform network, so it appears to applications as a network with a VPN transport rather than as some other app's socket.

Ownership is the user, then the package

Android multi-user is real separation, not a label. A work profile is a separate user with its own installed packages, its own app data, its own keystore and its own trust anchors. The same product installed in both places is two instances with different user ids, even when the launcher icons and product names are identical.

Provisioning is recorded against the calling package in that user. So a provisioning app running in the personal profile creates a personal tunnel, and the work apps in the work profile see nothing of it. The reverse is also true, which is why a work-profile tunnel is invisible to personal apps without an explicit policy that says otherwise.

A device policy controller can provision on behalf of a managed profile, which explains the entry nobody in the office remembers creating. If you are auditing a phone, that is the likely owner of a greyed-out profile, and it is not yours to delete as an experiment.

Three gates before a packet moves

The first gate is authority: management has to permit a VPN at all, and some deployments restrict the type as well as the existence. The second is identity: the client certificate or credentials must be available in the user that owns the profile, because a certificate imported into the personal keystore is not visible to the work profile.

The third is consent and policy. A user typically approves the connection the first time it is used, and an administrator can additionally pin it as always-on, optionally with lockdown so traffic cannot leave outside the tunnel. Those settings decide what happens when the tunnel is down, which is the part users notice.

Scope is where the three meet. The profile determines the gateway and the identity, while the policy layer decides which applications may use the tunnel and whether the traffic is forced through it. Two phones with identical gateway addresses can therefore behave very differently.

Why a personal connection does not cover work apps

Traffic from a work app is generated in the work user, and the network policy that applies is the one in that user. A tunnel established in the personal profile does not carry it, no matter how healthy the indicator looks. That single fact explains most of the reports where a user swears the VPN is connected and one specific app still cannot reach an internal service.

Name resolution follows the same boundary. Private DNS suffixes and trust anchors are per user, so an internal hostname that resolves in the personal profile may fail in the work profile even with an equivalent-looking tunnel, because the resolver policy and the CA store are different objects.

Verify on a real enrollment, not a lab phone

On the device, identify the entry's owner first: which user, which package, and whether the profile came from the platform provisioner or from an app implementing its own VPN service. Then confirm that the identity the profile expects is actually present in that user's keystore.

Test the lifecycle, not just the connect. Sign in, unlock the credential store, let the work profile pause for the evening, then bring it back and check the tunnel returns without a manual tap. A work profile that turns off after hours takes its tunnel with it, and that is expected behaviour rather than a fault, provided the expected unavailable state is written down.

Finally, test the work app itself against a known internal endpoint and compare it with the personal profile's result. The two are allowed to differ; what must not differ is the ownership model. If the tunnel belongs to the wrong user, no amount of certificate reissuing will fix it.

Do not force the issue by launching hidden settings activities to reveal a menu, and do not copy private keys between profiles to make a connection appear. The VpnManager reference documents what a caller is allowed to provision; if the approved path does not include your case, that is a decision for the administrator rather than a settings problem.