VPN Troubleshooting Checklist for IT Support

VPN tickets have a special talent for sounding urgent and vague at the same time. “VPN is down” might mean the whole company cannot connect, one user forgot their password, someone’s home Wi-Fi is falling over, MFA is not sending, DNS is broken after connection, or the user is trying to connect from a hotel network that hates joy.

Here is the fast version: do not start by reinstalling the VPN client. Start by narrowing the failure domain. Can anyone else connect? Can the user sign in from another network? Does authentication pass? Does the tunnel establish but apps still fail? Does DNS resolve internal names once connected?

Use this checklist when you need a practical help desk flow that turns “VPN broken” into a specific next action without guessing your way through ten random fixes.

The 60-second triage

Before you remote in, ask these questions:

What exact error do you see? Screenshot if possible. “It won’t connect” is not an error message.
Did it ever work on this device? New setup and suddenly broken are different tickets.
Are other users affected? This separates user/device problems from VPN gateway or identity provider problems.
Are you on home Wi-Fi, mobile hotspot, office network, hotel Wi-Fi, or public Wi-Fi? The user’s network matters.
Can you sign in to other company apps? This checks password, account lockout, SSO, and MFA before blaming the tunnel.
Does the VPN connect but internal apps still fail? Connected-but-useless is usually routing, DNS, permissions, or app availability.

Do not skip the scope questions because the user is in a hurry. Especially then. VPN issues get worse when you treat every failure as a client reinstall.

Quick decision table

Symptom	Most likely area	First check
Everyone cannot connect	VPN gateway, identity provider, internet edge	Status page, firewall, VPN concentrator, SSO logs
One user cannot authenticate	Password, account lockout, MFA, group membership	Test SSO login and MFA prompt
VPN connects then drops	Home network, Wi-Fi, client version, tunnel policy	Try hotspot and check client logs
VPN connects but internal sites fail	DNS, routes, split tunnel, app outage	`nslookup`, `ping`, route table, browser test
Works on hotspot but not home Wi-Fi	ISP/router/DNS/local firewall	Reboot router, test another DNS/network
MFA prompt never arrives	MFA registration, push fatigue controls, phone issue	Verify MFA method and sign-in logs
New laptop cannot connect	Certificate, device compliance, client config	Confirm enrollment and VPN profile

That table is not the whole job. It just stops you from spending 30 minutes on the wrong layer.

Step 1: Decide whether this is an outage or a one-user problem

Scope first.

If multiple users report VPN failures around the same time, stop deep-diving one laptop. Check the VPN gateway, firewall, identity provider, certificate expiration, SAML/OIDC integration, MFA provider, and any monitoring alerts. A company-wide VPN outage is not fixed by clearing one user’s cached credentials.

If only one user is affected, stay local: account, MFA, device compliance, client config, local network, OS firewall, stale routes, bad cached profile, or permissions.

A useful ticket note at this point looks like this:

Confirmed VPN works for test account and two other users. Issue appears isolated to Jamie’s laptop/account. Jamie can access Microsoft 365, MFA works for web login, but VPN client fails after authentication with route setup error.

That note is already better than “checking VPN.” If your team struggles with useful updates, read the ticketing system best practices guide. Remote access tickets need clean notes because the next tech may inherit the same mess tomorrow.

Step 2: Separate authentication from tunnel problems

VPN failures usually happen in two broad places:

The user cannot prove who they are.
The tunnel establishes, but traffic does not work correctly.

Do not mix those up.

Authentication checks:

Can the user log in to normal SSO apps?
Is the account locked, disabled, expired, or forced to change password?
Is MFA registered and working?
Is the user in the correct VPN access group?
Did conditional access, device compliance, or location policy block the attempt?
Are there sign-in logs showing the denial reason?

Tunnel checks:

Does the client show “connected”?
Did it receive a VPN IP address?
Did routes get added?
Can it resolve internal DNS names?
Can it reach internal IPs directly?
Are only some apps broken?

If authentication fails, look at identity logs before touching drivers. If the tunnel comes up but nothing internal loads, move to DNS and routing.

Step 3: Test the user’s network before blaming the VPN

Home networks are chaos with better branding.

Have the user try a mobile hotspot if available. This is one of the fastest isolation tests in remote support.

Fails on home Wi-Fi and hotspot: likely account, device, client, or VPN-side issue.
Works on hotspot but fails on home Wi-Fi: likely home router, ISP, local DNS, captive portal, or local firewall issue.
Works from home but not hotel/public Wi-Fi: likely captive portal, blocked VPN protocol, or weird network restrictions.

Basic checks:

ping 1.1.1.1
nslookup thisisanitsupportgroup.com

On Windows, you may also use:

ipconfig /all
Test-NetConnection vpn.example.com -Port 443

Replace the hostname and port with your actual VPN endpoint. The point is not to memorize commands. The point is to prove whether the user’s network can reach the VPN service before you start changing client settings.

If the problem smells like name resolution, use the DNS troubleshooting guide. If the user does not understand why their laptop got a weird home IP, the DHCP explained guide is a good refresher.

Step 4: Check DNS after the VPN connects

A very common VPN complaint is “I am connected, but nothing works.” That often means the tunnel is up, but DNS or routes are wrong.

Run these tests after connection:

nslookup internal-app.company.local
ping internal-server-name
ping internal-server-ip

Interpret the result:

Internal hostname fails, internal IP works: likely DNS search suffix, DNS server assignment, or split-DNS issue.
Both hostname and IP fail: likely route, firewall, permission, or the app/server itself.
One internal app fails, others work: likely app-specific outage or access issue, not global VPN.
External sites fail after connecting: default route, split tunnel policy, proxy, or DNS override may be broken.

Do not just tell the user “VPN is connected, so it is fixed.” Connected is not the finish line. The user needs to reach the thing they opened the ticket for.

Step 5: Check routes and IP conflicts

VPN clients add routes so traffic knows what should go through the tunnel. If routes are missing or conflicting, the client may look connected while traffic goes nowhere.

Common problems:

User’s home network uses the same subnet as the office network.
VPN route did not install because of permissions or client failure.
Split tunnel excludes the app subnet.
Local security software blocks route changes.
The user has another VPN client fighting for the same routes.

On Windows:

route print
ipconfig /all

On macOS/Linux:

netstat -rn
ip route

You are looking for whether the internal network has a route through the VPN adapter. If the user’s home router uses 192.168.1.0/24 and your office also uses 192.168.1.0/24, enjoy your afternoon. That conflict can cause wonderfully annoying symptoms.

For networking fundamentals, the TCP/IP fundamentals guide is worth reading before you are forced to learn routing during an outage.

Step 6: Check client version, profile, and device compliance

After scope, auth, network, DNS, and routes, the client itself becomes a more reasonable suspect.

Check:

VPN client version
VPN profile/server address
Certificate presence and expiration, if used
Device enrollment/compliance status
OS version and recent updates
Local firewall or endpoint security blocks
Whether another VPN/security client is installed
Client logs around the failure time

If a reinstall is needed, capture the config first. Screenshots, exported profile, client version, error code, and logs are better than “removed and reinstalled.” You want a breadcrumb trail if the reinstall does not fix it.

A reusable VPN troubleshooting checklist

Copy this into your ticket notes if you want a structured flow:

Scope:
[ ] Exact error/screenshot captured
[ ] Confirmed whether other users are affected
[ ] Confirmed whether this device/user worked before
[ ] Checked outage/status alerts

Authentication:
[ ] User can sign in to SSO/company apps
[ ] Account not locked/disabled/expired
[ ] MFA works and prompt is visible
[ ] VPN group/access policy confirmed
[ ] Sign-in logs checked if available

Network:
[ ] Tested home Wi-Fi vs hotspot/alternate network
[ ] VPN endpoint resolves
[ ] VPN endpoint reachable on required port
[ ] Captive portal/public Wi-Fi ruled out

After connection:
[ ] VPN IP assigned
[ ] Internal DNS name tested
[ ] Internal IP tested
[ ] Routes checked
[ ] App-specific outage/permission checked

Client/device:
[ ] Client version checked
[ ] VPN profile/server verified
[ ] Certificate/compliance checked if required
[ ] Local firewall/security tool considered
[ ] Useful resolution note written

Example ticket note

Here is what a good resolution note might look like:

Resolved VPN access issue for Jamie R. Scope confirmed as single-user/single-device. SSO and MFA worked in browser. VPN authenticated successfully but internal apps failed by hostname while internal IPs responded. Found VPN adapter missing internal DNS suffix after client update. Re-applied VPN profile, confirmed internal DNS server assigned, verified access to file share and ticketing system. User tested required app successfully.

That note tells the next person what failed, what worked, and what changed. It also proves you did more than click reconnect until the problem disappeared.

When to escalate

Escalate when you have narrowed the problem and the next fix belongs upstream.

Escalate if:

Multiple users cannot connect.
Authentication logs show policy blocks you cannot change.
Certificates or device compliance are failing outside your access.
VPN gateway health looks bad.
Routes or DNS policies are wrong globally.
Firewall changes are required.
Client logs show errors you cannot interpret or fix.

Do not escalate “VPN broken.” Escalate something like:

Five users across different home networks cannot connect to GlobalProtect. All fail after SAML authentication with gateway timeout. SSO login succeeds and MFA completes. VPN gateway health check is failing from monitoring. Started 09:42. No client-side workaround found.

That is an escalation someone can actually use.

FAQ

What should I check first when a VPN will not connect?

Check scope and authentication first. Find out whether other users are affected, capture the exact error, and confirm the user can sign in to normal company apps with MFA. If authentication is failing, client reinstalls are usually wasted time.

Why does my VPN connect but internal websites still do not load?

Usually DNS, routing, split tunnel policy, app permissions, or the internal app itself. Test an internal hostname and internal IP separately. If IP works but hostname fails, focus on DNS.

Should I reinstall the VPN client?

Not first. Reinstalling is reasonable after you confirm the issue is local to the device and you have checked authentication, network reachability, DNS, routes, client version, and profile settings. Capture logs and config before removing anything.

Why does VPN work on a hotspot but not home Wi-Fi?

That usually points to the user’s home router, ISP, DNS, local firewall, or a subnet conflict. Hotspot testing is useful because it separates user/device problems from local network problems quickly.

What skills help most with VPN troubleshooting?

Networking fundamentals, DNS, routing, identity/MFA basics, and calm ticket notes. If you want command-line practice without wrecking a real machine, Shell Samurai is a good place to build muscle memory.

Bottom line

VPN troubleshooting gets easier when you stop treating “VPN is down” as a diagnosis. It is a symptom report. Your job is to isolate where the failure happens: account, MFA, device, network, tunnel, DNS, route, or app.

If you are building help desk skills, this is exactly the kind of repeatable checklist that makes you look senior before your title catches up. For more practical IT support and career guides, subscribe to the IT Support Group newsletter on the homepage and keep practicing the boring skills that actually save the day.