Android Home-LAN VPN Exception: A Runbook for One Service

You want one home service reachable while the VPN stays in force for everything else. The tempting setting is a local-route exemption that covers every private address, and that is the wrong control: on the next hotel or cafe network it can turn whatever answers into a bypass. This runbook scopes the exception to a single service and proves it under the transitions that break it.

Define the exception as a service, not a subnet

Record the app, the destination hostname and address, the protocol and port, the network where it is allowed, and the identity check the service itself performs. For an authenticated NAS, the certificate or account is what proves you reached the right machine. An address in 192.168.0.0/16 proves nothing, because every home router hands out the same prefixes.

Also decide what nearby means. A service on a routed VLAN is not on the phone directly connected subnet, and a guest Wi-Fi may share the same private prefix as home while being an entirely different machine. The exception should name the service and the environment, not just the address range.

Confirm the platform control fits the requirement

Android IKEv2 profile builder exposes setLocalRoutesExcluded(true), and its documentation requires a bypassable VPN: the exclusion is only meaningful when the client may let traffic bypass the tunnel. The same documentation warns that the underlying network can supply routes that affect the exclusion, which is why the setting follows the network you join rather than the network you trust.

It is also not a promise that every lockdown or managed configuration will let the user enable the same exception. A route exception, the bypassability flag and the device blocking policy are separate controls, and a managed device may forbid the third while allowing the first two. Check the installed profile and the management policy before designing around a checkbox.

Runbook: build and apply the exception

Step 1: create the profile through the supported path for the deployment, either the managed configuration or the client builder. Step 2: mark the VPN bypassable, because the local-route exclusion is not effective without it. Step 3: enable local-route exclusion. Step 4: keep the service's own authentication and certificate validation enabled; the exception is about routing, not trust. Step 5: save and reconnect so the profile is applied.

Rollback is the same path in reverse: clear the exclusion, then clear bypassability, then reconnect. Do not patch a route or firewall hook directly on the device. The network daemon owns those rules, and a manual rule can miss another address family, a reconnect or a network transition. If the installed configuration cannot express the policy, keep the stricter block until the owner approves another design.

Test the four cases that matter

Use harmless requests and write down the expected result before running each case. The matrix below is the acceptance test, not a suggestion: if any denied case succeeds, the exception is wider than the policy.

Case 3 is the one that catches a broad private-subnet bypass, and case 4 catches a client that only applied the exception at connect time. Run case 4 with the VPN disconnected and with the phone moved to cellular, then reconnect and confirm the exception returns without a reboot. The local-route API reference states the bypassability requirement that makes step 2 non-optional.

Record the exception and review it

The maintained record should name the service, the environment that justified it, the owner and the date. Local describes a routing relationship, not a trust level, and the next network the phone joins is not the network where the exception was approved.

Review the record after an OS update, a client update or a move. Re-run case 3 whenever the exception is renewed, because a profile that once scoped the bypass to a service can be broadened by a single default change.