A Windows Network Reset Deletes More Than the VPN Fault
A reset clears adapters, routes and WFP filters, not just the failing tunnel. Save the profile, the certificate list and the evidence, then test in layers.
The advice arrives within ten minutes of every Windows VPN complaint: run the network reset, it fixes everything. It does not, and it is not narrow. That button clears adapters, rebinds protocols, removes static addresses and default routes, drops firewall and filter entries, and forgets Wi-Fi profiles for good measure. On a machine with a working but misconfigured tunnel, it converts one diagnosable fault into an undocumented rebuild. Save five things first, and you keep the option of undoing it.
The reset is not scoped to the VPN profile
A VPN connection is one object among many that share the networking stack. Removing and re-adding an adapter changes the interface index, and anything that referenced that index, from a route to a firewall rule to a third-party filter driver, now refers to something that no longer exists.
Virtualisation makes this worse. Hyper-V switches, VMware bridges, container networks and VPN clients with their own virtual adapters all live in the same space. A reset that reinstalls the base stack can leave those components half-present, and the resulting machine reports working hardware with no working path.
None of that is an argument against ever resetting. It is an argument against resetting first, on a machine you have not documented, when the actual fault might be one route entry or one stale filter. A reset is a wide tool with a narrow success rate, and using it as the opening move guarantees you will never learn which of the two it was.
Save the evidence before you save the settings
The failure itself is data. Note the exact error code, the time, which profile was selected, and whether the gateway logged an attempt at all. A code that says the tunnel never got an answer and a code that says authentication failed point at completely different repairs. After a reset you may not be able to reproduce either one. Treat the broken state as an asset you are about to spend.
Capture the state while it is still broken, into a folder outside the machine's temporary directories:
mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xmlThe last command is the one people leave out, and it is often the one that explains the fault. Leftover filters from a removed client survive as persistent policy, and the exported XML is the only local record of them. Read it before a reset erases the thing you were trying to identify.
Save the configuration that will not come back
Some settings are recreated automatically. Static addresses, custom routes, DNS suffixes, proxy exceptions and firewall rules are not. Neither are the profiles themselves, which live in a phonebook file that the reset does not restore for you.
| What to save | Where it lives | Why the reset loses it |
|---|---|---|
| VPN profiles | rasphone.pbk in ProgramData or the user profile | Profiles are not part of the adapter state |
| Static IP and DNS | Adapter configuration | Adapters are removed and recreated |
| Persistent filters | WFP policy store | Filter state is cleared with the stack |
| Third-party bindings | Adapter binding list | Components must be reinstalled manually |
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfterThe certificate listing matters more than it looks. Client certificates are not destroyed by a network reset, but the list tells you which ones the profile depended on and whether any expire in the near future. Discovering an expired certificate after a rebuild wastes the rebuild.
Write the recovery path down before you start
If the machine is remote and the VPN is your only way in, the reset can end your session and there may be no way back without someone on site. Confirm that out-of-band access exists, or that a person is available, before running anything that touches adapters.
Store the installers and the connection details somewhere the machine can still reach afterwards. A client that has to be reinstalled from a vendor portal reached over the tunnel is a circular dependency, and it is the single most common way this procedure becomes an outage.
Then record what you are doing and why, including the exact commands. The next person needs to know whether the reset was an experiment or a decision, and "we tried everything" is not a record.
Test in layers after the reset
Restoring too much at once makes the result unreadable. Work from the bottom: adapter and address, then name resolution, then the tunnel's identity stage, then the application. Each layer has a command that answers its own question:
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443If the adapter layer is healthy and resolution is not, stop and fix resolution. Reinstalling the VPN client at that point adds a variable and removes a clue. Only restore the settings you can explain, one at a time, checking the same layer after each.
Microsoft's own troubleshooting guidance for error 720, for example, distinguishes binding problems from address-allocation problems rather than prescribing a blanket reset, which is the right instinct for every code in this family. Read what the code claims before reaching for the widest tool available.