Organizations everywhere are rapidly adopting Microsoft Azure public cloud infrastructure to extend or replace their existing datacenter. As traditional on-premises workloads are migrated to the cloud, customers are looking for options to host VPN services there as well.
Windows Server
Windows Server with the Routing and Remote Access Service (RRAS) installed is a popular choice for on-premises Always On VPN deployments. Intuitively it would make sense to deploy Windows Server and RRAS in Azure as well. However, at the time of this writing, RRAS is not a supported workload on Windows Server in Azure.
Although explicitly unsupported, it is possible to deploy Windows Server and RRAS in Azure for Always On VPN. In my experience it works well and can be an option for organizations willing to forgo formal support by Microsoft.
Azure Gateway
Options for supporting Always On VPN connections using native Azure VPN infrastructure depend on the type of VPN gateway chosen.
VPN Gateway
The Azure VPN Gateway can be configured to support client-based (point-to-site) VPN. With some additional configuration it can be used to support Windows 10 Always On VPN deployments. Azure VPN gateway supports either IKEv2 or SSTP VPN protocols for client connections. The Azure VPN gateway has some limitations though. Consider the following:
- A route-based VPN gateway is required
- A maximum of 1000 concurrent IKEv2 connections are supported when using the VpnGw3 or VpnGw3AZ SKUs (2000 supported in active/active mode)
- A maximum of 128 concurrent SSTP connections are supported on all gateway SKUs (256 supported in active/active mode)
- The gateway can be configured to support either device or user connections, not both.
Virtual WAN
Azure Virtual WAN is the future of remote connectivity for Azure. It includes support for client-based VPN (currently in public preview at the time of this writing), but only supports IKEv2 and OpenVPN VPN protocols for client connections. SSTP is not supported at all. Further, OpenVPN is not supported for Windows 10 Always On VPN, leaving IKEv2 as the only option, which poses some potential operational challenges. Virtual WAN offer much better scalability though, supporting up to 10,000 concurrent client-based VPN connections. Like the Azure VPN gateway, Azure Virtual WAN can be configured to support either device or user connections, not both.
Virtual Appliance
The most supportable option for hosting VPN services in Azure for Windows 10 Always On VPN is to deploy a third-party Network Virtual Appliance (NVA). They are available from a variety of vendors including Cisco, Check Point, Palo Alto Networks, Fortinet, and many others. To support Windows 10 Always On VPN, the NVA vendor must either support IKEv2 for client-based VPN connections or have a Universal Windows Platform (UWP) VPN plug-in client available from the Microsoft store. Click here to learn more about Always On VPN and third-party VPN devices.
Note: Be careful when choosing an NVA as some vendors support IKEv2 only for site-to-site VPN, but not client-based VPN!
Hybrid Deployments
For organizations with hybrid cloud deployments (infrastructure hosted on-premises and in Azure), there are several options for choosing the best location to deploy VPN services. In general, it is recommended that client VPN connections be established nearest the resources accessed by remote clients. However, having VPN servers hosted both on-premises and in Azure is fully supported. In this scenario Azure Traffic Manager can be configured to intelligently route VPN connections for remote clients.
NetMotion Mobility
The NetMotion Mobility purpose-built enterprise VPN is a popular replacement for Microsoft DirectAccess. It is also an excellent alternative for enterprise organizations considering a migration to Always On VPN. It is a software-based solution that can be deployed on Windows Server and is fully supported running in Microsoft Azure. It offers many advanced features and capabilities not included in other remote access solutions.
Summary
Administrators have many options for deploying VPN servers in Azure to support Windows 10 Always On VPN. Windows Server and RRAS is the simplest and most cost-effective option, but it is not formally supported by Microsoft. Azure VPN gateway is an interesting alternative but lacks enough capacity for larger deployments. Azure Virtual WAN is another option but has limited protocol support. Deploying an NVA is a good choice, and NetMotion Mobility is an excellent alternative to both DirectAccess and Always On VPN that is software-based and fully supported in Azure.
Additional Information
Windows 10 Always On VPN with Azure Gateway
Windows 10 Always On VPN and Third-Party VPN Devices
Windows 10 Always On VPN and Windows Server Routing and Remote Access Service (RRAS)
Windows 10 Always On VPN IKEv2 Features and Limitations
Windows 10 Always On VPN Multisite with Azure Traffic Manager
Heath
/ June 28, 2019I’m trying to get Always On VPN to work with the Azure virtual gateway. SSTP works great but IKEv2 returns the error “Can’t connect to Error processing ID payload”. Rasclient logs event 20227 ” dialed a connection named which has failed. The error code returned on failure is 13834.” Our RADIUS server logs a successful grant for the session but something is failing at the end for IKEv2 and I haven’t be able to find any resolutions for it.
Richard M. Hicks
/ June 28, 2019That’s unusual. Are you using the hostname provided by Azure or your own hostname to connect via IKEv2?
freebaser
/ June 28, 2019The azure hostname ‘azuregateway-{string}.vpn.azure.com’
Richard M. Hicks
/ June 28, 2019Ok, that’s correct. Not sure what’s up to be honest. Might want to enable IPsec auditing or take a network trace and see what IKE is complaining about on the wire.
tslsLuke smith
/ October 4, 2019I’m getting the same error with the Azure VPN Point-to-Site using IKEv2, did you get your issue resolved?
tsls
/ October 4, 2019I’m also getting the same error when using Azure Point-to-Site VPN IKEv2 running on Windows 1903 – Did you get this issue resolved? SSTP works fine but need IKEv2 for Always On
Heath
/ October 8, 2019Do you also have Site-to-Site configured on the same Gateway? I think there might be an issue with having both a S2S and P2S on the same Gateway when using IKEv2.
Richard M. Hicks
/ October 10, 2019Yes. In my testing I had the Azure VPN gateway configured to perform both site-to-site and point-to-site concurrently. No issues to report.
tsls
/ October 10, 2019It is running both S2S and P2S using VpnGw2. Richard are you running IKEv2 on your S2S
Luke.
Richard M. Hicks
/ October 10, 2019I am, yes. Works flawlessly for me.
tsls
/ November 5, 2019So turns out we are publishing too many routes. we have 54 routes and the Windows VPN Client when using IKE only supports 25. We are going to summarize these and hopefully all will be good – will report back once working.
Richard M. Hicks
/ November 10, 2019That’s good to know, thanks for sharing! I had no idea there was a hard limit, but I’ve never come anywhere near close to using that many routes myself. Let me know how it goes!
Don
/ February 6, 2020So yeah, the “Error processing ID payload” thing again. IKEV2 P2S tunnel issue, SSTP works fine but the 128 limit is too restrictive plus we need IKEV2 for Always On VPN.
The 25 routes thing is real. My VPN gateway has connections back to 2 on-prem sites each with a ton of routes for the many subnets at these locations. Doing some route consolidation of the subnet routes into more “supernet” routes can help.
Appears to still be an issue in Win10 1903 and (just tested) 1909.
https://www.tsls.co.uk/index.php/2019/11/07/azure-gateway-point-site-windows-vpn-client-error-processing-id-payload/
non092
/ March 3, 2020As anyone tested using Azure Virtual WAN to setup Always On VPN ?
Does it allow to have both a user and device tunnel by creating 2 separate P2S configuration in virtual WAN ?
We are currently planning a migration from DA to Always On VPN and thinking that using virtual WAN from the start would be a better choice than Azure gateway using device tunnels only.
Richard M. Hicks
/ March 5, 2020I’ve not used Azure Virtual WAN myself, so I can’t really comment. Perhaps someone else has experience to share with us?
Bryan Hall
/ September 12, 2023Resurrecting an old thread. We’re PoCing vWAN with user and device tunnels right now with Azure vWAN using two hubs: One to support user tunnels with IKEv2 + RADIUS, and the other for device tunnels with IKEv2 and machine certs. Both tunnels are getting established correctly. We’re not far enough along the PoC to experience any issues yet, but we expect some. IKEv2 is a big limitation, but seeing Martijn’s reply is interesting; perhaps OpenVPN can be used. Another thing we’re wondering about is how if Azure vWAN’s cert revocation check is limited to only the explicitly listed cert thumbprints on the P2S gateway, or if that list is in addition to CDP lookups. If each individual revoked cert needs to be defined in the gateway, that has an impact on management
Richard M. Hicks
/ September 14, 2023I’m not sure how revocation works in that scenario, honestly. It may not perform revocation checks using the CDP location. Hopefully it does, but that’s something you’ll have to test.
Let me know what you find out!
John
/ December 23, 2020Hi Richard, I’m trying to setup RRAS SSTP with the Azure Application Gateway. Currently I’m getting “The network connection was aborted by the local system”. Do you need to add the SRA_ URL anywhere in the AAG? I don’t suppose you have any plans on writing a guide for this? Many Thanks
Richard M. Hicks
/ December 28, 2020I’ve not configured SSTP VPN with Azure Application Gateway. However, I’m not sure it is really needed. You don’t need it to perform authentication and you don’t want to offload TLS processing either. Best to just assign a public IP address to the RRAS instance and set a network security group to allow inbound TCP 443 only.
John
/ December 29, 2020Thanks Richard, I’m actually able to get the RRAS up and running just fine directly as you suggest, but was hoping for some load balancing options from the AAG and assumed that as I’m just using SSTP for the protocol that it would be fine. As soon as I put an AAG in front, the connection just stops dead with “The network connection was aborted by the local system”. i get this behaviour if my RRAS servers are in the backend pool but also if there
is nothing in the backend pool (!) so I’m assuming an issue in the AAG somewhere..
Richard M. Hicks
/ January 6, 2021Instead of using AAG I’d suggest using the Azure Load Balancer instead. I know I’ve tested AAG in the past and it worked, it has many features/capabilities that aren’t really required, making the Azure load balancer a better fit.
https://directaccess.richardhicks.com/2019/10/28/always-on-vpn-load-balancing-for-rras-in-azure/
John
/ January 8, 2021Thanks Richard, in the end I gave up on the AAG and opted for the Kemp ADC Azure Appliance. Got everything up and running in under 30 minutes from deployment to configuration, with the help of your guide of course!
🙂
Richard M. Hicks
/ January 9, 2021Good choice. 🙂
Martijn Verheijen
/ March 8, 2022Hello Richard,
At first I want to thank you for the wealth of information you provide trough this website and your excellent book. A collegue of mine implemented a point to site config with Azure Gateway based on OpenVPN and Azure AD Authentication. He Used Oma-Uri in Endpoint Manager to configure the clients. This results in a simple to setup and maintain P2S VPN implementation with as little moving parts as possible (no NPS server and no PKI). Also the maximum number of concurrent sessions is significantly higher than that of SSTP. The key concern that I have when I saw this is that the only officially supported protocols for Always On VPN is IkeV2 and SSTP. My collegae states that the user experience is exactly the same as with IkeV2 and SSTP with the exception that the user needs to accept an MFA challenge the very first time he/she connects to the VPN after that the connection is always automatically build up as one would expect with Always On VPN. Is this even an supported setup, and if so are there security considerations why one would not go down this route? On paper this looks like a need and simple solution.. Thanks for thinking with me on this one.. Kind regards, Martijn, The Netherlands.
Richard M. Hicks
/ March 8, 2022Hi Martijn! Thanks for the kind words. Much appreciated! I see no issue using Azure VPN gateway and OpenVPN for Always On VPN. While not common (at least based on my experience) it is a workable solution. To clarify though, the officially supported protocols for Always On VPN are IKEv2, SSTP, L2TP, and PPTP. However, this applies only to client configurations using the native profile, not the plug-in profile. With the plug-in profile, you can use any VPN protocol supported by the vendor, in this case, OpenVPN. 🙂
Martijn Verheijen
/ March 8, 2022Hello Richard, Thank you for your quick response and nice to know that this is a feasible option. Just to be curious, what is your go to solution at this moment when you need to implement Always On VPN with Azure as concentrator? Azure Gateway, SSTP, A VM with NPS and a VM’s for a PKI? It feels like a lot of IaaS for something that Ideally would be a SaaS solution. Just trying to pick you brain on this one to get your general point of view 😉
Richard M. Hicks
/ March 8, 2022It really depends on customer requirements. Most deployments still use Active Directory accounts so NPS on-premises or in Azure are still required. RRAS in Azure is quite popular despite the lack of formal support because it is easy to deploy and scales effectively. Azure VPN gateway works well for smaller deployments where SSTP is desired, but Azure Virtual WAN is best for large-scale deployments. You just have to accept the limitations of IKEv2 in that scenario.
Martijn Verheijen
/ March 8, 2022Hello Richard, I understand. Thanks again for the info and greetings from the Netherlands.. Martijn.
Ross
/ March 10, 2023Hello we are also having this new issue with Error Processing ID Payload. We are also in azuregateway….. vpn.azure.com. Only seems to be around 10 clients out of 2000. We might be linking this with a failed windows updates but we not certain. Very odd. Regards Ross