Azure Point-to-Site VPN with RADIUS Authentication
For the money, it’s hard to beat the Azure VPN Gateway. Until recently though, Point-to-Site VPNs were a bit clunky because they needed mutual certificate authentication. It wasn’t bad, but it certainly wasn’t good. Thankfully, Microsoft now allows RADIUS backed authentication. This post is how you impliment said configuration.
To start off, here is my environment information I’m using to setup this configuration.
Virtual Network: “raidus-vnet”
Virtual Network Address Space: 10.1.0.0/24
Virtual Network VM Subnet: 10.1.0.0/28
Virtual Network Gateway Subnet: 10.1.0.16/28
VPN Gateway SKU: VpnGW1
VPN Client Address Pool: 172.28.10.0/24
Domain Controler/NPS Server Static IP: 10.1.0.10
Virtual Network (VNET) Setup:
You most likely already have a VNET where you will be configuring this setup, but if you don’t you need to create one with two subnets. One subnet for infrastructure, and one “Gateway Subnet”. The Gateway Subnet will be used automatically, and is required, when you configure the VPN Gateway.
VPN Gateway Setup:
The Azure VPN Gateway is just about as easy as it gets to configure and to managed (sometimes to a fault). The only caveat you need to be aware of in this scenerio, is that RADIUS Point-to-Site authentication is only available on the SKU “VPNGW1” and above. You’ll then need to choose the vnet where you have created the VPN Gateway, and create a Public IP Address resource.
This will take anywhere from 20-45 minutes to provision, as noted. While that’s running, you can provision your NPS (Network Policy Server) VM. This being a test environment, I provisioned a VM to be both the domain controler and the NPS box. Make sure to set a static IP on the NPS box’s NIC in Azure, you’ll need a static for your VPN configuration. I used 10.1.0.10.
After complete, you will need to configure the VPN Gateway’s Point-to-Site configuration. Choose “RADIUS authentication”, enter in the static IP of the will-be NPS server, and set a Server Secret. This being a test environment, my password is obviously not as secure as I hope yours would be.
Configure NPS:
Now, go back into that VM that was created earlier and install the NPS role.
After it’s installed, you need to create a Network Policy with a condiational access clause (I used a group in AD) and tell it what security type you want to allow.
Next, you’ll need to create a Client Access Policy. Here you need the IP of the VPN Gateway you created, and the shared secret. Here is the interesting bit, you can’t view the IP of your VPN Gateway in the Gateway Subnet. If you looked at “Connected Devices” in the VNET the VPN Gateway doesn’t show any IP. I know that the VPN Gateway is deployed (behind the scenes) as an H/A pair, but I would assume they’re using a floating IP that they could surface. Anyways, there is no real way to find it – but it looks like (after testing with a dozen different deployments) it uses the 4th available IP in the subnet. This subnet being a 10.1.0.16/28, the 4th IP is 10.1.0.21. This is the IP that goes in the address of the RADIUS Client.
Next, I configure NPS Accounting. You don’t have to do this, but I think it helps for the sake of connection logging and for troubleshooting. You can log a few different ways, and choose here just to use a text file to a subfolder I created called “AzureVPN”.
Generate VPN Client Package:
Now that everything is set, you need to generate a VPN Client Package to distribute to your users.
After it is installed, you can see the VPN Connection in the VPN list and users can logon using their domain credentials.
After logging in, we can go back and look at the accounting log which shows us the successfull authentication of that user.
There we go, connecting to an Azure VPN Gateway with RADIUS authentication using domain credentials. I think we can all thank Microsoft for this one, and not having to do cert management anymore.
I hope I’ve made your day at least a little bit easier.
sn131678
Your posts are turning into my bible.
Thanks
mshansen01
Glad the posts are useful! If there is anything you think I should write a post about, feel free to shoot me a message.
ShadowXVII
Server 2016 NPS supports CIDR ranges as the NPS Client IP Addresses — this makes finding the VPN Gateway IP a bit easier, and handles it’s supposedly Dynamic IP.
Ken
Thank you for posting this – it was a brilliant source of info. I too struggled with the VPN gateway ip address and had initial success with the forth IP address that you suggested- until it changed on a VPN restart. I came across this link :- https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-radiuis-mfa-nsp.
Here it suggests just putting in the whole Subnet address range for the source IP address – Never occurred to me but it appears to work and will accommodate address change with in the subnet.
I think this is maybe what ShadowXVII is saying, so, apologies for the repost – Not really a network guy!
stuhad
Does your NPS server need to be set up with a cert that matches the DNS name of the Azure VPN endpoint?
something like:
azuregateway-randomstring.cloudapp.net
I’ve followed this guide but when I try to connect the Azure VPN client it seems to get stuck verifying password. I can see the request coming in to the NPS server, and the auth request gets logged in the Accounting logs with what I gather is a successful code:
0
However another event that suggests access was granted never appears in Event Viewer under the NPS logs.
So I’m just wondering if there is something I’m missing, or just something that is assumed in this guide that I’m not knowledgeable enough to figure out for myself?
Hariharan Anantharaman
Thanks a lot. It is really helpful. I ended up doing a small tweak. In the “Radius Client” setup section, only afte giving IP equal to the public IP of the VPN gateway, it was working. I also enabled (default disabled) “Use windows authenticatiion for all users”
Glitter Johnson
Hi,
Thanks for the post. I configured the radius server for the authentication of Azure VPN. It was working fine but down suddenly last day. I couldn’t find any reason. Finally contacted the MS Team and got a reply that I should have two IP’s one for update from azure and one for service. Is it correct that we should have two nic for Radius with out interruption.
juraj
has the question about radius server’s DNS name matching the vpn endpoint’s DNS been resolverd? curious about it too..
Joe
The IP for the Radius is going to be the fully entered subnet… not an individual IP address. SO in the example above it is 10.1.0.16/28 and not 10.1.0.21
This might have worked in the past. But as of Dec 27 2019 it works with full subnet in the field for IP address.
Azure Active Directory Domain Services (AADDS) | Domain Join for external Windows Client Workstations with P2S VPN at Logon Screen established - .matrixpost
[…] Azure Point-to-Site VPN with RADIUS Authenticationhttps://thetechl33t.com/2018/01/08/azure-point-to-site-vpn-with-radius-authentication/ […]
skup samochodów Kobiór
Excellent pieces. Keep writing such kind of info on your blog.
Im really impressed by it.
Hey there, You have performed a fantastic job. I’ll certainly digg it and individually
recommend to my friends. I’m sure they will be
benefited from this web site.
Azure Web App with Cost Effective, Private and Hybrid Connectivity « The Tech L33T
[…] network and create an emulated “client” machine, alternatively you could also setup a point-to-site VPN for just your local machine. I won’t be showing that process here, but I have another post […]
Azure Site-to-Site VPN with Palo Alto Firewall « The Tech L33T
[…] Azure Point-to-Site VPN with RADIUS Authentication « The Tech L33T […]
Sean
Is there any way to manually create the VPN client? I have an environment that users are not supposed to be local admins on their machines but we need them to have access to this VPN client. Any thoughts on that?
Mlody45
Thank you very much. Only here i found VPN Gateway address which works. So many hours of searching 😀
Davey
thank you for this. As for me it work on the 5th host ip address (I used 10.1.2.0/27) since it was flagging on the event log: “A RADIUS message was received from the invalid RADIUS client IP address 10.1.2.5”. Its weird since the 10.1.2.4 can be pinged too . my two cents.