Always 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).
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.
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.
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.
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.
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
Martyn Jones
/ January 14, 2020Hi 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.
Richard M. Hicks
/ January 14, 2020The 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.
Antonio
/ November 27, 2023Hi Richard, is this still a valid statement in 2023?…
Richard M. Hicks
/ November 27, 2023It is, yes. Tell Leo I said ‘Hi’. 🙂
martynjones87
/ January 14, 2020Hi 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.
Patrick
/ March 20, 2020Hi 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?
Richard M. Hicks
/ March 20, 2020Absolutely. 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.
DiPersiaTech
/ April 7, 2020Thanks 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. . .
Richard M. Hicks
/ April 7, 2020Sorry, 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.
DiPersiaTech
/ April 8, 2020Cool, 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.
Richard M. Hicks
/ April 8, 2020Not sure what’s up there. :/
Stephen Zammit
/ April 15, 2020A quick question, does Always On VPN Device Tunnel with Azure VPN Gateway support ExpressRoute to on-premise resources?
Richard M. Hicks
/ April 15, 2020It does not, unfortunately. :/
James McIntosh
/ April 17, 2020If use Azure Virtual WAN it is indeed supported unless I am mistaken?
Richard M. Hicks
/ April 18, 2020That’s correct. You can access on-premises resources over ExpressRoute with Azure Virtual WAN point-to-site VPN connections.
Justin Nel
/ June 3, 2020Azure 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?
Richard M. Hicks
/ June 4, 2020It 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.
Yann
/ June 29, 2020Thanks 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.
Richard M. Hicks
/ June 29, 2020I’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.
Jarrett Boudreau
/ August 7, 2020Hey 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?
Richard M. Hicks
/ August 8, 2020Did you configure a device tunnel specifically? Did you do this using the native Intune method or with custom XML?
Steve Parankewich
/ January 14, 2021Are 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.
Steve Parankewich
/ January 14, 2021As 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.
Richard M. Hicks
/ January 18, 2021I 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.
Eshaq
/ March 25, 2024Hi,
I am trying to get this exact scenario working. I can get the tunnel and cert issued without any issues. However I get the error IKE credentials unacceptable when trying to connect. I checked my radius server and see no authentication attempt. Its as though, the maybe some cipher settings aren’t matching. I have tried different combinations and none of them work. Can you help please?
Richard M. Hicks
/ March 25, 2024If it were related to cipher settings, you would receive a different error message. This is almost certainly a certificate issue. What, specifically, I’m not sure. Have a look at this post and make sure everything checks out.
https://directaccess.richardhicks.com/2021/12/13/always-on-vpn-error-13801/
Daniele Scrivano
/ March 12, 2021Hi 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
Richard M. Hicks
/ March 12, 2021Technically 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.
Andrew
/ March 17, 2022Good 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/
Richard M. Hicks
/ March 17, 2022I’ve heard of it, but haven’t used it. Looks interesting, for sure.
Eshaq
/ March 27, 2024I’ve determined that the error “IKE Authentication Credentials are unacceptable” are indeed certificate related as you suggested as it is similar to an error I previously had with AOVPN to a Fortigate firewall. On that one I ended up having to issue a certificate from my on prem CA to the Fortigate that contained the FQDN of the VPN.
With Azure p2s I am not sure how i would issue a certificate to it. I believe the existing address of xxx.vpn.azure.com is using a DigiCert cert which is already trsuted on the client so that should work but I would like a way to issue my own just in case the DigiCert one is the cert that is causing issues. How would i go about doing that for Azure p2s?
Richard M. Hicks
/ March 27, 2024You cannot install your own certificates on the Azure VPN gateway. However, the certificate is issued by a publicly trusted CA, so there shouldn’t be any issues there. As long as you use the subject name provided by Azure it should work. Unfortunately, you can’t use a DNS CNAME or alias because the subject name wouldn’t match.
Eshaq
/ March 27, 2024Any idea what else i can check? I have setup p2s with radius. I’ve checked the secrets and it all matches. In fact when I switch to user certs, I see the radius request come through. The client has a very issued by the on prem CA. The NPS server performing radius is also an on prem domain controller.
Richard M. Hicks
/ March 27, 2024If you are using the device tunnel you must also upload your root CA certificate to the gateway. After that, make sure you have issued a device certificate with the Client Authentication EKU to your endpoint. Those, along with using the Azure-supplied VPN gateway FQDN should work just fine. Remember, you won’t see any NPS requests when using the device tunnel. If you are using the user tunnel then you must configure your RADIUS servers on the gateway. You will also need a user authentication certificate and a corresponding NPS policy that allows authentication with EAP/PEAP with certificates.
Eshaq
/ March 27, 2024I am using a device tunnel and want to use radius instead of azure certificates. I only get the option of uploading my root CA certificate when azure certificate option is selected. The reason I want to use radius for device authentication is so that device certs can be checked to see if they are revoked or not. I know there’s an option of manually inputting revoked certificates when azure certificate option is used but that doesn’t scale well. The device had the correct EKU too.
Richard M. Hicks
/ March 27, 2024The device tunnel does not support RADIUS authentication. Your only option is to use certificate authentication. If you want to use NPS you must deploy the user tunnel.
Eshaq
/ March 27, 2024Ah that clears that confusion. I couldn’t see it mentioned anywhere that device tunnel isn’t supported when using radius. What is the best way to achieve some level of either a CRL or a way of restricting devices with a device tunnel that maybe linked to a live directory of some sort? I see entra ID is an option but that looks like it might only be for user tunnels.
Richard M. Hicks
/ March 27, 2024When using the device tunnel you can only revoke certificates to prevent access. However, that’s not immediate because revocation lists are cached. Depending on how long the CRL is valid for you could end up waiting for an extended period of time before a device is unable to connect. When using RRAS (on-premises or in Azure) you can always place the device certificate in the untrusted publishers certificate store on the server. I don’t recall if Azure VPN gateway has an equivalent or not.