I have been tasked with deploying Always On VPN for my company’s environment.
We recently moved all of our servers from an on-prem datacenter into Azure, and the company has split into 2 separate entities. The users who are going to remain have had their M365 licenses upgraded to E5 from E3, and it was decided that the cybersecurity packages with the license, including Always On VPN would be the way to go and dump the existing services they are paying for.
I have followed the tutorial to set up the infrastructure from here, and configured the Certificate Authority templates from here, and am on the phase of testing the connection for a test client box that has been joined to the domain and added to the appropriate OU found here.
When I attempt to connect the client box to the Always On VPN profile, I am greeted with the error: “The remote connection was not made because the name of the remote access server did not resolve.”
If I “trick” the hosts file by adding the line for the external IP of the VPN server with the hostname for the VPN server, I get a different error message:
“IKE authentication credentials are unacceptable.”
I have reached out to both Azure and Microsoft 365 support and have been bounced back and forth 8 times as of the writing of this post without resolution. The 365 team blames Azure, and Azure team blames 365. I am spinning my wheels with this task, and would be ever so grateful for assistance by someone who has more experience with this.
First Remote Access is not supported in Azure, as is said on your first link.
You should probably look at using Azure VPN Gateway for this, it supports both device and user always on vpn.
Second support for Always on VPN is included in M365 E3.
The first error is related to DNS, you need a public dns record that points to your server. The second is either a configuration issue or related to Remote Access being unsupported
Agreed. That Richard Hicks guy is cool. Your initial problem sounds like a DNS issue. However, if you connect via IP address I would expect the IKE authentication error because it’s likely your IP address isn’t the subject name on the IKE certificate.
I expect when you get the DNS issue resolved things will start working after that.
Also, you have all of your servers in Azure which is like the dream scenario to just use the Azure VPN Gateway to conect to your servers via VPN in Azure already if your servers were converted to Azure VMs.
Azure VPN Client (using XML config file) → Azure VPN Gateway —> Your servers
Why I wouldn’t want to use Always on VPN in Azure:
You will need to setup servers to handle the VPN connections already covered by the VPN Gateway as a service with no maintenance overhead on your part other than setting up the service itself.
Compute (server instances) are the most expensive things to provision in cloud…
If you have licensing problems and this is friendly towards your environment, deploying system wide VPN with OpenVPN is as easy as placing a properly generated file in a folder
I recently figured out a slick way of doing this with WireGuard. Works really well and has some fantastic self-healing functions that I really like. Would be happy to review with you if you’re interested.
I’d say the “Always on VPN” term is something of the past - either SASE the solution (Microsoft now has Entra ID Global Connect Private/Internet Access, at least in preview) or use something like Bastion or App Proxy if web/RDP/SSH.
They don’t want to deploy Always on VPN at my place of work, but we’re also unable to deploy programs to user’s computers. It also takes 10 minutes to remote in.
I keep hearing AOVPN is not supported in Azure but cannot find anything specific on this other than the odd references in u/richardmhicks blogs.
In what way is it not supported? By just standing up IaaS Windows VMs in Azure, or using the VPN Gateway? I need to move away from Direct Access On-Prem to AOVPN in the very near future, and ideally I would like to do this in Azure in some way but there is no way my employer will go for it if it is in any way unsupported, even if it operationally works…
I second Richard Hicks. Follow his documentation and articles for some of these issues. If you’re a book reader his AoV book is priceless
When I hit a wall I shot him an email with a few questions and he went as far as to schedule a call with me to review my entire setup. It ended up solving my issue!
I reached out to Richard Hicks, and on the same day he responded and has offered to spend a couple hours next week to help diagnose. Amazing how such a gesture of kindness like that can restore faith in humanity.
Sounds like the focus now is using Azure Virtual WAN which supports AOVPN so why would anyone want to stand up an unsupported configuration on IaaS VMs?
Your initial problem sounds like a DNS issue. However, if you connect via IP address I would expect the IKE authentication error because it’s likely your IP address isn’t the subject name on the IKE certificate.
