When deploying Windows 10 Always On VPN, it may be desirable to host the VPN server in Microsoft’s Azure public cloud. Recently I wrote about Always On VPN deployment options in Azure, and in that post I indicated that deploying Windows Server and the Routing and Remote Access Service (RRAS) was one of those options. Although not formally supported by Microsoft, RRAS is often deployed in Azure because it is cost-effective, easy to manage, and provides flexible scalability.
Supportability
It’s important to state once again that although it is possible to successfully deploy Windows Server with RRAS in Azure to support Always On VPN, as of this writing it is not a formally supported workload. If the administrator makes the decision to deploy RRAS in Azure, they must also accept that Microsoft may refuse to assist with troubleshooting in this specific deployment scenario.
Azure Prerequisites
The configuration of RRAS is identical to on-premises, with a few additional steps required by Azure infrastructure.
Windows Server
RRAS can be configured on any Windows Server virtual machine supported in Microsoft Azure. As with on-premises deployments, Server GUI and Core are supported. Domain-join is optional. The server can be deployed with one network interface or two.
Public IP
A public IP address must be assigned to the VPN server’s external network interface, or the internal interface if the VPN server is configured with a single network adapter. The IP address can be static or dynamic. When using a dynamic IP address, configure a CNAME record in DNS that points to the name configured for the IP address in Azure. If using a static IP address, an A host record can be configured pointing directly to the IP address.
Network Security Group
A Network Security Group (NSG) must be configured and assigned to the VPN server’s external or public-facing network interface that allows the following protocols and ports inbound.
- TCP port 443 (SSTP)
- UDP port 500 (IKEv2)
- UDP port 4500 (IKEv2 NAT traversal)
RRAS in Azure
Below are the infrastructure requirements for supporting Windows Server RRAS VPN in Azure.
Client IP Subnet
Static IP address pool assignment must be used with RRAS. Using DHCP for VPN client IP address assignment in Azure is not supported and will not work. The IP subnet assigned to VPN clients by RRAS must be unique and not overlap with any existing Azure VNet subnets. If more than one VPN server is deployed, each server should be configured to assign a unique subnet for its clients.
IP Forwarding
IP forwarding must be enabled on the VPN server’s internal network interface. Follow the steps below to enable IP forwarding.
1. In the Azure portal, open the properties page for the internal network interface for the VPN server.
2. Click IP configurations in the navigation pane.
3. Click Enabled next to IP forwarding.
4. Click Save.
Routing
Azure must be configured to route IP traffic from VPN clients back to the VPN server. Follow the steps below to create and assign a routing table in Azure.
1. Click Create Resource.
2. Enter “Route Table” in the search field and press Enter.
3. Click Route Table.
4. Click Create.
5. Enter a descriptive name for the route table in the Name field.
6. Choose an appropriate subscription from the Subscription drop-down list.
7. Select the resource group where the VPN server(s) reside.
8. Select the best location to deploy the route table resource from the Location drop-down list.
9. If the administrator wants to have the VPN client IP subnet route information published automatically, select Enabled for Virtual network gateway route propagation.
10. Click Create.
Once complete, follow the steps below to define the route for VPN clients.
1. Open the properties page for the route table.
2. Click Routes in the navigation pane.
3. Click Add.
4. Enter a descriptive name in the Route name filed.
5. Enter the IP subnet assigned to VPN clients in the Address prefix field.
6. Select Virtual appliance from the Next hop type drop-down list.
7. Enter the IPv4 address assigned to the VPN server’s internal network interface in the Next hop address field.
8. Click Ok.
9. Repeat the steps above for each VPN server configured in Azure.
Finally, follow the steps below to assign the route table to an Azure VNet subnet.
1. Open the properties page for the route table.
2. Click Subnets in the navigation pane.
3. Click Associate.
4. Click Virtual network.
5. Choose the appropriate Azure VNet.
6. Click Subnet.
7. Choose an Azure VNet subnet to assign the route table to.
8. Click Ok.
9. Repeat the steps above to assign the route table to any Azure VNet subnet that must be accessible by VPN clients. If VPN clients need access to on-premises resources via Azure site-to-site gateway, assign the route table to the Azure VPN gateway subnet.
Note: Azure only supports the assignment of one route table per subnet. If a route table is currently assigned, the VPN client subnet route can be added to an existing route table, if necessary.
Summary
Administrators have many choices when it comes to support Always On VPN connections hosted in Azure. RRAS on Windows Server can be an effective solution, assuming you can live without formal support. If having a formally supported solution is a hard requirement, consider deploying Always On VPN using the native Azure VPN gateway or another third-part Network Virtual Appliance (NVA).
Additional Information
Windows 10 Always On VPN with Azure Gateway
Windows 10 Always On VPN Options for Azure Deployments
Windows 10 Always On VPN Multisite with Azure Traffic Manager
Justin
/ September 27, 2019Thanks Richard for another great post!
I’m feeling very frustrated with Azure P2P VPN options. We have a Expressroute and the Azure P2P can’t work with this due to Gateway transit restrictions allowing only one gateway on a vnet peer and p2p VPN and Expresroute won’t work on single Vnet. Thinking about trying the RRAS option with no support. Were you able to get the p2p VPN working with Azure VPN Gateway and Expressroute ? I need the users to be able to connect to the VPN and then traffic flow over the Expressroute to on premise. I was able to get the p2p VPN working with Azure VPN Gateway but could not access any resources either in Azure or on premise over Expressroute.
Justin
/ September 27, 2019Sorry this is meant to be P2S VPN not P2P.
Richard M. Hicks
/ October 7, 2019I’ve not tested with Express route myself, but I can tell you that using the Azure VPN gateway isn’t the ideal solution due to some of the limitations imposed by the infrastructure. Limited scalability is another challenge. RRAS does work well, is flexible and scalable, and if you can accept the non-supportability it can be a good solution.
Lemmings
/ November 25, 2019Richard, thanks for the Azure guide; do you have similar guides for AWS routing?
Richard M. Hicks
/ November 25, 2019Not at the moment. It is in the queue however. Look for that blog post in the near future! 🙂
IT Manager
/ July 14, 2021Richard, Thank you for this article. We are working on implementing this in AWS. Did you ever write the equivalent post for AWS. Having searched the site, I have been unable to find one that addresses routing and site-to-site access in AWS for AoVPN.
Richard M. Hicks
/ July 15, 2021I have implemented RRAS in AWS, but haven’t yet published a post on it. It’s on my list of things to do. I hope to have something posted on this topic in the future at some point.
[email protected]
/ January 9, 2020Hi Richard
Thank you so much for this article.
I have always-on vpn working now in Azure with RRAS and clients being able to route back to on-prem through a express route.
The missing information for me to get it working was to associate the route to the gateway subnet where the express is connected to.
Richard M. Hicks
/ January 9, 2020Great to hear! Indeed, if you want to be able to route VPN client traffic back on-premises via site-to-site or ExpressRoute you must assign the route to the gateway subnet. It’s easy to overlook that crucial bit of information for sure. 🙂
Viraj
/ March 18, 2020Hi Richard, awesome article! We’re seeing the same issue as Ed though. Applying the static route to the gateway subnet doesn’t allow RRAS VPN client traffic to the on-prem subnets connected to Azure via IPSec VPN. Almost seems like that subnet needs to be created in Azure and added to the existing encryption domains for the existing IPSec tunnels? Any help appreciated!
Richard M. Hicks
/ March 18, 2020Interesting. And you are sure that you have configured the on-premises gateway correctly? VPN client subnet is routed to Azure form on-premises? Traffic selectors updated accordingly?
Ed
/ March 5, 2020Hi Pete,
We are trying the same configuration, however we are not seeing the user-defined route (client VPN subnet) being advertised into our express route. We have applied the route table to the Gateway Subnet, but it is still not working. Perhaps you can share some further detail about how you got this working?
Kind regards,
Ed
Justin Nel
/ February 7, 2020Hi Richard, a bit of a late reply.Thanks for all your help! I decided to use the RAS VPN option on an Azure VM over the Azure VPN Gateway after having so much trouble with it. I’ve been using the RAS VPN for a couple of months now and had no problems, works like BOSS. The route on the GW subnet also helped me thanks. I’m now able to communicate back over the Expressroute and access resources on-premise, the fix for me was to use Force tunneling on the adapter. When I was using split tunneling I could only get it to work with static routes which was quite messy and also allowed local internet breakout which defeats the object of the security of a VPN for me.
Justin
/ February 27, 2020Hi Richard, I’m having an issue with AOVPN user tunnels when plugging an ethernet cable into a laptop that is currently connected to the VPN over wifi. What seems to be happening is that the VPN is not disconnecting even though it is on the trusted corporate network. We don’t want our users connecting over the VPN when on our corporate LAN. It seems to me that the trusted network detection is working intermittently even though I have the tag configured in the script. I’m just wondering if you have come across this before and might be able to point me in the right direction? To add we are not using lockdown mode. Thanks, Richard appreciate all your help so far!
Richard M. Hicks
/ February 27, 2020Hi Justin,
Always On VPN and Trusted Network Detection is actually working just fine. However, if you have an existing wireless connection to the network established and you later connect directly with wired Ethernet, the Always On VPN connection just remains up (by design). You can fix this behavior by setting two specific group policy options. The settings are in the following location:
Computer Configuration > Administrative Templates >> Network >> Windows Connection Manager
The two settings that you should enable are:
Enable Windows to soft-disconnect a computer from a network = Disabled
Minimize the number of simultaneous connections to the Internet or a Windows Domain = Enabled (1 – Minimized simultaneous connections)
Let me know if that helps at all!
sergiibiletskyi
/ March 4, 2020Hi Richard,
Here is the update to my previous message. Issue has been solved by simply adding VPN client network to source gateway address space:)
Really missed the place where all GW’s network ranges are added:)
sergiibiletskyi
/ March 4, 2020P.S. Looks my main message has not been sent:(
So the issue was that i couldn’t make VPN clients be available from other VNETs via vnet-to-vnet tunnels.
Andrew
/ March 30, 2020Great article Richard, thanks for this. Getting AOVPN setup was a snitch in Azure following your advice, any pointers for trying to get the clients to connect to the on-premises over ExpressRoute at all? am I missing anything obvious at all?? ExpressRoute is configured with BGP.
Richard M. Hicks
/ March 30, 2020Funny you should ask this. I just learned yesterday that you can’t access on-premises resources via Azure VPN gateway point-to-site connections! Somehow that is not supported. You can certainly connect via site-to-site, but Express route doesn’t work for some reason. Apparently this is supported using Virtual WAN though. I haven’t done much work with Virtual WAN, but I’m hoping to in the near future. It really looks like the way to go in the future.
sergiibiletskyi
/ April 13, 2020Hi Richard, and thank you for a great article!
The only problem i noticed using RRAS on Azure is when you need to let clients to reach specific public resources routed via VPN. In this case there is a need to enable NAT protocol on RRAS server and with NAT enabled there is no need to add extra routes on Azure networking side.
Also, strangely enough, one of my RRAS servers with NAT enabled experience RRAS service error after restart.
Faulting application name: svchost.exe_RemoteAccess, version: 10.0.17763.1, time stamp: 0xb900eeff
Faulting module name: ntdll.dll, version: 10.0.17763.1131, time stamp: 0x4dc06dfc
Exception code: 0xc0000374
Fault offset: 0x00000000000fb049
Faulting process id: 0xdd4
Faulting application start time
The only way to start service back is to remove NAT, start service and add NAT back in my case.
Richard M. Hicks
/ April 13, 2020That’s certainly less than an ideal configuration (using NAT for VPN traffic), but if it works for you I can’t argue with that. 😉 Odd issue with the service crash though. I’d say opening a support case with Microsoft would be a good idea, but RRAS in Azure isn’t supported. Unless you can reproduce the issue on-premises they won’t likely give you much help.
sergiibiletskyi
/ April 14, 2020I’d love to avoid NATing VPN clients but looks like that’s the only option with RRAS server on Azure.
The private routing according to your guide works perfect but in my case i need some public resources be routed via VPN and that’s not only web services so web proxy is not an option in my case.
Richard M. Hicks
/ April 15, 2020If you have the requirement to route Internet traffic over the VPN, then you’ll have to live with the NAT to make it work. There’s always tradeoffs! 🙂
Mohammad
/ May 25, 2020Thanks Richard I was stuck on this for a week until I found your great article 🙂
kdurigan
/ November 1, 2020Hi Richard, I just ran across this article and really hoped it would solve my issue but so far, no luck. My clients connect successfully to the RRAS server with SSTP. I can access resources on the RRAS server but not beyond. For example, I can ping the server’s NIC but not 8.8.8.8. What I see in Wireshark (or Network Watcher) are the packets from the client being sent but no packet ever gets a response. I am not sure what is blocking the outbound (or possibly inbound) packets. My goal is to force tunnel all traffic through the VPN when the client is connected, including internet bound traffic. For clarity, my Azure based RRAS server IP is 10.2.0.4, the static pool for VPN is 192.168.3.50 – 64 so the server’s virtual interface is 192.168.3.50 and clients get addresses in the pool above .50. All routes on the server are created by RRAS – I do not define any static routes myself. Everything works except the final route beyond the server. BTW, the RRAS server itself has no issues pinging or communicating to internet sites. Any thoughts on what step I may have missed? Also, why is a CNAME required on DNS for the public IP? Thanks
Richard M. Hicks
/ November 1, 2020For some reason Azure does not support routing traffic to the Internet in this scenario. If you plan to use Azure, you must enable split tunneling. It is possible there’s a workaround for this, but I’m not aware of it. The CNAME is required so the subject name on your TLS certificate used for SSTP matches the FQDN used by VPN clients.
kdurigan
/ November 1, 2020Thanks for the quick reply. Do you happen to know if P2S VPN would allow me to route all traffic over the VPN, including to the Internet? Split tunneling is what I want to avoid.
Richard M. Hicks
/ November 2, 2020I don’t believe so, but it’s not something I’ve tested. Perhaps it works differently, not sure. Let me know if you try it!
Fredrik
/ November 2, 2020Thanks a million for this article, Richard!
There is one small thing that we cant get to work the same way as in our current in-house infrastructure (which we are moving to Azure):
Once we have created the client’s VPN-configuration, we must set the DNS suffix to “internal.ourcompany.se” for IPv4.
Without that, we have to use the FQDN when accessing resources over VPN. Also (which is strange to me), internet connection is lost for the client.
Any ideas why this is? (We don’t need to do this in our current in-house infrastructure, which uses the same setup, although we host our own DHCP-server)
Richard M. Hicks
/ November 6, 2020Configuring the DNS suffix for the VPN connection is pretty standard. I do it for every deployment. Although it may not be strictly required (you could be providing it via group policy for example) I still do it just be certain it is there.
James Cook
/ November 12, 2020Hi, thanks very much for this article. Have you seen this error with this configuration “A connection between the VPN server and the VPN client IPADDRESS has been established, but the VPN connection cannot be completed. The most common cause for this is that a firewall or router between the VPN server and the VPN client is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47).” – A bit of googling suggests this might be getting blocked at the azure level but I see comments here of people having success with this working
Richard M. Hicks
/ November 17, 2020Not seen that myself. I’ve deployed RRAS in Azure numerous times without issue, so it should work. I’d suspect VPN server configuration. What specifically I’m not certain though.
Chris
/ November 30, 2020Thanks for this guide, was really, really helpful – I have a problem however where I can VPN in and route packets within the azure tenant, but can’t get packets across our VPN to on premise, I’ve added the route to the route table (the same route table that gets everything else down to on prem) but no luck – any tips?
Richard M. Hicks
/ November 30, 2020Assuming your link from Azure to on-premises is a site-to-site link and not ExpressRoute it should work. If that’s the case it is either a routing issue, firewall issue, or combination of the two. 🙂
Ian Campbell
/ December 1, 2020Bless your heart! I struggled with this for a day and a half before I found this article. Routing the subnet to the Virtual Appliance was what fixed it. You rule!
Richard M. Hicks
/ December 1, 2020🙂
Nate
/ January 20, 2021Hi,
This is similar to kdurigan’s issue but different behavior. We’ve been running RRAS in Azure for a year with very few issues. Recently there’s been a new need to route select Internet IPs over the VPN to simplify our IP ACLs and we’re running into an odd issue. RRAS has two NICs (internal/external), and both NICs have NAT enabled so that we didn’t have to add routes to all of our SNets. IP forwarding is off on both NICs because it wasn’t needed with NAT enabled.
During the initial build, I added static routes in RRAS for our internal subnets to route out of the internal NIC’s gateway and an OS-level persistent default route to use the external NIC’s gateway. Traffic didn’t route properly and clients couldn’t connect until I configured it this way.
Now that VPN clients need to get to Internet IPs, I found that I needed to add a default route in RRAS as well to use the external NIC’s gateway.
This works… for a little while. Some time later (minutes to an hour or two), clients are no longer able to connect to that RRAS server but it’s still online in Traffic Manager. When I remove the default route from RRAS (and reboot for good measure), it still takes about 30 minutes before clients are able to connect consistently.
It seems like something with the RRAS default route is propagating into and breaking the VNet or something even though the same persistent route is set at the OS level. Has anyone run into this?
Thanks,
Nate
Richard M. Hicks
/ January 21, 2021I’ve never had success getting Internet traffic routed over an RRAS server hosted in Azure. Not sure if anyone else has had any success with that either.
Nate
/ February 6, 2021Thanks, Richard.
If my failure helps anyone else to not bother: I also tried using RRAS routes for individual Internet IPs (instead of a default route), since we had only a handful of them, and I had pretty good success when testing it myself. As soon as I added a few more users to the pilot, it immediately fell apart. It seemed to allow only one VPN client at a time to access an Internet route to a specific IP, like a one-to-one relationship cap between VPN clients and the Internet route. I would LOVE to know how this works under the hood; it makes little sense from an Azure user perspective. So, back to the drawing board.
By the way, thanks again for all your help Richard. You’re the main reason why I have a successful implementation to begin with. You are very much appreciated.
Richard M. Hicks
/ February 10, 2021Thanks for the kind words, Nate! 🙂
Ken Durigan
/ February 12, 2021Re Richard’s comment: “I’ve never had success getting Internet traffic routed over an RRAS server hosted in Azure. Not sure if anyone else has had any success with that either.” – I have to ask… Is this only a problem in Azure or is this a cloud agnostic problem? I never did get it to work in Azure no matter what I tried.
Richard M. Hicks
/ February 15, 2021I’ve not tried this with any other cloud provider. It could very well work in AWS, just not something I’ve tried myself.