Windows VPN errors 691, 809 and 812 are useful starting points for troubleshooting a Windows built-in connection, including connections to an organization-managed gateway. They are not a complete diagnosis by themselves. First identify the client, profile, and permitted checks, then separate authentication, network reachability, and server policy before changing anything.

Key Takeaways:

Check that the error comes from Windows built-in VPN rather than an unrelated app.

Error 691 can involve credentials or an authentication method, not only a mistyped password.

Error 809 points to an unsuccessful network connection and does not alone prove a failed server.

Error 812 concerns server policy; lowering authentication requirements is not a user fix.

Which Windows connection produced the error?

Identify the connection. Record the built-in client, intended profile, and tunnel type.
Choose the code branch. Check authentication for 691, the network path for 809, or policy for 812.
Perform only permitted checks. Keep other conditions constant and preserve required controls.
Escalate persistent failure. Stop guessing and send redacted observations to the responsible administrator.

Open the connection's recorded details or your organization's instructions and identify the VPN provider, server address, and tunnel type. Do not publish the gateway address if it is internal or sensitive. A Windows built-in profile is different from a separate provider application, even if both are called VPN in everyday use.

Record the exact code and message rather than relying on the three digits from memory. The Microsoft error-code reference is the authoritative starting point for these Windows messages.［1］ App-specific messages with similar numbers need that app's documentation instead; applying RRAS advice to an unrelated client can create new problems without explaining the original one.

If your administrator supplied the profile, keep its intended settings. Ask which sign-in method and account format are required, whether you are authorized to use the connection, and whether your device is managed. Do not import another person's profile or guess a new protocol simply because one internet guide recommends it.

The VPN fundamentals guide explains the broader connection model. This article focuses on the Windows built-in and RRAS error system. It does not repeat adapter repair or app-launch instructions, and it does not treat a consumer VPN account as a replacement for an employer's gateway credentials.

How do Windows VPN errors compare?

Code	Initial direction	User-level check	Administrator investigation
691	Authentication denied or permitted authentication mismatch	Required account format and approved sign-in method	Authentication configuration, account permission, and relevant server events
809	Network connection to the server was not established	Ordinary internet, intended gateway, and another approved network	Gateway reachability, firewall or NAT path, and protocol-specific configuration
812	Connection prevented by server policy	Confirm the supplied profile and record the full message	Applicable access policy and client/server authentication requirements

The table selects an investigation branch, not a remedy to apply without evidence. Microsoft describes 809 in network-path troubleshooting and 812 in connection-policy context; the relevant tunnel type and deployment affect the details.［2］ A code should be paired with the profile and a time-correlated observation, especially when the organization operates several gateways.

VPN error 691: what can you safely check?

Confirm the account format given by your administrator. A username alone, a domain-qualified name, and a user principal name can be different inputs. Use the one specified for the profile. If the approved process uses a password, check whether it has expired or was recently changed through the organization's normal procedure; do not send it to support.

Confirm that the configured sign-in method matches the supplied instructions. Credentials can be correct while the negotiated authentication method is not permitted. Microsoft's RRAS guidance documents an MS-CHAPv2 authentication failure whose 691 message can mention a username/password problem or an unallowed authentication protocol. The investigation must preserve both possibilities.［3］

Retry once after correcting a known input issue. Repeated guessed passwords can trigger account lockout; Microsoft also discusses failed-authentication effects on the domain's bad-password counter in the documented RRAS case.［3］ If the same failure remains, stop guessing and provide the administrator with the time, full message, and profile identity through the approved channel.

Do not switch to a weaker authentication method to get past the error. Server policy, allowed account access, and authentication configuration belong to the administrator. On a managed machine, a profile mismatch is a reason to ask for a corrected approved profile, not to remove organizational restrictions yourself.

VPN error 809: how do you investigate the network path?

Check whether ordinary internet access works and whether any required network sign-in is complete. Verify the gateway name against the organization's instructions without substituting a similarly named endpoint. If the gateway address was entered manually, correct only a demonstrable typo; otherwise keep the supplied configuration unchanged.

Where permitted, compare the same device and profile on another approved network. Keep the account, gateway, and tunnel type constant so that the result isolates the underlying access path. Record both results near the same time. Success elsewhere suggests a path difference but does not prove intentional blocking by the first network.

For applicable IKEv2 deployments, Microsoft's Always On VPN troubleshooting discusses UDP 500 and 4500 and the role of firewalls or NAT.［2］ These are protocol-specific clues for an administrator, not instructions to open every port or edit a shared router. Different tunnel types have different requirements; a generic port list is not a universal 809 fix.

An administrator can inspect gateway service status, relevant network devices, firewall policy, and time-correlated logs. A user cannot infer server failure from the code alone. Congestion, an incorrect endpoint, path filtering, and deployment configuration can all require separate evidence. Do not disable your device firewall or corporate agent to turn an uncertain result into a passing test.

If the configured connection is L2TP, use the L2TP explanation to understand that protocol's role, then follow your administrator's instructions. Do not apply an IKEv2-specific troubleshooting step as though it established the behavior of every Windows VPN profile.

Error 812: why is this a policy escalation?

Read and preserve the full policy-related message. Microsoft associates this error with connection policy and possible mismatch between server requirements and the client's authentication configuration.［2］ The user should confirm that the intended approved profile is selected and that no manual changes have altered its sign-in method or tunnel type.

The administrator needs to examine the applicable access policy and authentication settings, including deployment-specific RRAS or NPS configuration where used. The fix can involve correcting a configuration mismatch, but it should maintain the organization's intended authentication and access requirements. The code does not authorize a user to choose the easiest available authentication option.

Do not remove policy conditions, disable required authentication, or reuse another person's access details. Those changes can undermine the gateway's control over who connects. If the profile is incorrect, request the corrected profile through the organization; if access is denied intentionally, ask the owner to review your authorization instead of treating it as a connectivity trick.

Who may change what, and when should retries stop?

Action	User responsibility	Administrator responsibility	Stop condition
Confirm account input	Use the supplied format without disclosing secrets	Verify account access and authentication records	Known correction fails or lockout is suspected
Compare another network	Use only a permitted network with the same profile	Investigate network policy and gateway path	Required controls would need disabling
Check the profile	Identify the intended supplied profile	Correct policy and protocol configuration	The proposed change is unsupported or weakens requirements
Collect diagnostics	Provide limited, redacted observations	Request deeper logs through an approved process	Collection would expose secrets or unrelated data

This division prevents a successful page load from becoming the only measure of a good fix. An organization connection has an access-control purpose as well as a networking purpose. A method that connects by bypassing policy can defeat the very requirement the gateway was intended to enforce.

For a personal task, a managed service such as AethoVPN belongs to a different connection choice than an organization's RRAS gateway; the Windows VPN selection guide helps distinguish that context. An employer's authentication and policy requirements for errors 691, 809, and 812 still require the authorized corporate connection and its administrator; a separate personal tunnel does not grant corporate access.

What information should you send to an administrator?

Provide the Windows version, whether the device is managed, the connection's nonsecret profile identifier, the tunnel type if known, and the exact message. Include the time and time zone, whether ordinary internet worked, and the result on another approved network if that comparison was allowed. State any known recent account or network change without disclosing credentials.

Redact passwords, one-time codes, certificates' private keys, account tokens, unnecessary addresses, and unrelated material in screenshots. Do not post internal gateway details in public forums. A complete diagnostic archive can contain more information than the administrator initially needs; use the approved collection process when detailed logs are requested.

Keep observations separate from conclusions. “The same profile worked on network B at this time” is useful evidence; “the hotel blocked the server” is a claim requiring more investigation. State when a comparison could not be performed rather than filling that gap with a guessed cause.

If the organization reports an outage or access restriction, follow its instructions and use only an approved alternative for urgent work. Preserve successfully collected evidence, stop repeated attempts, and wait for the owner to resolve the relevant account, policy, or infrastructure issue. Local checks cannot establish that a remote change has taken effect.

Summary

Identify the Windows client, profile, and tunnel type first.
Treat 691 as an authentication branch with more than one possible cause.
Treat 809 as a network-path branch, not proof of server failure.
Escalate 812 through the owner of access policy.
Share redacted evidence and preserve mandatory security controls.

FAQ

Does error 691 always mean a wrong password?

No. It can involve credential input or an authentication method the server does not permit. Check the approved format and escalate persistent failures rather than guess passwords.

Should I keep retrying 691 with different passwords?

No. Repeated failed authentication can contribute to lockout. Correct a known input issue once, then ask the administrator to investigate if the same failure remains.

Does error 809 prove the VPN server is down?

No. It indicates that the network connection was not established. The endpoint, access path, firewall or NAT policy, and deployment require separate investigation.

Should I open UDP 500 and 4500 myself?

Those ports are relevant to applicable IKEv2 deployments, not every VPN. Shared network and firewall changes belong to authorized administrators; preserve your organization's required controls.

Can I fix 812 by lowering authentication requirements?

Do not weaken authentication or bypass access policy. Confirm the supplied profile and ask the administrator to correct any mismatch while preserving the intended requirements.

Does this guide apply to every VPN application?

It targets Windows built-in and RRAS-style connection errors. A separate application's similar code needs its own documentation; matching digits do not establish matching causes.

What should I include in a support request?

Send the exact error, time with time zone, profile and tunnel context, and permitted comparison results. Redact secrets and use the organization's approved process for deeper logs.

Sources

Sources checked 5 October 2026.

Related Articles:

Windows VPN Errors 691, 809 and 812: What They Mean