A mobile VPN depends on a working access network, a reachable VPN endpoint and an application that can continue after the path changes. When a connection fails while moving between Wi-Fi and cellular, identify which layer stopped working before changing settings.
This guide is for remote workers and small IT teams. On managed equipment, follow the employer’s policy. Keep required VPN, certificate and traffic-blocking controls in place unless an authorized support procedure says otherwise. Test transitions during a noncritical session.
Give the VPN a defined purpose
An employer VPN may provide access to internal applications. A personal VPN service may route internet traffic through its operator. A full tunnel and a split tunnel send different traffic through the VPN; a work-profile VPN may cover only that profile’s applications.
Ask which applications are intended to use the tunnel and how you should verify that they do. An external IP-address check can help in a full-tunnel setup but may be irrelevant to an internal-only split tunnel. A VPN indicator shows a connection state, not proof that every application takes the same path.
Android Enterprise’s VPN documentation distinguishes always-on operation, blocking non-VPN connections and per-app configuration. These are separate policies. If blocking is enabled, losing the tunnel can deliberately leave an app without network access until protection returns.
Locate the failure
On a narrow screen, scroll the table sideways. Keyboard: focus the table and use the arrow keys.
| Observation | First area to investigate | Evidence to collect |
|---|---|---|
| Wi-Fi is joined but a venue login is pending | Captive-portal authorization | Official network name, portal state and expiry message |
| Access network is available but VPN cannot connect | VPN endpoint, credentials, policy or supported transport | Exact client error, timestamp and client version |
| VPN reports connected but one work app fails | Application, internal DNS, access policy or session | Affected app and comparison with another approved resource |
| Calls fail only during a network transition | Tunnel reconnection and application recovery | Transition direction, interruption length and whether rejoining helps |
| Everything fails after sleep | Access-network return and VPN restart | Network state before and after wake; client status |
Use another approved connection or the client’s diagnostics to establish whether the access network works. On a device that blocks traffic outside the VPN, an ordinary failed browser test cannot by itself isolate an internet outage. Keep that policy in the incident record.
Complete hotspot onboarding through the approved path
A hotel or airport may require a portal login before allowing general internet traffic. Apple’s captive-network instructions explain how iPhone and iPad users can join the network and open its login screen. Confirm the network with the venue and use its expected voucher or terms process.
Some managed VPN configurations provide a portal exception or dedicated onboarding flow. Others require an alternative connection. Ask your IT team for the approved method before travel. If the portal cannot load with required controls in place, a permitted phone hotspot may be the quickest fallback.
Do not bypass certificate warnings or install a profile just because a portal requests it. Verify unusual requests with the venue and your administrator. Once onboarding is complete, confirm the VPN reconnects and open a harmless approved work resource before resuming sensitive work.
Rehearse the network transition
- Start on known working Wi-Fi. Connect the VPN and open an approved test resource.
- Note the VPN status, active access network and current time. Save any work that would be costly to lose.
- If policy permits, move to the cellular path you intend to use. For a laptop, this may mean a phone hotspot; for a phone, its own mobile data.
- Observe whether the VPN remains established or reconnects. Record the time until the test resource works again.
- Repeat in the reverse direction, then after the device sleeps and wakes. Test the actual calling or remote-desktop app separately.
The result belongs to that device, client, protocol, gateway and network combination. A tunnel can recover while a call or remote desktop session still needs to reconnect. Automatic network switching therefore deserves an application-level test.
Work through an interruption example
Fictional example: a laptop’s work portal loads on hotel Wi-Fi, but its remote desktop freezes after switching to a phone hotspot. The VPN client reconnects in eight seconds. A new browser request to an approved internal resource succeeds; the existing remote desktop session remains frozen until reconnected.
Record both events. The successful new request indicates that some required connectivity has returned, while the desktop session has a separate recovery problem. If all approved internal resources also fail, preserve the VPN error and ask support to inspect the tunnel, DNS and access policy instead.
Repeat the same transition once during an agreed test window. A reproducible sequence is more useful than repeatedly reinstalling the client. Avoid changing protocol, gateway, DNS and power settings simultaneously.
Give support a useful, private record
Include device model, OS version, VPN client version, configured profile name, network type, time zone, exact error, affected applications and the result of the comparison test. Note whether the failure followed sleep, portal expiry or switching networks. Leave passwords, authentication tokens and full certificates out of the record.
On supported Android devices, Google’s user instructions locate VPN settings under Network & internet, with variations by device and app. Use those settings to inspect the profile; an employer may manage or lock changes centrally.
If one network repeatedly fails but another succeeds, give that comparison to support. They can check supported transports, gateway reachability and policy without weakening the device’s configuration. Test any approved fix through the same transition sequence.
For general hotspot use, see wireless security. For a tunnel that stays connected while call quality degrades, use the separate video-call quality checks.