T The Triage ManualTechnical Guides for IT Emergencies
P2 · Remote Access & VPN

Windows Endpoint VPN and Network Connectivity Failure — Adapter, DNS, Tunnel, and Stack Triage

Windows 10/11 endpoints experience VPN connectivity failures or general network loss due to misconfigured split-tunneling, DNS resolution failures over the VPN tunnel, network adapter driver regressions, or network stack corruption. Symptoms range from VPN client refusing to connect, intermittent tunnel drops, and DNS resolution failures for internal hostnames, to complete adapter-level loss. Remediation follows a layered diagnostic approach: confirm adapter state, isolate routing vs DNS vs tunnel, review VPN client operational logs, then apply targeted fixes ranging from netsh stack reset to VPN profile re-provisioning via Intune or Group Policy.

Indicators

Likely causes

Diagnostic steps

  1. Run 'ipconfig /all' and review the output — confirm all adapter states (up/down), check DNS server assignments per adapter, verify default gateway presence, and note whether the VPN adapter appears and has a valid IP assignment.
    Determines whether the VPN adapter is present and has been correctly configured by the OS, distinguishing between a missing adapter (driver/profile issue), a connected-but-misconfigured adapter (split-tunnel or DNS issue), and a physical connectivity failure.
  2. Open Event Viewer (eventvwr.msc) and navigate to Applications and Services Logs > Microsoft > Windows > VPN-Client > Operational. Review the most recent entries for errors relating to IKE negotiation, certificate validation, or authentication rejection. Then check Applications and Services Logs > Microsoft > Windows > NetworkProfile > Operational for unexpected network profile changes.
    Identifies VPN-specific failure modes such as IKE phase failures, certificate errors, or authentication rejections, and separately identifies OS-level network classification changes that may block VPN connectivity.
  3. Test layer-by-layer connectivity: first run 'ping <VPN gateway IP>' to confirm basic IP reachability. If tunnel establishes, run 'ping <internal resource IP>' to test tunnel routing. Then run 'nslookup <internal hostname> <VPN DNS server IP>' to test DNS resolution specifically against the VPN-assigned DNS server, bypassing LAN DNS servers.
    Isolates the failure layer — routing failure (VPN gateway reachable but internal IPs unreachable indicates split-tunnel route missing), vs DNS failure (routing works but internal names fail to resolve indicates DNS is routing to LAN servers).
  4. Run 'netsh winsock show catalog' and review for unexpected or corrupt entries. Also run 'netsh int ip show config' to review TCP/IP configuration per adapter. If the output shows malformed entries or the command returns errors, proceed to network stack reset in the resolution path.
    Identifies network stack corruption that is not visible from adapter properties — Winsock or TCP/IP stack corruption can cause intermittent connectivity failures that persist through adapter disable/enable cycles.
  5. Check the Windows System event log for any Event ID 7036 (service state change) entries for the VPN-related services (e.g., RasMan, IkeExt, PolicyAgent) and confirm all are Running. Run 'sc query RasMan', 'sc query IkeExt', 'sc query PolicyAgent' to verify service states.
    A stopped or failed RasMan (Remote Access Connection Manager), IkeExt (IKE and AuthIP IPsec Keying Modules), or PolicyAgent (IPsec Policy Agent) service will prevent VPN tunnel establishment entirely, even if the client UI appears functional.

Resolution path

Prevention

Tools

References

vpnnetworkingwindows-endpointalways-on-vpndnsnetwork-adaptersplit-tunnelwinsocknetwork-stackrasmanikev2connectivityintunegroup-policydriver-regression