A VPN that will not connect stops a remote worker cold. The good news is that VPN clients are chatty about why they failed, if you know where the message is. The bad news is that the message is often generic and the real cause is somewhere else: a hotel firewall, an expired certificate, a password that changed yesterday.
This guide works for the built-in Windows VPN client and for the common vendor clients (Cisco AnyConnect and Secure Client, SonicWall NetExtender, FortiClient, GlobalProtect, WireGuard). The steps are the same even when the button looks different.
Start with the error, not the client
Get the exact error text or number before doing anything. For the Windows built-in client the numbers are well known. Error 809 means no response from the server, which is almost always a firewall or NAT blocking UDP 500 and 4500 for IKEv2 and L2TP. Error 691 is a bad username or password. Error 812 means the connection reached the server but the NPS network policy rejected it. Error 13801 is an IKE certificate problem, usually an expired or mismatched server certificate.
Vendor clients use their own wording, but the categories are the same: cannot reach the gateway, authentication failed, policy rejected, or connected but no traffic. Sorting the error into one of those four buckets tells you which of the next sections to read.
Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, ConnectionStatusIs it the internet or the tunnel?
Before blaming the VPN, prove the laptop has working internet. Open a browser to a site the user does not normally visit, because a cached page proves nothing. Hotel, airport and café networks often need a captive portal login first, and until that is done every VPN attempt fails instantly. Some guest networks block the VPN ports on purpose.
The fastest test is to switch to a phone hotspot and try again. If the VPN connects over the hotspot, the problem is the network the user was on, and the fix is a different network or a client that supports TCP 443 fallback. If it fails on the hotspot too, the problem is the laptop, the account or the server.
Credentials, MFA and certificates
Authentication failures are the largest group. Ask when the user last changed their password; a VPN client with a saved password keeps trying the old one and can lock the account. If MFA is in the path, a push notification that times out looks like a failed login. Ask the user to have the phone unlocked and in hand before clicking Connect.
On the server side, if authentication goes through NPS (RADIUS), the Security log on the NPS server records every attempt. Event ID 6272 is access granted, 6273 is access denied, and 6273 includes a reason code that says whether it was the password, the user's group, a policy condition or the authentication method. Certificate-based VPNs add one more failure mode: an expired or missing machine certificate on the laptop, or an expired server certificate. Check certlm.msc on the client and the gateway's certificate expiry date.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=6273} -MaxEvents 20 | Format-List TimeCreated, MessageClient-side fixes
If the network and account are fine, the client itself is next. Restart the vendor's service or, for the built-in client, the Remote Access Connection Manager service. Check Device Manager under Network adapters for WAN Miniport devices with a warning icon; a broken miniport driver stops every built-in VPN type and is fixed by uninstalling the device and scanning for hardware changes.
Vendor clients break when Windows updates change the network stack. Uninstall, reboot, and reinstall the current version from the vendor rather than the one in your old software share. Also check whether a second VPN client or a security product with its own network filter is installed; two filter drivers fighting over the adapter is a classic cause of connect-then-drop.
Connected, but nothing works
The tunnel is up and the user still cannot reach the file server. This is almost always DNS or routing. Run ipconfig /all and check that the VPN adapter got a DNS server from the office and a connection-specific DNS suffix. Run route print and confirm the office subnets point at the VPN adapter. With split tunnelling, a subnet that is not in the split list goes out to the internet and dies.
If names resolve and routes look right but large transfers stall, it is MTU. Set the VPN adapter MTU to 1400 or lower and test again. And if only one user has the problem on a shared gateway, compare their assigned group or profile with a working user before you spend an hour on their laptop. If you would rather hand this off, RackLedge runs and supports VPNs on SonicWall, MikroTik and Cisco gear for clients nationwide.
Frequently asked questions
The VPN works at home but not at a client's office. Why?
The client's firewall is probably blocking UDP 500 and 4500 or the vendor's ports. Ask their IT to allow them, or use a client and gateway configuration that falls back to TCP 443, which is almost never blocked.
Why does the VPN drop every few minutes?
Usually a Wi-Fi roam, a NAT timeout on the home router, or a power-saving setting on the network adapter. Disable Allow the computer to turn off this device on the adapter's Power Management tab and test on a wired connection to narrow it down.
Takeaway
Sort the failure into one of four buckets: cannot reach the gateway, authentication failed, policy rejected, or connected with no traffic. The error code and a hotspot test get you there in a couple of minutes. From that point the fix is usually a blocked port, a stale password, an expired certificate or a DNS setting, and each of those has a short, repeatable fix.