VPN connected but no internet? Find where access stops

When your VPN connects but websites won't load, try the same site with the VPN disconnected, provided your device policy permits it and sensitive work is paused. If it still fails, start with the underlying internet connection. If access stops only after the VPN connects, investigate DNS, routing, or the app's settings. Change one thing at a time and record the result. The app's connected label doesn't establish that a fresh page can load. A few recorded checks will give support a useful starting point and help you restore any settings you change.

Does internet access also fail with the VPN off?

Disconnect the VPN and request a fresh public page, then compare that with the connected state. If the page fails in both cases, check the device's network connection and internet access first. Pause apps or activities that depend on VPN protection while you make this comparison.

Try a second site so that a single destination's failure doesn't look like a complete outage. An already-open page may display old content; send a fresh request for the test. If the network has a sign-in page, complete that process first. A Wi-Fi indicator shows a local connection without guaranteeing access to every internet destination.

Next, try the same network on another device you control. If neither device has access, the modem, router, or internet service is a more useful starting point. If only one device fails, keep that result for the settings investigation. This narrows the search without proving that a particular component is broken.

The explanation of how a VPN connection works helps separate the underlying internet connection from the tunnel. The tunnel needs a usable communication path to establish itself.

When is DNS worth investigating?

If site names fail while some direct connections still work, DNS deserves attention. DNS resolves domain names into address information. IVPN's connected-but-no-browsing guide specifically separates IP connectivity from name resolution, using 1.1.1.1 and 8.8.8.8 as example test destinations.

If you're comfortable using ping, a reply from an IP establishes that this particular exchange received a response. Compare it with loading a site by name. A missing ping reply alone cannot diagnose a failed VPN; avoid extending one test's result to all traffic. Ask support to handle this step if network tools are unfamiliar.

Before changing DNS manually, check which configuration your VPN service recommends. IVPN warns in the same guide that selecting OpenDNS can send DNS requests to that service and may constitute a privacy leak. A site loading after a change therefore leaves another question to answer: whether requests now follow the path you intended.

If you entered a custom DNS setting yourself, record its value before considering a return to the provider's recommended configuration. Leave organization-managed settings and profiles to their administrator.

Why does one browser work while another fails?

Different results from two browsers on the same connection make browser settings worth checking. Examine the affected browser's proxy configuration and extensions before changing the entire network. IVPN also recommends trying another browser to narrow the investigation to browser configuration.

Use the same public page and run the comparisons close together. If one browser is signed in to an account and the other isn't, that account state may explain a different result. Start with a page that requires no login to reduce the differences you need to account for.

If you enabled a manual proxy or a network-related extension, record its state and make a temporary change following its instructions. Change a single control. Clearing all browser data or removing several extensions together makes it harder to attribute an improvement to a particular change.

Match the app and installation method against the setup guide. This stage is about finding a testable difference between browsers. One successful page load still leaves the precise diagnosis open.

What if a page starts loading and then stalls?

A transfer that starts and stalls can warrant investigation of packet size and the network path. The --mssfix section of the official OpenVPN 2.6 manual identifies a successfully established connection that stalls during use as a possible symptom of broken path MTU discovery.

OpenVPN users can treat that symptom as a lead to investigate. It leaves the cause of an individual failure to be established. MTU relates to the packet size a path can carry. Randomly adjusting it without understanding both ends of the connection is a poor general-purpose test. Record the protocol name and distinguish a page that never opens from one that starts and then stops.

If the app offers another server or protocol, change just one and request the same page again. Use documented options available through your provider. Avoid guessing configuration-file changes for a protocol your app doesn't offer.

The browser IP check can show the exit connection used by a fresh request. A successful check cannot establish that a large transfer works or that every app is covered. Record the outcome of the activity that actually stalls.

What can another network or device tell you?

Keep the VPN configuration fixed while changing networks to investigate whether the problem depends on that network. A second device helps separate device settings from network conditions. Avoid changing both at once, because you would lose the ability to attribute the result to one difference.

TestWhat stays fixed?What does it help investigate?Same device on another networkVPN app and configurationNetwork dependencyAnother device on the same networkNetwork and test destinationDevice dependencyAnother browser on the same deviceNetwork and VPN connectionBrowser configuration

Account for mobile data costs and allowances if you use a phone connection. Success on an alternative network doesn't establish deliberate blocking on the original network. It reduces the area to investigate. Likewise, a working second device cannot validate every setting on the first one.

After each test, restore temporary changes you have no reason to retain. A short record of the initial state helps prevent a collection of experimental changes from becoming the permanent configuration.

Which observations will help support investigate?

Prepare the result with the VPN on and off, app name, operating-system version, and exact error text. Explain whether every site fails or only one destination, and whether loading never starts or stalls partway through. Include the changes you've tried and the result of each.

If you temporarily changed a kill switch for testing, restore its previous state before resuming sensitive work. Keep workplace firewalls and security controls in place unless the administrator directs a change. App logs can contain connection details; send them through official support and keep passwords or private keys out of your message.

ZibalVPN users can include these notes in a support request. Put each result beside the change that produced it so the investigation can continue from the last reliable observation.