Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
VPN Connected but No Internet: What to Check
Ryan Foster
October 5, 2026· 11 min read
VPN connected but no internet? First establish whether the same device can reach ordinary websites with the VPN disconnected. A connected indicator only reports part of the connection state; it does not prove that DNS, routing, account access, and every destination work. Use the sequence below to isolate one failing layer without immediately resetting the network or turning off protection.
Key Takeaways:
- Test the underlying network before changing VPN settings.
- Compare two unrelated websites and another app; a single failure needs a narrower investigation.
- Change one setting at a time, record the previous value, and restore it after an unsuccessful comparison.
- Stop at certificate warnings, managed settings, or unclear security controls and collect evidence for the responsible support team.
What does “VPN connected but no internet” tell you?
Prepare two ordinary, permitted websites you normally use, plus one unrelated app. Save current VPN location and mode settings, the network name, and the time. Close private tasks before briefly comparing a disconnected connection: traffic during that comparison may use the underlying network directly. If policy requires an always-on managed connection, ask IT for an approved baseline instead of defeating it.
1. Test the disconnected connection
Observe: Disconnect using the VPN's normal control, then test those destinations without entering sensitive data. Judge: If they still fail, the problem is not confined to VPN-connected traffic. Act: Check the underlying connection through its normal network settings. Continue: Resume VPN tests only after that baseline works, or take the separate residual-disconnection branch below.
2. Separate Wi-Fi from internet access
Observe: Note whether the device joins Wi-Fi but lacks internet, or cannot join Wi-Fi at all. Judge: Those are different failures. Act: Compare another trusted network if available and permitted. Continue: If the symptom follows the original network, ask its operator; if it follows the device, use the device-specific diagnostic guide.
3. Identify a post-disconnection failure
Observe: Check whether the problem began only after disconnecting a VPN. Judge: A stale filter or route may belong to a different workflow. Act: Use internet not working after VPN disconnect. Continue: Return here once normal disconnected access is established.
Microsoft's Wi-Fi guidance distinguishes joining a network from reaching the internet. Its device and router checks are useful for this baseline. The Windows Wi-Fi connected but no internet guide handles that device-specific branch without repeating it here.［1］
Could a captive portal explain VPN internet troubleshooting results?
A hotel, airport, or guest network can require its normal sign-in before forwarding internet traffic. Do not assume that joining the Wi-Fi name completes that process. Ask the operator which portal is genuine and what access conditions apply; do not use an unfamiliar page that demands unrelated account credentials.
4. Complete genuine network authentication
Observe: With private tasks closed and a permitted baseline connection, look for the system's normal network sign-in prompt. Judge: A pending portal can explain broad failures before and after connecting the VPN. Act: Complete only the genuine operator-approved authentication. Continue: Confirm ordinary access first, reconnect the VPN, and repeat the same destinations.
If the portal loops or is absent, stop changing VPN routes and consult the captive portal troubleshooting guide. That article covers the portal branch in detail. Never ignore a certificate warning to get a portal to load, and do not install an unexplained profile offered as a quick fix.
If baseline access works but VPN traffic fails on that network and works on another permitted network, record that comparison. It narrows the problem to the first network's interaction with the connection. Ask the network operator or VPN provider about supported use rather than treating the result as permission to bypass controls.
Is every application failing or only one destination?
5. Compare unrelated destinations
Observe: Reconnect, then try both unrelated websites and the additional app with the same location. Judge: One failing site alongside working destinations suggests a service, account, or destination-specific issue; failure everywhere suggests a broader path problem. Act: Retry the failing feature once through its ordinary entry point. Continue: Follow the broad-path steps only if unrelated destinations fail too.
A homepage, sign-in flow, media feature, and file upload can use different endpoints. Record which operation fails instead of saying that the whole app is broken. If a service explicitly rejects the account or connection, use its approved access and support process. A network adjustment cannot grant membership, satisfy identity verification, or replace service authorization.
Do not use raw numeric website addresses as a universal internet test. HTTPS certificates and virtual hosting depend on names, so a numeric-address failure can introduce a new error. Likewise, an unsuccessful ping does not prove all web traffic is blocked: some systems do not answer that diagnostic protocol.
If the VPN cannot establish a connection at all, switch to VPN not connecting. Here, the premise is that the client reports a connected state while useful traffic fails. Keep that distinction in the evidence you send to support.
What can changing the location or mode show?
6. Retest one other location
Observe: Save the failing location, then select one other currently available location and reconnect. Judge: If the same destinations now work, the first route or its interaction with the destination becomes the useful lead. Act: Keep the working permitted route for the task and record both results. Continue: If both fail, restore the original choice and compare the mode next.
In AethoVPN, use the app's location picker and compare the public exit IP after reconnecting. Then record the current global-mode setting. Global mode sends all applications' traffic through the encrypted VPN route; when it is off, traffic to websites in your own region does not go through AethoVPN. Compare a local website and an unrelated destination, knowing that turning the mode off changes which traffic uses the tunnel.
7. Compare one mode setting
Observe: Compare those destinations after one permitted mode change, keeping the location fixed. Judge: A local-site improvement can point to the path that site accepts, rather than a universal outage. Act: Restore the required mode if the comparison fails or the task needs all traffic routed through the VPN. Continue: Do not make sensitive requests over an unintended direct route; move to DNS and system checks if the symptom remains.
If you are assessing AethoVPN for this connection task, start the three-day free Pro trial, available once per user. A location or mode comparison cannot repair missing internet access, an account problem, or a restricted service's eligibility. Use a permitted network and observe the platform's rules.
For a systematic record of the before-and-after address, use how to test a VPN connection. Avoid repeatedly switching locations without keeping results: each reconnect may change the address and destroy the comparison you intended to make.
How should you investigate VPN DNS problems and address families?
DNS translates names into addresses. If name resolution fails, applications may look offline even when some transport connectivity exists. Microsoft documents checking DNS configuration and clearing its cache among its network diagnostics. Treat these as a specific branch, not a reason to replace every resolver blindly.［1］
8. Check name resolution
Observe: Record the resolver and any name-resolution error using the system's normal diagnostic tools. Judge: A failed lookup is a DNS lead, while a completed lookup followed by a connection failure needs another explanation. Act: On a personal Windows device, clear the DNS cache once with ipconfig /flushdns if stale resolution is suspected. Continue: Retest the same name; if it still fails, keep the result and ask the responsible provider about its supported DNS configuration.
Do not overwrite managed DNS, install a random resolver profile, or assume a successful ping proves the resolver answers queries. If support recommends a resolver change on your personal device, record the original setting, change only that setting, test once, and restore it if it does not help. Make the resulting routing and privacy implications part of that decision.
9. Compare address families
Observe: Compare IPv4 and IPv6 results where your test tool identifies the address family. Judge: A working IPv4 path and failing IPv6 path narrow the issue; they do not identify the exact cause by themselves. Act: Save both results and the VPN configuration for support. Continue: Do not disable IPv6 globally as the default fix. Use a provider-supported configuration only when its instructions and rollback are clear.
For a known WireGuard setup, the WireGuard routing checklist covers allowed routes and related details. This guide does not attribute that protocol to AethoVPN or transplant protocol-specific commands into another client's configuration.
Could time or another application be interfering?
10. Correct the system clock
Observe: Check date, time zone, and automatic time settings, especially after travel. Judge: An incorrect clock can interfere with authenticated secure connections. Act: Correct it through the normal system setting and retry the same operation. Continue: If the clock was already correct or the problem remains, leave it accurate and examine recently changed network software. Apple's guidance explicitly includes checking date, time, updates, and another network.［2］
11. Review one recent software change
Observe: List recent VPN, proxy, firewall, content-filter, or profile changes. Judge: A second network-control application may affect the route; its mere presence does not prove responsibility. Act: Revert your own most recent optional change using its documented control, if you understand it and have permission. Continue: If a control is managed, required, or unfamiliar, stop and contact IT or its vendor.
Do not remove organizational profiles, uninstall security software, or shut off a firewall as the first response. Apple advises consulting the organization for managed settings. On a personal device, a normal restart after an authorized configuration change may be a useful comparison, but save work and retest the same destinations afterward.［2］
When should you stop and contact support?
Stop after one controlled pass if the result is unchanged. Keep a compact evidence packet rather than collecting passwords or complete browsing histories:
| Evidence | What to record | What to leave out |
|---|---|---|
| Baseline | Whether the same destinations work disconnected | Sensitive account activity during the comparison |
| Failure scope | Exact app feature, error, and unrelated working destinations | Unsupported “everything is blocked” conclusions |
| Route | Location, mode, public address family, and test time | Account tokens, recovery codes, or private keys |
| Controlled changes | One change, prior value, result, and restoration | A stack of unrecorded resets |
| Device and network | OS/client versions and relevant network type | Unnecessary personal or third-party data |
Send the baseline-network problem to its operator, a managed-control problem to IT, and the reproducible VPN-only problem to the VPN provider. Use a trusted private support channel for addresses or diagnostic logs and redact credentials. A successful comparison on another route is useful evidence, not proof of a permanent repair.
Summary
Start with normal disconnected access, complete genuine network authentication, and distinguish one destination from a broad failure. Compare location and mode once, then use DNS, address-family, clock, and software evidence to identify the responsible layer. The complete VPN guide explains the tunnel's role; resetting everything obscures the original problem.
FAQ
Why can a VPN say connected while websites fail?
The indicator may establish a client or tunnel state without proving end-to-end traffic. DNS, routes, the underlying network, or a destination can still fail; compare the same destinations disconnected first.
Should I immediately reset network settings?
No. Start with reversible comparisons and save the previous settings. A reset can remove useful configuration and evidence, particularly on managed devices; use it only through an appropriate supported workflow.
What if the internet also fails without the VPN?
Investigate the baseline network or device first. If failure occurs specifically after VPN disconnection, use the dedicated residual-disconnection guide rather than assuming every connected-state problem has the same cause.
Can changing an AethoVPN location fix an account error?
No. It can compare connection paths, but cannot grant account access or membership. Record the exact error and use the account provider's approved verification or support process.
Does turning global mode off keep every app tunneled?
No. For AethoVPN, traffic to websites in your region then avoids its relay. Understand that direct-path implication, close sensitive tasks for comparisons, and restore the mode required by your task.
Should I disable IPv6 to test a failure?
Not as the default action. Record separate IPv4 and IPv6 results where available, then use a provider-supported configuration with a clear rollback rather than making a system-wide change blindly.
What should I send support after the checks?
Send the baseline result, failing feature, controlled location or mode comparison, versions, and test time. Redact secrets and use a trusted private channel; do not send passwords, recovery codes, or private keys.
Sources:
- Microsoft, Fix Wi-Fi connection issues in Windows: https://support.microsoft.com/en-au/windows/experience/connectivity-networking/fix-wi-fi-connection-issues-in-windows
- Apple, If your device has network connectivity issues, check for VPN and other third-party security software: https://support.apple.com/en-ie/102281
Sources checked 5 October 2026.
