01
Name the exact resource
Get the real target: server name, UNC path, internal website, application server, printer, database, RDP host, or other endpoint. “Nothing works” is not testable until the destination is specific.
Everyday IT · VPN & Remote Access
VPN connected, but nothing works.
A successful connection proves the tunnel came up. It does not prove DNS, routes, internal servers, applications, file shares, printers, identity, or permissions are working.Treat “connected” as a checkpoint. Prove the path to the resource.
The post-connect decision path
Do not jump from a green VPN icon to reinstalling clients or changing firewall rules. Test the path in layers.
02
Test name resolution
Can the client resolve the internal hostname to the expected address? If the name fails but an approved IP test reaches the host, DNS becomes the leading layer instead of the VPN client.
03
Test routing and reachability
Confirm the VPN client received the route needed to reach the target network and that the destination is reachable through the intended path. A tunnel can be healthy while a required subnet is missing.
04
Test the service itself
A reachable host does not prove the needed service is listening or healthy. Test the actual protocol or application dependency, not only ping or tunnel status.
05
Test identity
If the service responds but rejects the user, confirm which identity is being presented. VPN authentication and resource authentication may be separate events using different credentials or tokens.
06
Test authorization
If the identity is accepted but access is denied, move to group membership, share access, NTFS permissions, application roles, or other authorization controls. Do not solve access denied with broad rights by default.
Resource → DNS → Route → Service → Identity → Permission.
Each result should tell you which layer deserves the next test.
Read the symptom as evidence
Different failures point to different layers. Use the symptom to narrow the next test instead of treating every failure as “the VPN.”
Name fails
DNS is suspect
If the target hostname does not resolve to the expected internal address, verify VPN-assigned DNS servers, suffixes, split-DNS behavior, and whether the internal DNS service is reachable.
Name resolves, host unreachable
Routing or network policy is suspect
Verify the expected destination subnet, VPN route, client route table, firewall policy, and whether another known-good remote user can reach the same network.
Host reachable, service fails
Move to the application or service
The network path may be working while SMB, RDP, HTTPS, database, printing, or another service is down, blocked, misconfigured, or listening elsewhere.
Service responds, access denied
Move to identity and permissions
Confirm the account actually being used, cached credentials, group-based access, application roles, share permissions, and NTFS permissions before changing network configuration.
Use known-good comparisons
A comparison test is often faster and safer than changing configuration.
Same user
Different device
If the account reaches the same resource from another managed device over the same remote-access method, the affected endpoint becomes more likely.
Same device
Different network
If the path works from another Internet connection, the local network, ISP path, DNS interception, or network-specific filtering deserves attention.
Same VPN
Different user
If another user reaches the same target through the same VPN, investigate identity, authorization, endpoint state, or user-specific policy before changing shared infrastructure.
Same resource
Several remote users fail
A shared failure shifts attention upstream toward DNS, routing, firewall policy, backend servers, authentication services, or the resource itself.
Common traps
These actions can create more variables without proving the failing layer.
Avoid
Reinstalling a VPN client that already connects
If the tunnel is established and the problem is one internal resource, prove DNS, routes, services, identity, and permissions before rebuilding the client.
Avoid
Using IP addresses as the permanent fix
An IP test can isolate DNS. Keeping the IP as the solution can break name-dependent authentication, certificates, applications, and future changes while hiding the real issue.
Avoid
Changing firewall rules broadly
Do not open networks or services because one remote user cannot reach a resource. Prove the missing path and expected policy first.
Avoid
Granting broad permissions
Access denied is not evidence that Full Control is appropriate. Verify the intended role, identity, group path, and effective authorization.
When the symptom becomes infrastructure work
Pause before a post-connect problem turns into an unplanned network or security change.
Escalate
Routes or firewall policy must change
Changing production routes, VPN address pools, firewall policy, NAT, split tunneling, or network segmentation can affect more than the reported user. Establish scope, ownership, rollback, and verification first.
Escalate
Multiple users share the failure
Preserve evidence from working and failing paths, identify the common dependency, and investigate the shared service instead of repeatedly changing endpoints.
Escalate
Core identity or DNS is unhealthy
If domain controllers, DNS servers, authentication services, or other shared infrastructure are involved, treat the condition as infrastructure work with appropriate recovery access and change safety.
Choose the next branch
Once the failed layer is known, move to the specific guide instead of continuing generic VPN troubleshooting.
Tunnel itself fails
VPN connection troubleshooting
Work client, gateway, reachability, credentials, MFA, and backend authentication in order. Troubleshoot the VPN connection
Mapped drive or share fails
Post-connect file access
Test the exact UNC path, SMB reachability, identity, share access, NTFS permissions, and the drive mapping separately. Troubleshoot VPN file access
Several users fail
Shared-service triage
Move upstream and identify the common DNS, routing, identity, firewall, server, or application dependency. Triage the shared service
Need a clean first pass
First 10 Minutes checklist
Capture symptom, scope, known-good comparison, evidence, next test, safety, and verification before adding more variables. Use the First 10 Minutes method
A green tunnel is not the goal. The user's required resource working is the goal.