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

19 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. :/

  3. Dirk Rober

     /  January 2, 2020

    The link for “PowerShell Script to Configure RootCertificateNameToAccept on GitHub” does not seem to work anymore. Can you point me to a working location?

    Reply
  4. Is it possible to trust multiple root CA’s? I’m digging around but just in case you’ve come across this thought I’d post to help any others as well.

    Reply
    • No. If you need to support Always On VPN device tunnel with certificates issued by different PKIs, you’ll have to implement separate VPN servers for them. :/

      Reply
      • Ok, just to be 100% clear. The VPN is supporting:
        – IKEv2 device tunnel, with an internally-issued cert with the fully-qualified service name as the subject name.
        – SSTP user tunnel, with a publicly issued wildcard cert

        What we’re seeing in in the client CAPI log is the VPN server seems to be presenting the wildcard cert when the device is getting set up.

        Also, thanks for clarifying the issue around trusting multiple CA’s for IKE connections as that is also a requirement!

      • Thanks Gavin. Does the certificate issued to the VPN server for the IKEv2 device tunnel connection by your internal CA include both the Server Authentication and IP security IKE Intermediate EKUs? It must include both.

  5. Stefan Hattrell

     /  April 6, 2020

    Hey Richard! Love your work. I’ve pretty much used your blogs to stand up our Always-On VPN.

    I’m now setting up a second server for failover and have gotten to this point but I’m getting the following error: “Set-VpnAuthProtocol : The parameter is incorrect. invalidArgument: (PS_VpnAuthProtocol:root/Microsoft/…VpnAuthProtocol) [Set-VpnAuthProtocol], CimException”

    This worked beautifully on the first server and I’m scratching my head to understand how it’s any different!

    Reply
    • Has RRAS been installed? If so, has VPN been configured?

      Reply
      • Stefan Hattrell

         /  April 6, 2020

        Ah! Figured it out. I hadn’t actually enabled machine certificate authentication as a method…

  1. Always On VPN Device Tunnel Operation and Best Practices | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Device Tunnel Only Deployment Considerations | Richard M. Hicks Consulting, Inc.

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: