01
Client
Confirm the expected VPN application is installed and launches. Updating or reinstalling the client is only useful after you know the client itself is the failing layer.
Everyday IT · VPN
Prove where the VPN fails.
“VPN does not work” can mean the wrong gateway, bad credentials, no firewall reachability, backend authentication failure, MFA never being reached, or a tunnel that connects but cannot reach the user's resources.Do not reinstall first. Identify the failing layer first.
The VPN troubleshooting layers
The source cases repeatedly separated these failure points.
02
Server address
Verify the exact VPN gateway, hostname, public address, port, or appliance URL expected for that environment. A perfectly working client pointed at the wrong destination will still fail.
03
Reachability
Determine whether the remote service can actually be reached from the user's network. If the VPN portal or appliance endpoint is reachable from one location but not another, that is useful evidence before touching credentials.
04
Credentials
If the VPN service responds but rejects the username or password, treat that as an authentication problem instead of a connectivity problem.
05
MFA
If an expected Duo or other MFA prompt never appears, confirm whether authentication reached the MFA stage at all. A missing prompt can be a symptom of an earlier backend failure.
06
Backend services
VPN authentication may depend on directory services, servers, synchronization, or an appliance that is slow or unavailable. One source case connected successfully only after the backend server returned to service.
07
Resources after connect
A connected tunnel does not prove mapped drives, DNS, printers, applications, or file servers are reachable. Test the resource separately after the tunnel is established.
Use comparison tests
A known-good connection can tell you whether to look at the user, the computer, the home network, or the VPN service.
Same credentials
Different network
If the same account and VPN settings work from another location, the user's local path to the VPN service deserves attention.
Same network
Different device
If another device on the same connection reaches the VPN endpoint, focus more closely on the affected computer or its client configuration.
Same device
Exact endpoint test
Test the known VPN portal, appliance address, or service endpoint before assuming that an error message means the password is wrong.
Connected does not mean finished
Several source cases became a second ticket after the tunnel itself was fixed.
Mapped drive
Test the UNC path directly
If the VPN connects but a mapped drive fails, test the actual server and share path. Then investigate DNS, server reachability, share permissions, NTFS access, or stale drive mapping.
Application
Know the dependencies
Some business applications depend on internal printers, servers, or site-specific routes. A green VPN status alone does not prove the application has everything it needs.
Validation
Test the user's real workflow
Do not close at “VPN connected.” Confirm the resource or application that required the VPN is actually usable.
When to stop
VPN work can cross quickly from endpoint support into firewall and infrastructure engineering.
Escalate
No firewall credentials or documentation
Do not guess appliance passwords, factory-reset equipment, or make broad configuration changes because documentation is incomplete.
Escalate
Multiple users fail at once
A shared outage points toward the appliance, Internet path, backend authentication, directory services, or another common dependency.
Escalate
Core server is unavailable
If authentication depends on an offline or unhealthy server, fix or escalate the infrastructure condition rather than repeatedly changing the user's VPN client.
Client → Gateway → Reachability → Credentials → MFA → Backend → Resource.
Work the layers in order and the vague “VPN problem” becomes a much smaller problem.