Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN Device Tunnel with Azure VPN GatewayAlways On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

Always On VPN Device Tunnel with Azure VPN Gateway

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Always On VPN Device Tunnel with Azure VPN Gateway

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

Always On VPN Device Tunnel with Azure VPN Gateway

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. Copy the FQDN in the VpnServer element in VpnSettings.xml. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Always On VPN Device Tunnel with Azure VPN Gateway

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Always On VPN Device Tunnel with Azure VPN Gateway

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

Leave a comment

30 Comments

  1. Martyn Jones

     /  January 14, 2020

    Hi Richard,

    In the limitations section, you mention that an Azure VPN Gateway cannot support both user and device tunnels at the same time.

    Is this a single client machine connecting a user and device tunnel at the same time is unsupported?

    Or is the Gateway itself, unable to have both types of connection configured through it?

    I can’t find any mention of this in the Microsoft documentation, so I’m just looking to clarify before going any further with planning for an Always On VPN rollout.

    Thanks very much,

    Martyn.

    Reply
    • The Azure VPN gateway can only be configured to support user tunnels or device tunnels, not both. This is because device tunnels are authenticated by the VPN gateway by their device certificate, but user tunnels are authenticated by NPS. The gateway configuration supports only one authentication method, either certificate or RADIUS (NPS). With that, you have to choose one or the other. No option to do both at the same time unfortunately.

      Reply
  2. martynjones87

     /  January 14, 2020

    Hi Richard,

    In the limitations section, you mention that an Azure VPN Gateway cannot support both user and device tunnels at the same time.

    Is this a single client machine connecting a user and device tunnel at the same time is unsupported?

    Or is the Gateway itself, unable to have both types of connection configured through it?

    I can’t find any mention of this in the Microsoft documentation, so I’m just looking to clarify before going any further with planning for an Always On VPN rollout.

    Thanks very much,

    Martyn.

    Reply
  3. Patrick

     /  March 20, 2020

    Hi Richard, thank you for this. I am able to connect using the downloaded vpn profile but cannot ping any resources on any other network. Do you know if I need to create a routing table so my vpn clients can ping to other vnets and on premise devices?

    Reply
    • Absolutely. Not sure how that’s done with the downloaded VPN client, but if you are using Always On VPN you add those routes to your ProfileXML. You can also add them to the VPN connection using the Add-VpnConnectionRoute PowerShell command.

      Reply
  4. DiPersiaTech

     /  April 7, 2020

    Thanks for this info, Richard. Two items – I’m trying to get the current IPSec policy out of Azure (Just for documentation purposes in case I mess this up and have to set something back!) Can’t seem to figure out how to get this for point to site VPNs.

    Second, when I DO try to implement this and create a new IPSec policy using your powershell above – I get the following error: “New-AzVpnClientIpsecParameter: Cannot validate argument on parameter ‘PfsGroup’. The argument “PFS2048” does not belong to the set “PFS24,PFSMM,ECP384,ECP256,PFS14,PFS2,None” specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.”

    Odd. . .

    Reply
    • Sorry, that was a mistake. I’ve corrected the issue now. The correct parameter for the point-to-site connection is PFS14. Confusingly you use PFS2048 to configure the same setting on the site-to-site connection. :/

      Also, you should be able to use Get-AzVpnClientIpsecParameter to view current settings.

      Reply
      • DiPersiaTech

         /  April 8, 2020

        Cool, thanks for the update. Yes – tried Get-AzVpnClientIpsecParameter, but seems to be returning incorrect info. Like IpsecEncryption none, everything set for MD5, DES and no DH or PFS group.

      • Not sure what’s up there. :/

  5. Stephen Zammit

     /  April 15, 2020

    A quick question, does Always On VPN Device Tunnel with Azure VPN Gateway support ExpressRoute to on-premise resources?

    Reply
  6. Justin Nel

     /  June 3, 2020

    Azure Virtual WAN looks interesting! Do you know if the AVW P2S VPN can be used without the SDWAN element, where I would still be able to access on-premise resources through an existing Expressroute? Has Anyone got experience using Azure Virtual WAN P2S VPN with AOVPN?

    Reply
    • It does look interesting, but I’ve done no testing with this so far. However, I’ve been told that if you establish a point-to-site connection using Azure Virtual WAN that you can access on-premises resoruces via ExpressRoute.

      Reply
  7. Thanks a lot for all these posts, they’re really helpful. I’m facing an issue for 2 days now and despite all my readings and tests, I wasn’t able to find a solution.
    I’ve an Azure AD DS managed domain, peered with an Azure VNet on which I’ve added an Azure Gateway for P2S VPN connections. I’ve followed the tutos and can connect using a P2S connection from local machine and access my Azure resources.
    However, I would like to add my local machine to the AAD DS domain but for this I wanted to create a VPN Device tunnel so that I can login with my Azure AD accounts: I can’t (error 13806: IKE failed to find valid machine certificates). I’ve run psexec, installed my certificates in LocalMachine store. I’m afraid the issue is because they are self-signed (I followed the tuto). Do you think it’s possible to create a Device tunnel with self-signed certificates? My concern is that it’s not possible to use a CA with AAD DS.

    Reply
    • I’ve not tested this using self-signed certificates as we typically like to avoid their use anyway. My guess is that it won’t work because there’s no issuing certification authority to tell the Azure VPN gateway to trust.

      Reply
  8. Hey Richard,

    I have Always-On VPN using Azure VPN Gateway configured and deployed via intune.

    After doing a bit of testing, I’ve determined the VPN is NOT connecting before user login.

    The VPN IS available for all users, and will connect as soon as the user logs in – but I’ve been able to confirm with a scheduled task ping output that the VPN is down until the user logs in.

    My test machine is a Win10 Ent VM in Azure that is domain joined.
    We use SCEPMan to handle device certificates and I have this working with our tenant and certificates are delivered via Intune. All of this is working great.

    Testing connectivity BEFORE user login is my last hurdle. Any pointers to check?

    Reply
  9. Steve Parankewich

     /  January 14, 2021

    Are you familiar with Windows AutoPilot deployments? We would like to leverage an always on VPN connection to Azure VPN where the workstation would then have line of site to a domain controller. The machine would not have the workstation certificate delivered to it before that initial login attempt though. Not sure if anyone has been able to get this working.

    Reply
    • Steve Parankewich

       /  January 14, 2021

      As well, it doesn’t have to be Always On. I believe as long as you can auth to the VPN before the user login so manually clicking the network icon would work as well.

      Reply
    • I am. I’ve been doing some testing with Always On VPN and Autopilot recently. You can deploy the certificate and the device tunnel profile to an Autopilot device to support hybrid Azure AD join. The certificate and device tunnel is in place to support the initial user logon without cached credentials. It works well, but in my experience, it takes a long time. Not only does it seem to take quite a bit of time to actually provision the device over Autopilot, but (for me) the device tunnel wasn’t provisioned immediately after provisioning. I had to wait a period of time before the device tunnel was ready and I could log in. If you are patient it should work though.

      Reply
  10. Daniele Scrivano

     /  March 12, 2021

    Hi Richard, thanks for your article. I have a question that you answer yet, but I need some clarifications about limitations. You wrote: device tunnel and user tunnel can’t activate at the same time. But the Azure docs report that they can. Maybe should I use two different Azure VPN gateway? Or can I use one VPN gateway? Can I use Azure VPN gateway to integrate Azure AD with conditional access?

    Thanks a lot for your support,
    Red

    Reply
    • Technically speaking the client can establish a device tunnel and user tunnel at the same time. However, the issue here is the Azure VPN gateway can be configured to support *either* a device tunnel or user tunnel connection, not both at the same time. With that, you’d have to deploy two separate Azure VPN gateways. Unfortunately, you can only have one Azure VPN gateway per VNet, so you’d have to deploy the additional VPN gateway in another VNet. You can go that route if you choose, or you can simply deploy RRAS which can do both.

      Reply
  11. Andrew

     /  March 17, 2022

    Good afternoon, I don’t know if you have seen SCEPman, but it allows for a simple CA infrastructure tied to Azure AD to issue and auth user/device certificates and is perfect for Azure Virtual Network Gateway with Always on VPN configuration.

    https://docs.scepman.com/

    Reply
  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.
  3. Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune | Richard M. Hicks Consulting, Inc.
  4. Always On VPN Device Tunnel Status Indicator | Richard M. Hicks Consulting, Inc.

Leave a Reply

%d bloggers like this: