VPN troubleshooting goes wrong in a predictable way: people change three things at once, and whatever happens next, they've learned nothing. The fix is boring and effective — check one layer at a time, in an order that rules things out, and write down what you find. This checklist is that order.

One boundary before starting: troubleshooting means finding where a problem lives, not working against anyone's rules. On a network you don't control or a device your organization manages, the policies in place stay in place — if a managed device is part of the picture, the organization's IT function is part of the troubleshooting, and switching off device security tooling is never a troubleshooting step.

1. Device basics first

Start embarrassingly simple, because this layer solves more than anyone admits: restart the VPN client; if that changes nothing, restart the device. Confirm the operating system and the client are updated — an update pending for weeks is a suspect, not background noise. And note whether anything changed around when the problem started: an update, a new app, different settings, a different location.

2. Does the internet work without the VPN?

Disconnect the VPN entirely and test ordinary browsing. If the connection is broken without the VPN, the problem isn't a VPN problem yet — solve the underlying connection first, because nothing downstream is testable until this layer works.

If the internet is fine without the VPN and wrong with it, you've genuinely narrowed something. Write that down.

3. Client state: connected to what, exactly?

Open the client and look rather than assume. Is it actually connected, or trying? Is the right profile selected — the current one, not an older entry left over from a previous setup? Disconnect and reconnect once, deliberately, and watch what the client reports.

If multiple profiles have accumulated in the client, that's a finding in itself: stale entries are a classic source of "it connects but behaves strangely."

4. Profile freshness: is this the current profile?

A setup that worked for months and stopped is often a lifecycle event wearing a disguise. Check the Lisar Panel: is this profile still the active one, and does its status say what you expect? If the profile has been replaced or its situation has changed, the fix is the supported flow, fresh: download the current .ovpn file from the Panel, open OpenVPN Connect, choose Upload File, import and save the profile, and connect — then remove the superseded file and the stale client entry.

The Panel and current setup instructions are the source of truth here; an old file or saved note is not. The profile-lifecycle article covers this layer in full.

5. DNS behavior: connected, but names don't resolve

Sometimes the connection is up and browsing still fails — pages don't load by name, apps can't find their services. That pattern is worth noting as a pattern rather than fighting blindly: reconnect once, try a different site or app to confirm it isn't one destination, and capture exactly what fails and how.

Resist the urge to start changing settings based on advice threads. A precise description of DNS-shaped behavior — connected, but names failing — is one of the most useful things you can hand to official support, and one of the easiest things to destroy by changing configuration mid-diagnosis.

6. The different-network test

The single most informative check: try the same device and setup on a different network — home versus mobile data, office versus home. The purpose is diagnostic: learning whether the problem follows the device or stays with the network. If it follows the device, the earlier layers deserve another pass. If it stays with a network, that network's own behavior or policies are part of the story — and on networks you don't control, the answer is choosing a network that works and noting the finding, not contending with the one that doesn't.

7. Notes that make support fast

If the checklist doesn't resolve it, you've still done the valuable part: you can now hand official support a real report. Capture the device and OS version, the client and its version, when the problem started, what changed around then, which layers you checked and what each showed, and which networks behave differently. Check any screenshot for profile-specific details before sending it, and use official support channels rather than public posts.

A five-minute report of that shape usually beats an hour of description — because it says where the problem isn't, which is most of the diagnosis.

Frequently asked questions

What's the right order to troubleshoot a VPN problem? One layer at a time: device basics, the internet without the VPN, client state, profile freshness in the Panel, DNS-shaped behavior, and a different-network test — noting what each layer shows before moving on.

My VPN worked for months and suddenly stopped. Where do I start? The Lisar Panel. Long-working setups that stop are often profile-lifecycle events: check whether the profile is still active, and if it's been replaced, re-download the current .ovpn file and set up through the supported flow.

It connects, but pages and apps can't find anything. What now? That's a pattern worth capturing precisely: reconnect once, confirm it isn't a single destination, and describe exactly what fails to official support rather than changing settings based on advice threads.

The VPN fails only on one network. What does that mean? That the network's own behavior or policies are part of the story. The diagnostic value is knowing the problem stays with the network; the practical answer is using a network that works and including the finding in your support notes.

Should I turn off security tools on my device to test the VPN? No. Switching off device security tooling is never a troubleshooting step, and on a company-managed device, the organization's IT function is part of the troubleshooting.