Android Always-On and Block Without VPN: Choose the Right Pair

Always-on reconnecting and blocking without a VPN are two settings, and turning on the first does not turn on the second. The pair you need depends on three conditions: who owns the device, which apps the tunnel covers, and what happens before the phone is unlocked. Get one of those wrong and the phone looks protected while an app quietly takes the ordinary network, or looks broken while it is doing exactly what the policy asked.

Two switches that make different promises

Always-on is a persistence promise. The system keeps the selected VPN service running across the lifecycle events it supports, and restarts it when it drops. Blocking is a confinement promise: while the tunnel is not usable, covered traffic has no path outside it. A server that is down, a password prompt nobody can answer, or a client that crashed all leave a blocking device deliberately offline.

A third factor sits on top of both: the client's per-app scope. Android supports per-app VPN configurations, and the scope belongs to the client or the management policy rather than to the two system switches. Deciding to block without deciding the scope produces a policy that is either wider or narrower than the requirement.

Decision one: managed device, or a user setting?

On a managed device, a device policy controller can own always-on and lockdown for a profile, and the local switch may be missing, greyed out, or reset at the next policy refresh. That is the policy working, not a bug to route around. Check the policy before hunting for a hidden menu, and change the requirement in the policy rather than on the endpoint.

On a personal device the user makes the choice, and the honest question is whether they accept being offline when the tunnel is unavailable. Blocking is an availability trade, and it should be described that way. An absent switch is also not an invitation to root the phone or strip device management; if the platform does not offer the control, the requirement has to change.

Scope by profile, not by device. Personal and work profiles are separate contexts, and Android allows one active VPN per user profile.

A block in the work profile says nothing about the personal side, and testing one context does not validate the other.

Decision two: everything blocked, or some apps excluded?

Per-app exclusions under blocking mode are the part people get backwards. In Android's documented behaviour, applications excluded from a per-app VPN can lose connectivity in blocking mode instead of silently using the ordinary network. So an exclusion is not a licence for that app to reach the internet, and a policy built on that assumption will produce unexplained failures.

Choose deliberately: block all covered traffic and accept that excluded apps go dark, or leave blocking off and accept that fallback is possible. If the requirement is that one app must always have connectivity, blocking mode is the wrong instrument for that device, and no amount of per-app tuning will make those two requirements coexist.

Decision three: what happens before unlock and at a portal?

With most clients the tunnel is not up until the user has unlocked the device, so treat the first moments after boot as a gap rather than a failure; confirm the behaviour for the client you deploy before you sign off. The same applies to credential-based unlock, which can be the very thing a blocking policy prevents. Decide whether that gap is acceptable before deployment, and test it rather than discovering it in the field.

Captive portals are the other edge. A hotel or airport network needs an unauthenticated browser session before anything else works, and a hard block can make sign-in impossible. The supported answer is an approved recovery workflow, whether that is a temporary managed exception or a documented procedure. That exception should name the trigger (a portal SSID or network), the maximum duration, who can grant it, and the check that enforcement returns on its own afterwards; disabling enforcement as an unexplained workaround is not that exception.

The platform documentation on Android VPN clients covers the always-on and blocking behaviour, per-app exclusions and the one-VPN-per-profile rule. Read it before you design around a remembered behaviour from an older release, because the client you deploy may already differ.

Test the offline state, then write the acceptance line

Use harmless traffic and the client's supported failure test. Check the ordinary connection, the loss of the tunnel, recovery, and the reboot-before-unlock case. For each, record whether the covered app connected, was blocked as intended, or unexpectedly took another path.

Verify the resource and the resolver, not the status icon. A VPN interface can exist while the useful path is unusable, and an icon that says connected is not evidence that the app reached anything. Test a tethered device separately too: a phone's policy does not establish forwarding for hotspot clients, because tethering is its own path with its own behaviour.

The acceptance line is specific and testable: the intended app in the intended profile reaches the approved tunnel, and stays in the required blocked state when it cannot. Before you sign it off:

• Always-on and blocking are both configured where the platform supports them, and the owner of each setting is known.
• The app scope is deliberate, and you have confirmed what happens to excluded apps in blocking mode.
• The pre-unlock gap and the captive-portal workflow are decided, not discovered.
• The failure test was run on the device class you actually deploy.