When the same VPN works on one device but not another, the working device is a comparison control—not proof that every account, server, network, and policy condition is identical. Hold those shared variables constant, record both devices' state, and change one difference at a time. This turns a vague “device problem” into evidence about the operating system, client version, VPN permission, profile ownership, local filter, clock, address family, or security policy.

The complete VPN guide maps the whole connection path. This article covers a two-device comparison; it does not assume a subscription limit and does not replace the separate case where a browser extension and desktop app route different traffic on one device.

Key Takeaways

Confirm both tests really use the same account, server, access network, target, and time window.

Compare versions, permissions, profiles, filters, clock, address family, and management state before reinstalling.

The exact failure stage is more useful than a generic red or green status.

Use only supported settings and official updates; preserve managed profiles and logs.

Escalate a compact comparison table without credentials, tokens, certificates, or private infrastructure names.

1. VPN works on one device but not another? Freeze the shared variables

Place the devices on the same authorized Wi-Fi network or, if testing cellular service, clearly record that they are on different carrier paths. Select the same documented VPN location or server, use the same test destination, and run the checks close together. Confirm the account identity without exposing it and note whether simultaneous sessions are active.

Do not assume “same Wi-Fi name” means the same path. One device may use a guest VLAN, private MAC policy, cellular fallback, captive portal, IPv6-only route, or a different DNS configuration. Disable cellular fallback only if the operating system provides a safe temporary control and policy permits it; restore it after the test.

Build a comparison table before making changes:

Variable	Working device	Failing device
Model and OS build	Exact version	Exact version
VPN app and source	Version/store	Version/store
Account and server	Confirmed match	Confirmed match
Access network	SSID/path/family	SSID/path/family
Failure stage	Connected/test result	Exact error and time
Management and filters	Profiles/apps	Profiles/apps

If these basics do not match, correct the test design before interpreting the result.

2. Identify the failing stage on each device

Separate launch, sign-in, permission, profile creation, endpoint resolution, transport connection, authentication, tunnel establishment, and post-connect traffic. Record the exact message and timestamp. “Does not work” might mean the app crashes, the OS refuses to add a VPN configuration, credentials fail, connection times out, or only one website fails after a connected status.

Run the same small validation on the working device. A green icon without traffic does not make it a valid control. Use safe VPN connection tests to compare DNS and ordinary HTTPS behavior without exposing private data.

If both devices fail at the same time, the server, account, or access network becomes more plausible. If only one fails at a reproducible local stage, focus on that device rather than rotating servers and passwords.

3. Compare operating system and client versions

Record the full OS build, not just the major version, and the VPN app version plus installation source. A staged app rollout can leave two devices on different builds. An old OS may lack a required networking fix; a newly updated OS may require the vendor to update its client. Architecture and device model can also determine which network extension or driver package is installed.

Update through the official platform store, vendor channel, or organization software portal. Verify the publisher and signature through supported UI. Do not download a package from a mirror or disable platform protections. After an authorized update, restart the app normally and retry once with the same server and target.

If the problem began immediately after an update, preserve the before/after version and time. Do not downgrade unless the vendor or administrator provides a signed, supported rollback path.

4. Check VPN permission and profile ownership

Operating systems mediate VPN creation and routing. Android's VPN platform requires user consent before an application establishes a VPN service, and only one app is normally the prepared VPN service for a user or profile at a time.［1］ Apple platforms likewise use VPN payloads and system-managed configurations whose availability can depend on device management and platform support.［2］

Compare whether each device shows the expected VPN configuration, who installed or manages it, and whether a permission prompt was denied or never completed. A work profile and a personal profile may have separate app data and VPN ownership. A stale configuration with a similar display name can point to an old provider or server.

Do not delete every VPN profile. First record the profile name, app association, management owner, and current status. Managed profiles may contain certificates or per-app routing that the user cannot safely recreate. Ask the administrator to remove or replace them through the proper channel.

5. Look for another network owner on the failing device

Inventory other VPN applications, DNS filters, ad blockers, parental-control tools, endpoint security agents, firewalls, private-relay features, and work-profile networking. Two products may both request the same system VPN slot or install overlapping routes and DNS settings. The working device may simply lack the competing component.

Use the two-VPN conflict guide for a controlled ownership test. Pause or change a component only through its supported controls and only if policy allows. Do not force-stop enterprise security, unload drivers, delete certificates, or edit routes by hand.

If disabling an optional filter makes the VPN work, that is evidence of interaction, not proof that either product is malicious or defective. Capture versions and ask both owners about documented coexistence.

6. Compare device time, credentials, and secure storage

Check the full date, year, time zone, UTC offset, and automatic synchronization state. A clock error can invalidate certificates or time-based authentication even when the displayed hour looks plausible. Compare both devices with the same trusted time source.

Confirm the failing device is signed into the intended account through the official flow. Do not copy tokens, certificate files, private keys, or application data from the working device. Secure storage is device-bound in many systems, and copying it can expose credentials without producing a valid registration.

If the account permits multiple devices, a fresh official sign-in may restore missing local credentials. If product documentation does not state the permitted device count, do not infer a limit from this symptom.

With AethoVPN, check the plan before blaming the failing device: Standard covers one mobile device, Pro covers two desktop and two mobile devices, and Premium covers eight devices of any type, with tablets counted as mobile. Standard also excludes the Mac and iPhone/iPad configuration, so a Mac or iPad on that tier is a plan boundary rather than a device fault. If both devices are within the allowance, install the client from the same official source on each (the .exe, .deb, or Android APK, or the setup-wizard configuration on Mac and iPhone) and connect both to the same in-app location. Support can confirm account-side state from authorized records, but local permissions and profiles still have to be compared on each device. Compare Standard, Pro, and Premium device allowances if the second device may fall outside your tier.

7. Compare address family, DNS, and local network policy

One device may prefer IPv6 while the other uses IPv4, receive different DNS answers, or join a different network segment. Record the assigned address family and resolver result through supported system views. Keep the endpoint and target hostname constant. Do not replace managed DNS with a public resolver merely to force a result.

Device-specific randomized addresses, private-address modes, MAC allowlists, parental schedules, firewall rules, or network access control can affect only one device. Ask the network owner whether the failing device is authorized. Do not clone the working device's MAC address or bypass enrollment.

If the discrepancy occurs only on an IPv6-only network, follow the dedicated address-family diagnosis rather than disabling IPv6. If ordinary non-VPN traffic also fails on the device, resolve Wi-Fi, cellular, captive-portal, or DNS access before testing the VPN.

8. Reproduce with one-variable changes

Choose the smallest reversible difference supported by the evidence. Examples include completing a missed VPN permission, applying an official app update, synchronizing the clock, selecting the same documented server, or pausing one optional conflicting VPN filter. Record the before state, change, result, and restoration step.

Avoid the common reset cascade: switching servers, reinstalling, clearing storage, changing passwords, deleting profiles, and rebooting the router all at once. Even if the connection returns, the cause remains unknown and important evidence may be gone.

Reinstallation belongs late in the process. Before uninstalling, confirm how to recover the account, whether managed configuration will return, and whether diagnostics must be exported through an approved route. Never remove a work profile or device-management enrollment as a VPN experiment.

9. Distinguish this case from adjacent problems

If a browser extension works but desktop applications do not on the same device, follow browser-versus-desktop VPN routing. That is a traffic-scope comparison, not a two-device control.

If the failing device never connects on any network and no working control can be made equivalent, use general VPN connection troubleshooting. If it connects but one destination fails, test the destination and DNS rather than treating the entire client as broken.

The goal is a narrow statement such as “version X lacks VPN permission after the OS update” or “the managed filter owns the VPN slot,” not the broad conclusion “this model cannot use VPNs.”

10. Escalate the comparison safely

Provide both device models, OS builds, VPN versions and installation sources, management state, network and address-family observations, chosen server, sanitized error stage and timestamps, controlled test result, and the one-variable changes already tried. State whether another VPN-style filter exists.

Microsoft's Remote Access troubleshooting guidance emphasizes collecting the error code, client configuration, server-side evidence, and relevant event logs rather than relying on a generic symptom.［3］ For a consumer service, use the same principle but share only the minimum sanitized evidence requested through the official support channel.

Do not post account identifiers, passwords, MFA codes, private certificates, full server names, recovery codes, unrestricted logs, or employer network details. The working device should remain intact as a control until the cause is understood.

Summary

A VPN that works on one device has already supplied a useful control, but only if account, server, network, target, and timing are truly comparable. Map the failure stage, then compare OS and client versions, permission and profile ownership, competing filters, clock and credentials, address family, and local policy. Change one reversible variable at a time, preserve the working device, and escalate a sanitized two-column record instead of performing a destructive reset cascade.

FAQ

Does a working device prove the VPN server is healthy?

It shows that one path worked at one time. The devices may use different address families, network segments, transports, accounts, or server instances, so first verify the shared variables.

Should I copy the VPN profile from the working device?

Only use an official export or management workflow that the provider authorizes. Never copy private keys, tokens, certificates, or application storage between devices manually.

Can VPN device limits cause one device to fail?

They can for products that explicitly define such limits, but the symptom alone proves nothing. Check the current product account documentation or ask authorized support.

Why does reinstalling sometimes appear to fix it?

Reinstallation may renew permission, replace stale files, or trigger sign-in, but it also erases evidence. Compare versions, permissions, profiles, and filters first so the actual change is known.

What if one device is managed by my employer?

Treat management profiles and security agents as policy-controlled. Ask IT to compare the approved VPN configuration; do not remove enrollment, certificates, or required filtering.

Can different device clocks explain the discrepancy?

Yes. Wrong absolute time can break certificate or time-based authentication. Verify the full date, time zone, offset, and synchronization on both devices.

When is the access network the likely owner?

When the failing device lacks ordinary connectivity, joins a different segment, is blocked by access control, or receives a distinct address-family and DNS path. Provide that evidence to the network administrator.

Disclaimer: Follow product, platform, and organization policy when changing VPN or security settings. This guide does not authorize copying credentials, removing managed profiles, or bypassing network access controls.

Sources:

Android Developers, "VPN": https://developer.android.com/develop/connectivity/vpn
Apple Platform Deployment, "VPN overview for Apple device deployment": https://support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web
Microsoft Learn, "Troubleshoot Remote Access (VPN) and Always On VPN guidance": https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-remote-access-vpn-and-aovpn-guidance

Sources checked 8 September 2026.

Related Articles:

VPN Works on One Device but Not Another