Windows VPN Not Connecting? Match the Code to the Event Log

It worked on Friday. On Monday the same Windows client answers with a dialog saying the connection attempt failed, and the sentence underneath is one you have already seen for a dozen unrelated problems. That dialog is the end of a chain, not the start of it. Windows hides the stage where the attempt actually died, and two small pieces of evidence name it: the numeric result code and one RasClient event from that same minute. Here is the order I use — pin the attempt, read the code, pull the event, then change exactly one layer.

The dialog text is the last step, not the cause

The sentence you read is chosen after the attempt has already unwound. "The connection was terminated by the remote computer before the connection was established" appears when a server hung up mid-negotiation, when IPsec failed before your username was ever sent, and when a policy refused the tunnel outright. Three different owners, one sentence. Treat the wording as a symptom class and let it steer nothing until the code agrees with it.

What you can still pin down is the attempt itself. Write down the connection name, the tunnel type stored in the profile — PPTP, L2TP/IPsec, SSTP or IKEv2 — the time to the second, and the code. If you are not sure which protocol actually ran, open %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk and read the entry instead of trusting memory; a profile reused for a new protocol keeps its old display name.

Read the number before you read the words

Codes fall into three stages, and the stage matters more than the exact phrasing: an authentication exchange that was reached and refused, a server that never answered, or a negotiation that collapsed after the link came up. 691 is the first kind — the credential check ran and failed, whether because of a bad password, a locked or expired account, or an authentication protocol the server will not accept. 812 is a refusal too, but with valid credentials: a policy on the remote access server decided against you. Microsoft keeps the canonical dial-up and VPN error code list, and it is worth reading your number there before you search the message text.

809 is the opposite class: nothing came back. That is a path problem — TCP 443 filtered for SSTP, GRE blocked for PPTP, UDP 500 and 4500 or ESP dropped for IPsec pass-through. A new password cannot fix it and neither can a fresh certificate. 720 means the link came up and PPP never finished negotiating, which points at a protocol mismatch or a server that could not assign an address. 789, or 13801 on IKEv2, is identity inside IPsec: a certificate whose subject does not match the name you dial, an untrusted chain, or a pre-shared key that differs between the two ends.

Pull the RasClient event for that same minute

In Event Viewer, Windows Logs > Application filtered on source RasClient is the first place to look. Microsoft's write-up of error 720 points at event 20227 in that log. The same provider emits other identifiers for other outcomes, so read the message and the embedded result code rather than treating the ID as the diagnosis; a generic dialog plus a 20227 carrying 720 is already a much narrower story.

From PowerShell, without clicking through the GUI:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

An empty result is informative. It usually means the dial never got far enough for RAS to log anything, or that the software that failed is not the native client at all — third-party clients keep their own diagnostics and often write nothing to the Application log. Check the vendor's log before you conclude that event logging is broken.

Build one timeline instead of a pile of events

Retry loops manufacture noise. Five automatic reconnects leave a cluster of events, and the temptation is to read them as one sequence with a single cause. They are five separate attempts, and only some of them reached a server. Take a two- or three-minute window, one connection name, and list each event with its own code before interpreting any of it.

Then ask where the attempt stopped. When the gateway or the authentication backend holds no record for that timestamp, the client never reached it, and you are looking at a reachability problem. When the backend shows a request and a rejection, the decision was made there, and the credential or policy class applies. Compare clocks before you compare times: clients report local time, many gateways log UTC, and an offset will make a perfectly correlated pair look unrelated.

For a repeatable capture, dial from the command line and let it print the result:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

The console shows the number the GUI hides behind friendly text, and running it twice tells you whether the code is stable or intermittent.

What each stage tells you to change

Naming the stage is only useful if it shrinks the change set to one layer:

• 691 — authentication: the EAP method the client offers against the one the server accepts, account state, password expiry, dial-in permission.
• 812 — server policy: the remote access policy or NPS rule that matches this user and this time window.
• 809 — reachability: firewall rules on the path, NAT and protocol pass-through, the port the chosen tunnel type needs.
• 720 — PPP negotiation: authentication protocol mismatch, address assignment, a server-side PPP setting.
• 789 / 13801 — IPsec identity: certificate subject against the name you dial, trust chain, pre-shared key.

Change one of those, retest the same profile, and write down the new code. A different code after a change is progress rather than contradiction: you moved the failure to a later stage, which is what fixing a multi-stage handshake looks like. What you should not do is alter the firewall, the certificate and the password in one sitting and then credit whichever one came last.

Share the evidence, not the environment

Event messages are richer than they look. They carry the connection name, the account, often the gateway's internal name or address, and sometimes a certificate thumbprint. Keep the original where it belongs, and build a separate redacted copy for anyone else; retyping the timeline from memory loses exactly the details that make it useful.

A handoff that gets worked needs five fields: the code, the stage it belongs to, the client and tunnel type, the timestamp with its timezone, and whether the gateway saw the request at all. Everything else is optional. With those five, the next person can tell a credential argument from a routing argument without repeating the investigation.

Before you close anything out, replay the attempt on the same profile and confirm where the code lands now. A success ends it; a different failure means the original stage is fixed and you have the next one in hand.