Windows · Windows Server · high · Networking & connectivity

VPN errors 809, 789 and 691 — the tunnel will not come up

Three different failures that look identical to the user: blocked on the way out, refused by the security association, or refused by the credentials.

What you see

"The network connection between your computer and the VPN server could not be established" (809), "the L2TP connection attempt failed because the security layer encountered a processing error" (789), or "the username or password is not valid on this domain" (691).

What is actually wrong

809 is almost always a NAT device between the client and server with no support for IPsec traversal. 789 is a certificate or pre-shared key mismatch, or the IKE service being stopped. 691 is authentication — wrong credentials, or an NPS network policy that does not permit the connection.

Codes and articles

809789691812IKEv2L2TPError 800

Fixes (3)

Allow IPsec through the NAT in front of the client

Elevated PowerShell on the client15 minutesmedium riskreversible

Error 809 or 800, and the same profile works from another network.

Check whether the server is even reachable on the right port. L2TP is UDP 500 and 4500, SSTP is TCP 443, IKEv2 is UDP 500 and 4500.
PowerShell
```
Test-NetConnection vpn.example.com -Port 443 -InformationLevel Detailed
```
Set the NAT traversal value so the client will build a tunnel through a NAT device.
PowerShell
```
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent' -Name AssumeUDPEncapsulationContextOnSendRule -PropertyType DWord -Value 2 -Force
```
By default Windows will not build an IPsec tunnel when both ends sit behind NAT. A value of 2 permits it, which is the standard fix for a home router in front of a client and a firewall in front of the server.
Restart the machine. The policy agent reads this at boot.
If it still fails on that network only, the router is dropping UDP 500 — switch the profile to SSTP over TCP 443, which passes through anything.
PowerShell
```
Set-VpnConnection -Name 'Work VPN' -TunnelType Sstp -Force
```

Confirm it workedThe tunnel connects and the assigned address appears.

PowerShell

Get-VpnConnection -Name 'Work VPN' | Format-List Name,ConnectionStatus,TunnelTypeipconfig | findstr /i "PPP"

If you need to undo itRemove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent' -Name AssumeUDPEncapsulationContextOnSendRule, then restart.

Fix the security association — key, certificate or service

Elevated PowerShell25 minutesmedium riskreversible

Error 789 or 812. The connection reaches the server and is refused at the IPsec layer.

Confirm the IKE services are running. 789 appears immediately if they are not.
PowerShell
```
Get-Service IKEEXT,PolicyAgent,RasMan | Format-Table Name,Status,StartType
```
For a pre-shared key profile, re-enter the key — a trailing space pasted from an email is a genuine and frequent cause.
PowerShell
```
Set-VpnConnection -Name 'Work VPN' -L2tpPsk 'TheKey' -Force
```
For IKEv2 with certificates, check the client actually trusts the server's issuing CA.
PowerShell
```
Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*YourCA*' | Format-List Subject,NotAfter,Thumbprint
```
An expired or missing root is the most common 789 on a rebuilt machine, and the error text never mentions certificates.

Read what the server thought. On the RRAS server, the Security log records the SA failure with a reason.

PowerShell

Get-WinEvent -LogName Security -MaxEvents 50 | Where-Object Id -in 4653,4654 | Format-Table TimeCreated,Id,Message -Wrap

Confirm it workedThe tunnel establishes and the main mode SA is listed.

PowerShell

Get-NetIPsecMainModeSA | Format-Table LocalEndpoint,RemoteEndpoint,CipherAlgorithm

If you need to undo itThe pre-shared key can be set back with the same command. No system state is changed.

Work out which side is refusing the credentials

Elevated PowerShell on the NPS or RRAS server25 minuteslow riskreversible

Error 691. The tunnel is fine; the account is being turned away.

Look for the rejection on the NPS server. It states the reason code and the policy that matched, which is the whole answer.
PowerShell
```
Get-WinEvent -LogName Security -MaxEvents 60 | Where-Object Id -in 6273,6274,6278 | Format-List TimeCreated,Message
```
Reason code 65 is "the connection was rejected by a policy", 16 is bad credentials, 48 is "no policy matched". Match the code to what to change.
Check the account is in the group the network policy requires, and that dial-in access is not set to Deny.
PowerShell
```
Get-ADUser jbloggs -Properties MemberOf,msNPAllowDialin | Format-List Name,msNPAllowDialin,MemberOf
```
msNPAllowDialin set to False overrides group membership and policy entirely, and nothing in the client error hints at it.
Confirm the authentication method the policy allows matches what the client offers — a client set to MS-CHAPv2 against a policy that only permits EAP fails as 691.

Confirm it workedEvent 6272 (access granted) appears on the NPS server for the account and the tunnel comes up.

If you need to undo itAny group or dial-in change can be reversed directly. Note the original value before changing it.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.