Always On VPN Device Tunnel and Certificate Revocation

Always On VPN Device Tunnel and Certificate RevocationRecently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all that’s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Updates for Windows Server

Microsoft has released fixes to support device tunnel certificate revocation for the following operating systems.

Windows Server 2019 – KB4505658 (build 17763.652)

Windows Server 2016 – KB4503294 (build 14393.3053)

Windows Server 2012/R2 – Will not be updated.

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

Always On VPN Device Tunnel and Certificate Revocation

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub

 

 

Leave a comment

8 Comments

  1. Simon

     /  June 24, 2019

    This sort of bug is unforgivable… not bothering to check if a certificate is revoked? RRAS has absolutely no place in a modern IT infrastructure, it’s absolutely shocking.

    Reply
    • It is surprising to learn this bug has apparently been around and unfixed for so long. It’s important to note also that Windows Server 2012 R2 is affected, but Microsoft won’t be releasing a fix for that version. You’ll have to upgrade or replace it with a proper security appliance, which I suspect would be your choice. 😉

      Reply
  2. John

     /  July 16, 2019

    Hi Richard
    I have a Server 2016 Device Channel VPN configured in a DMZ and working fine. Clients connect on a daily basis. I followed the steps above and set the CertAuthFlags registry flag to “4”. Afterwards, clients can connect but none of the routes are working in that client session.
    Reversing this and setting the CertAuthFlags back to “2” disable the function, fixes the routes again. Any idea what could be causing this?
    Regards John

    Reply
    • That’s quite unusual. Certainly not something I’ve seen in my testing. Also, I can’t imagine how changing CRL checking would impact routing? Odd. Are you able to reproduce this reliably? I ask because there is a known issue with RRAS that sounds similar. There’s currently a bug that will result in VPN connections being established but routing fails. The only workaround is to restart the server (restarting the service isn’t enough). I’m curious to know if perhaps these two issues aren’t being conflated here somehow.

      Reply
      • Fredrik

         /  November 11, 2019

        Hi Richard
        Do you have more information about this bug? I am currently experience the same problem. Routing fails and i have to restart server to get it working.

      • I don’t have any more information other than Microsoft is aware of the issue. No idea if they are working on a fix or not. :/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: