Overview
A VPN can show Connected while internal resources remain unreachable. That usually points to routing, DNS, authorization, split-tunnel behavior, resource availability, or the wrong VPN profile.
Why this happens
VPN establishes a secure tunnel, but internal DNS, network routes, resource permissions, and application availability must still work after the tunnel is built.
Before you begin
- Record the VPN profile and connection status.
- Identify one specific unavailable resource.
- Confirm whether all or only some resources fail.
- Do not edit route tables or adapter metrics.
Click-by-click troubleshooting
Step 1: Confirm VPN connection details
Action: If Windows built-in VPN is used, open Settings > Network & internet > VPN and verify the intended profile shows Connected. Otherwise open the approved VPN client and verify the intended profile.
Why this matters: Users may connect to the wrong region, tenant, or profile.
What to look for: Confirm profile name, connection time, and assigned VPN address if displayed.
Expected result: The intended organizational VPN profile should be active.
Step 2: Test more than one internal resource
Action: Test the affected resource and one additional approved internal resource.
Why this matters: One failed service is different from a tunnel-wide routing problem.
What to look for: Note whether all internal resources fail or only one.
Expected result: The scope should be clear enough to isolate VPN versus resource-specific failure.
Step 3: Test DNS resolution
Action: Open Command Prompt and run nslookup internal-hostname.
Why this matters: VPN may be connected while internal DNS is not being used correctly.
What to look for: Look for the expected internal IP, timeout, or public/unexpected result.
Expected result: Internal names should resolve according to the organization's design.
Step 4: Review assigned network adapters
Action: Run ipconfig in Command Prompt and identify the VPN adapter without changing anything.
Why this matters: This confirms the tunnel created a usable virtual adapter and address.
What to look for: Look for the VPN adapter and assigned IP information.
Expected result: A connected VPN should show the expected virtual network state.
Step 5: Verify the work identity and resource permission
Action: Confirm the user is signed in with the intended work account and has approved access to the resource.
Why this matters: VPN connectivity does not grant file, application, or server permission.
What to look for: Distinguish timeout from Access denied or permission errors.
Expected result: The user should have the correct identity and authorization independent of VPN status.
Step 6: Reconnect the VPN once
Action: Disconnect normally, wait several seconds, reconnect the approved profile, and retest.
Why this matters: A fresh tunnel can correct temporary route or authentication state.
What to look for: Compare DNS and resource access before and after reconnection.
Expected result: Temporary tunnel-state issues may clear after a controlled reconnect.
What to look for
- All internal names fail: VPN DNS or routing issue.
- One resource fails: resource or permission issue.
- Access denied: authorization, not tunnel connectivity.
- Wrong profile: remote-access configuration issue.
When to stop
When to contact IT
Contact J3 Systems Group if VPN connects but internal DNS or routing remains broken, multiple resources fail, or access differs between users. Include article code KB-15.006, VPN profile, resource names, ipconfig, and nslookup results.
Need help with this issue?
J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.
Contact J3 Systems GroupAuthoritative references
Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.