## Error message
```text
Error 812: The connection was prevented because of a policy configured on your RAS/VPN server. This is commonly caused by a mismatch between the NPS policy and the connection parameters.
```

## TL;DR
A network policy on the server said no, so the fix lives in NPS, not on the client. Check the NPS event log for which policy denied the connection, then fix the mismatched condition: authentication method, encryption requirement, group membership, or time restriction.

## Steps
1. Open the NPS event log on the server around the failure time.
   Expected: The log names the policy that denied access and the reason.
2. Compare the connection's parameters against that policy: auth method, encryption level, NAS type, and group conditions.
   Expected: You spot the mismatched condition.
3. Fix the client settings or the policy per your change process, whichever is wrong.
   Expected: The policy and client now agree.
4. Have the user reconnect.
   Expected: The connection establishes.

## When to use
- The exact error 812 appears after authentication succeeds
- Only some users or devices fail while others connect
- The failure started after an NPS policy change

## When not to use
- The error is 691 (credentials instead)
- No NPS server is involved (third-party VPN instead)
- The client cannot reach the server at all

## Why this happens
NPS evaluates policies in order after the user authenticates; the first matching policy with a deny, or no matching allow, ends the connection with 812. Mismatches between what the client offers (EAP type, encryption) and what the policy demands are the usual cause.

## Edge cases
- Policy order matters: a broad deny above a specific allow silently blocks users.
- NPS logs the client as the NAS IP, so correlate by timestamp when many users connect.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CI0zTKFzaScH3YxQNsGRLw