Checked One App in OpenVPN? The List Baseline Decides
The same checked package means include or exclude depending on the list baseline. Pick include-only first, reconnect, then test the whole workflow.
The checkbox looks like the whole decision, and on Android it is not. The same checked package means "only this app uses the VPN" under an include-only baseline and "this app skips the VPN" under an exclude-selected baseline. People install a client, find a list labelled Allowed apps, tick the one package they care about, and walk away with a policy that does the opposite. Changing clients rarely helps; choosing the baseline before you touch the list does.
The baseline is the policy, not the checkbox
Under Android's VpnService, a client configures per-app routing with addAllowedApplication or addDisallowedApplication. The first limits the tunnel to the listed packages, the second tunnels everything except them. Clients wrap the two in UI that can look almost identical, and some label the section by the list rather than the mode, so the section title alone cannot tell you which baseline is active.
Read the mode control above the list, not the heading. In the upstream OpenVPN for Android client the allowed-apps list has an include-only and an exclude-selected baseline, and a branded build can word both differently while keeping the same two behaviours. A screenshot from another client, or from an older version of the same one, is not evidence about the mode you are in.
| What the client shows | What a checked app gets |
|---|---|
| Allowed apps, include-only baseline | The app uses the tunnel; unchecked apps do not |
| Allowed apps, exclude-selected baseline | The app bypasses the tunnel; everything else uses it |
| No list configured | Client or profile default, commonly all apps |
That table is the whole myth. Ticking the app is a statement about one package; the baseline decides whether the statement is "include it" or "exclude it".
Choose the mode, then the package
Work in this order, because a selection made under one baseline can survive a mode change and silently invert its effect:
- Identify the real package and whether it is the personal or the work-profile copy.
- Open the application-selection settings for the exact VPN profile you connect with.
- Set the baseline whose meaning is "only selected apps use the VPN".
- Include the intended package and leave unrelated apps out of the set.
- Reconnect so the client rebuilds the interface with the new list.
The profile matters as much as the package. A client can hold several profiles, and per-app selection belongs to the one you actually connect; editing a profile you never use changes nothing. On a managed device, the work profile is a separate user with its own copy of the app and its own policy, so the personal instance being inside the tunnel says nothing about the work instance.
Reconnect before you judge the result
VpnService reads the application lists when the tunnel interface is established. A running tunnel does not necessarily pick up a list edit, and clients differ in whether they rebuild automatically or wait for you to disconnect and connect again.
If the change appears to do nothing, test the reconnect before you doubt the list. Then make a fresh request rather than reloading a page that was already open: an app that keeps an established connection is a poor test subject, and the result you see may belong to the old interface.
Your workflow can leave the app
An app can hand off to a browser for sign-in, a document viewer, or a share target. Under an include-only baseline those helpers are outside the tunnel, so a workflow can fail halfway even though the first app was configured correctly. Include the helper only if the workflow genuinely needs it, and add it deliberately rather than discovering it during a demo.
Per-app selection also does not replace the connection's own route policy. The profile still has to carry the destination prefixes and address families the app uses, and the gateway still has to permit the service. A correctly listed app with an unreachable destination looks the same as a misconfigured list.
Test both sides, then write the policy down
Test one fresh request in the included app and one in an app expected to stay outside. Compare the exit address and access to a private resource, then repeat after a reconnect. If your organization uses Android's block-connections-without-VPN policy, an excluded app may be blocked outright instead of going direct; that is the policy working, not a fault to route around.
Record the mode, the package names with their profile, which apps should bypass, which address families the tunnel carries, and what should happen when the tunnel is down. If the client cannot express the workflow cleanly, choose a wider approved app set or a managed-profile policy instead of editing firewall rules at the root level, which is not part of Android's supported per-app mechanism.