VPN connected but no internet? Work the four layers

The client says connected, the browser spins, and every site ends in a timeout. That combination is common and it is not a contradiction: connected means the tunnel negotiated, and nothing more. Name resolution, routing, and the server's own exit each fail in their own way, and each has a different owner. Work the layers in order and stop at the first one that fails.

Start with the network you came from

Drop the tunnel with the client's own disconnect control, then try two unrelated HTTPS sites if policy allows. Leave sensitive work closed for the duration of that test. If ordinary access fails too, the VPN is not the first suspect.

Look at the Wi-Fi link, the router, and any portal page that demands a sign-in before touching the tunnel. A kill switch may block traffic while disconnected by design, so follow its documented test procedure rather than concluding the network is dead. A different trusted network is a useful comparison, and a new VPN exit will not complete an expired hotel login. If the open network works and the tunnel does not, the network is exonerated and the next layer is yours.

Decide whether the failure is name resolution

Write down the error text, because a resolution failure, a timeout and a certificate warning each point somewhere else. The pattern to catch early is a hostname you have never visited failing while an application with an open session carries on. That pattern is about new lookups rather than about the tunnel carrying packets. A single lookup shows what the resolver returns, and it takes a second to run. Try a second name as well, so one cached answer or one broken record does not decide the diagnosis.

nslookup example.com

An arbitrary IP in an HTTPS address bar is not a DNS test, because the certificate and the virtual host usually depend on the name. Internal names may need the organization's resolver rather than a public replacement, and a browser with its own secure resolver can answer differently from the operating system lookup. Where the two disagree, the browser's resolver is the one the user experiences, and that distinction belongs in the ticket.

Full tunnel or company subnets only

Some profiles exist only to reach a handful of company subnets; others are built to carry everything and need a working exit behind them. Read the documented purpose before assuming the indicator covers every application and every address family. A private-network profile can be working exactly as designed while the browser, which was never meant to use it, still fails. Read the route table without changing it, and include IPv6, because a working IPv4 path says nothing about the other family.

A more specific route can win while the default route still exists, which is why the table has to be read rather than assumed. Competing virtual adapters can also own traffic you expected elsewhere, particularly after a second VPN client has been installed and forgotten. Do not delete the default route as an experiment; that turns a diagnosis into a second outage.

A single failing site among working ones is a problem with that site, and it also proves the tunnel is carrying traffic. Stalls that appear only on large transfers point at packet size rather than at reachability.

When the server never forwards anything

If every destination fails on two devices and two access networks, the tunnel is up and the exit is not forwarding. That pairing is what separates a server-side failure from one device misconfigured in one place. Send the operator the forwarding, NAT and return-path questions rather than a screenshot of the indicator.

Those three cover most server-side causes, and they are the operator's to answer. The OpenVPN connectivity troubleshooting page walks the same questions from the server side, so hand it over with the ticket. A screenshot of a green indicator answers none of them.

Scan the client log from after login for failures applying routes, DNS settings, or the virtual adapter. Errors at that stage point at the device rather than at the server. An error that never appears in the log is equally informative, because it moves the suspicion to the far side.

Check one layer at a time

Once you change something, reconnect and repeat the exact application that failed. A single page that loads proves less than a repeatable path to the resources the profile was built for. Two commands separate resolution from reachability, and the second one is host-specific. Run the curl line anywhere, then run the route command that matches the host in front of you.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

If the numeric request works and the name does not, stay on DNS. If neither works, compare the route table with the tunnel's expected default, and check the family you are actually testing. If the route is right and the request still dies at the exit, the remaining question belongs to the operator, and the evidence you kept is the ticket.