Always On VPN User Tunnel Error 812

Question

Hello,

We are deploying Always On VPN device and user tunnels using a powershell script run as SYSTEM via a scheduled startup task.
During testing, everything seemed to go really smoothly, but now we are deploying to live, we are seeing a number of issues we did not experience, and have so far been unable to resolve.

1. We have several users whose device tunnels and user tunnels have deployed to their machines. The device tunnels connect ok, but when attempting to connect the user tunnels, they get the error:
   "The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the administrator of the RAS server and notify them of this error."
   On the client machine, I see event IDs 2027, which states an error code of 812. The various causes for this error do not seem to apply.

Looking at our NPS server, for the times of these connection attempts, we see events 6273 in the security log with a reason code of 16
(Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.)

As we are using user certificate authentication, I don't understand why it would be complaining of a mismatch? Some users are working fine with the same deployment, so what would prevent only some users from not being able to connect (they are all in the same VPN Users security group used on both NPS and the CA where the VPN template sits).
Equally, if I log into another test machine as one of these affected users, I am able to connect without issue.

2. We have some users whose device and user tunnels have been deployed, but their device tunnels do not seem to be automatically connecting, even though their user ones are. Again, I cannot see any reason why their machines would not auto connect one but not the other?
   Does anyone have any thoughts on what may be ocurring here?

Many thanks
James

Answer 1

Hello James,

If you are prepared to share trace data then I could suggest something to trace, but it would probably require at least two "rounds" of tracing (the first round would probably just provide enough information to "tune" the trace parameters for a second round of targeted tracing). The trace data would probably be very large and not interpretable by most people. The trace would need to run on the RADIUS server; the trace would be created by "Windows Performance Recorder" (WPR).

The tracing might give some insight into the authentication decisions:

Gary

Answer 2

After a fantastic effort from @Gary Nebbett via e-mail, he was able to identify this issue to be the same as shown in this post.
Essentially an issue with some RSA algorithms on older TPM modules.

Testing the algorithm disabling mentioned in the post, we proved the user tunnel/user cert was ok after this, proving this is the issue.
We are now going to investigate storing this cert/key only in the software crypto provider rather than TPM, or try and find some way to do it for only TPM 1.2 devices, leaving TPM 2.0 devices to store the cert/key as they are currently.

Many thanks
James

Answer 3

Hello,

We have the exact same problem. We tought that the problems are related to the KB5014754 update which bring some certificate-based authentication changes. So far no solution found yet.

Are u using SSTP or IKEv2 for the user tunnel? If SSTP, is public or private certificate being used on RRAS servers?

Answer 4

Hello @James Edmonds

Thank you for your heads up!

Here are my 2 cents about this case scenario described previously...

-For instance, A mismatch error perhaps does not make any sense when using certificate but I am wondering if you check the service provider on the registry so , you can double-check if there an active TLS 1.0 or TLS 1.1 when it has to be TLS 2.0.

• Furthermore, Try to compare cipher suites from a working computer as well as a non-working one by running this on PowerShell terminal:

***PS C:\Windows\system32> *Get-TlsCipherSuite | Format-Table -Property CipherSuite, Name****

**CipherSuite Name

---

   4866 TLS_AES_256_GCM_SHA384                   
   4865 TLS_AES_128_GCM_SHA256                   
      0 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  
  49195 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  
  49200 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    
  49199 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    
    159 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384      
    158 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256      
      0 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  
  49187 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  
  49192 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    
  49191 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    
  49162 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA     
  49161 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA     
  49172 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA       
  49171 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA       
    157 TLS_RSA_WITH_AES_256_GCM_SHA384          
    156 TLS_RSA_WITH_AES_128_GCM_SHA256          
     61 TLS_RSA_WITH_AES_256_CBC_SHA256          
     60 TLS_RSA_WITH_AES_128_CBC_SHA256          
     53 TLS_RSA_WITH_AES_256_CBC_SHA             
     47 TLS_RSA_WITH_AES_128_CBC_SHA             
     10 TLS_RSA_WITH_3DES_EDE_CBC_SHA            
     59 TLS_RSA_WITH_NULL_SHA256                 
      2 TLS_RSA_WITH_NULL_SHA                                
    176 TLS_PSK_WITH_NULL_SHA256**                 

PS C:\Windows\system32>

-Have you checked if the Self-signed certificate or any other CA certificate used for this is on the Trusted Certificate Authority field on the PC's?

-Review the Certificate settings and compare it from a working machine by issuing this command below:

****PS C:\Windows\system32> Get-ChildItem -Path "Cert:\CurrentUser\My"
PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
Thumbprint Subject

---

400D2B5390C57B1959EE2D1A405587263F943525 CN=P2SChildCert
3B0AFD934104CB339854AE09B7EE7948CACB512C CN=P2SRootCert
B2D4ABB99794207268853A8B29B741C2C85926E2 CN=P2SChildCert
EF3DBCB8BD97AC7B4515B88A24DC1788E7BD39ED CN=P2SRootCert01
CA5A5CA55E45A7A093CDE6272E62B9998F658BBF CN=P2SRootCert
PS C:\Windows\system32>****

-Check the server name or FQDN/CN used for this set up...

If you have any chance to share the logs for this issue will be appreciate it : )

I hope this can give you more details on where to take a look.

Cheers,

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 5

Thanks a lot for that response!!

You really were doing a hard work on this issue and well done.

Now that there are more details about it and you isolated the issue.... If we go back to the error code is what you just mentioned before.

Error code: 812
Error description. Can't connect to Always On VPN. The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method the server used to verify your user name and password may not match the authentication method configured in your connection profile. Please contact the administrator of the RAS server and notify him or her of this error.
Possible causes:
The typical cause of this error is that the NPS has specified an authentication condition that the client cannot meet. For example, the NPS may specify the use of a certificate to secure the PEAP connection, but the client is attempting to use EAP-MSCHAPv2.
Event log 20276 is logged to the event viewer when the RRAS-based VPN server authentication protocol setting doesn't match that of the VPN client computer.
Possible solution. Ensure that your client configuration matches the conditions that are specified on the NPS server.

Cheers,