Disallow Config VPN on Android: Rollout Checklist
Decide the policy, confirm the authority you hold, check the version behaviour, and keep the approved always-on path alive before you enforce.
Someone asks you to stop people configuring their own VPN on managed Android devices. The tempting answer is a firewall rule blocking a few familiar ports. That answer misses how the platform works and how applications actually connect.
The supported control is a management restriction on the device or profile you own, and it has an explicit scope, version-specific behaviour, and an exception you have to configure deliberately.
Work through the five checks below in order. Each one can invalidate the plan, so stop at the first that does not hold.
Check 1: decide what no VPN means
Two requirements hide behind the same sentence. One is that no user may create a VPN of their own. The other is that only the organization's approved VPN may run. Both are legitimate, and they produce different configurations, different support stories and different failure modes.
Write down which one you are buying before you touch a management console. If the intent is a single approved tunnel for everyone, you are implementing an approved path with a prohibition around it; if the intent is no tunnels at all, you must also accept that remote-access and troubleshooting paths change.
Get this wrong and the rollout appears to work while quietly cutting off the VPN that operations depends on, usually discovered by the person on call at an inconvenient hour.
Check 2: confirm the authority you actually hold
Android exposes the restriction through UserManager.DISALLOW_CONFIG_VPN, documented in the UserManager reference. It prevents VPN configuration and startup, and it is not a setting any ordinary application can apply to itself or to other apps.
It is applied by an authorized administrator: a device owner for the whole device, or a profile owner for the managed profile, with the same authority available to a profile owner inside the managed profile. If your EMM cannot act as one of those, you do not have this control, and no amount of policy configuration in the console will create it.
Scope matters as much as authority. A restriction applied to a work profile governs that profile, not the personal side of the same phone. Describing that as control over everything the user does is inaccurate, and it will be tested by the first person who installs a VPN in the personal profile and finds it works.
Check 3: know the version behaviour
The restriction has changed across releases, and the differences decide what your rollout will actually do on the devices in the field.
| Platform boundary | Documented behaviour |
|---|---|
| Device owner or profile owner | The restriction can be applied under that owner's authority |
| API 24 and later | An always-on VPN that the device or profile owner configured is still started by the system |
| API 31 and later | Turning the restriction on disconnects a VPN the user already had running |
The API 31 row is the one that surprises people mid-rollout: enforcement is not cosmetic on those devices, it disconnects a tunnel that was already running. Plan for that as a visible event rather than a silent settings change.
The API 24 row is the one that saves you: an owner-configured always-on VPN survives the restriction, which is how the approved path stays available at all.
Check 4: keep the approved path alive
Configure and test the organization's always-on VPN before you enforce the restriction, not after. If you enforce first, the devices lose the tunnel and the tooling you would use to diagnose them at the same time.
Verify three things explicitly: that the always-on VPN is created by the owner rather than by the user, that it starts on those devices after enforcement, and that it survives a reboot. A tunnel that only comes up manually is not an approved path; it is a support ticket queue.
Keep a recovery route that does not depend on the tunnel being up. A management console, a local admin path, or an out-of-band channel all work. What does not work is assuming you can fix a broken policy through the connection the policy just disabled.
Check 5: verify, then describe the limit honestly
Test with a real device and a real account. Confirm a user cannot add or start a VPN, confirm the approved tunnel connects and carries traffic, and confirm the personal profile still behaves as documented. Those three results are the acceptance criteria.
Then be careful about what you claim. The restriction governs the Android VPN capability. It does not turn every permitted connection into an inspected protocol, and it does not stop an app from routing its own requests through an explicit proxy. Blocking UDP 500, UDP 4500 and one OpenVPN port is not the same control, because traffic can travel over many transports, including ordinary-looking HTTPS.
If the requirement is broader than the VPN capability, combine this with app distribution policy, account controls and network restrictions appropriate to the environment. And record what stays outside the scope, so nobody repeats a partial restriction as a complete one in the next audit.