VPN connects but cannot reach internal file shares

MSP Toolkit
Practical troubleshooting paths for MSP technicians dealing with real-world support failures.
Submitted by Anonymous (not verified) on

Field Summary

A VPN client showing connected only proves authentication and tunnel setup. File shares still need routes, DNS suffixes, firewall rules, SMB reachability, and user/share permissions to line up across the VPN path.

Common Symptoms

  • VPN says connected but mapped drives fail.
  • Ping by IP works but hostname fails.
  • Hostname resolves but SMB path times out.
  • One VPN group, user, or subnet is affected.
  • Access works in office but not remotely.

Fast Triage

  1. Check VPN-assigned IP, DNS servers, and suffix search list.
  2. Test internal server by IP before hostname.
  3. Run route print and confirm the file-server subnet is routed through VPN.
  4. Test TCP 445 to the file server.
  5. Confirm the user is in the expected VPN group and file-share permission group.

Likely Causes

  • Missing split-tunnel route.
  • Wrong DNS server or missing DNS suffix on VPN adapter.
  • Firewall rule blocks VPN pool to SMB/file server.
  • VPN group maps to restricted access policy.
  • File share or NTFS permissions fail after network path succeeds.
  • Local security software blocks SMB over VPN.

Useful Commands

ipconfig /all
route print
nslookup fileserver.domain.local
ping file-server-ip
Test-NetConnection fileserver.domain.local -Port 445
net use \\server\share

Tier 1 Fix Path

  1. Reconnect VPN and confirm IP/DNS values changed or refreshed.
  2. Flush DNS after recording the bad lookup.
  3. Try UNC by IP and FQDN.
  4. Remap drive only after reachability is proven.
  5. Capture exact mapped-drive error and test results.

Tier 2 / Admin Investigation

  1. Review firewall logs for VPN pool to file server on SMB/445.
  2. Check VPN address pool, split tunnel routes, DNS suffix, and group policy.
  3. Review RADIUS/MFA logs only if authentication is failing or group mapping looks wrong.
  4. Check file server security logs if traffic reaches the server.
  5. Compare routes and DNS against a working VPN user.

Advanced Remediation

Do not switch to full tunnel, open broad SMB rules, or rebuild the VPN profile until tests show whether the failure is route, DNS, firewall, or authorization.

Verification

  • User opens the intended UNC path over VPN.
  • FQDN resolves to the expected internal IP.
  • Test-NetConnection to port 445 succeeds.
  • Firewall logs show allowed traffic from VPN pool to file server.
  • Mapped drive reconnects after VPN reconnect.

Ticket Notes to Capture

  • User, device, VPN client, assigned VPN IP, DNS/suffix, route test, IP/FQDN/SMB results, firewall log result, group membership, fix, verification.

Escalate When

  • Multiple users in a VPN pool lose file-share access.
  • Firewall/VPN policy changes are needed.
  • File server logs show access denied outside helpdesk scope.
  • Routing or DNS changes could affect site-wide access.

Prevention

Keep a VPN validation sheet per client with VPN pool, DNS servers, suffixes, internal test IPs, expected routes, and required firewall rules.

Subjects
Networking
VPN & Remote Access