Why a per-app VPN misses the work copy of an Android app

One app shows up twice on a phone with a work profile, and the two copies are not the same subject. A per-app VPN configured inside one context governs that context's instance, which is why a rule naming the package can still leave the other copy untouched. This is not a bug to work around, it is the profile boundary doing what it was designed to do. The question worth answering is which context owns the VPN and which one owns the app you are trying to protect.

One icon, two installs, two policy owners

Android gives the work profile its own managed context, complete with separate apps, accounts and policy, so the launcher can show two entries that share a name and a badge. A VPN service started inside one context operates for the users of that context, which is the mechanism behind the whole problem. The icon tells you which app you tapped, not which profile the resulting traffic belongs to. That is why the owner has to be read from the profile rather than from the picture.

An organisation can also enforce always-on or block-without-VPN behaviour for the managed side, which changes what happens when the tunnel is down. The personal side has no such guarantee unless you built one yourself.

What an allowed-app list actually means

Android's per-app VPN support is built around lists, documented in the VPN user and work profiles guide, and the two list types have opposite defaults. An allowed list means only the named packages use the tunnel and everything else is excluded, while a disallowed list means everything is included except the named packages. Get that backwards and you have built the opposite of the intended policy while the settings screen still looks plausible. The list is evaluated inside the context where the VPN runs, so a package name present in both profiles matches only the copy in that context. An unlisted package in the other profile is simply not this VPN's business.

Write the behaviour down for the two or three apps that matter, because the difference between everything-except and only-these decides whether a personal app leaks around the tunnel or fails closed. A small table beats a paragraph here: one row per profile, naming the list type and the default for everything else.

Which side runs the tunnel, and under whose policy

A consumer VPN does not lift the organisation's controls from the managed profile, and a work-profile VPN is not a general tunnel for personal apps. If the organisation requires its own client for managed apps, the personal client is a separate arrangement with its own policy and its own failure modes. Decide which mechanism is supposed to carry which traffic before comparing results, or you will be measuring two systems and calling the difference a bug. Inside its own context the managed side usually wins, and that is the intended behaviour.

The awkward case is a managed app that needs a route the managed policy does not provide. That is an exception request to the organisation, not a reason to disable the work profile.

Testing the instance you actually meant

Launch the copy you care about and inspect the request from inside it, because a public address check in the personal browser says nothing about the work app. Verify the signed-in account and internal name resolution separately, since an internal name can depend on the managed route while public browsing stays elsewhere. Note which copy produced which result at the moment you test, and put the profile in the label; a screenshot with two identical icons is not evidence. Repeat the check after a reconnect and after the profile is recreated, because policy can reapply in between.

If you cannot tell which copy answered, fix the labelling before drawing any conclusion. An ambiguous result is worse than no result, because it gets quoted later as if it settled the question.

Documenting coverage so the next test survives

Record three facts together for each context: the app instance, the policy owner and the expected coverage. That is enough for the next person to reproduce your test without guessing which icon they launched. Add the list type and the default for unlisted packages, since that is the part people misread most often.

Then verify one internal name and one external address from each side, and write down what should happen when the managed side blocks the personal VPN. A phone where neither side is covered while both look connected is the failure worth designing against. When both profiles genuinely need a tunnel, plan two arrangements rather than one clever rule.