Always On VPN and RRAS in Azure

Always On VPN and RRAS in AzureWhen 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.


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.

Always On VPN and RRAS in Azure


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.

Always On VPN and RRAS in Azure


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.

Always On VPN and RRAS in Azure

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.

Always On VPN and RRAS 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.

Always On VPN and RRAS in Azure

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.


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

Leave a comment


  1. Justin

     /  September 27, 2019

    Thanks 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, 2019

      Sorry this is meant to be P2S VPN not P2P.

    • I’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.

  2. Lemmings

     /  November 25, 2019

    Richard, thanks for the Azure guide; do you have similar guides for AWS routing?


     /  January 9, 2020

    Hi 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.

    • Great 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, 2020

        Hi 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!

      • Interesting. 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, 2020

      Hi 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,


  4. Justin Nel

     /  February 7, 2020

    Hi 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.

  5. Justin

     /  February 27, 2020

    Hi 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!

    • Hi 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!

  6. sergiibiletskyi

     /  March 4, 2020

    Hi 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:)

  7. sergiibiletskyi

     /  March 4, 2020

    P.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.

  8. Andrew

     /  March 30, 2020

    Great 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.

    • Funny 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.

  9. sergiibiletskyi

     /  April 13, 2020

    Hi 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.

    • That’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, 2020

        I’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.

      • If 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! 🙂

  10. Mohammad

     /  May 25, 2020

    Thanks Richard I was stuck on this for a week until I found your great article 🙂

  1. Always On VPN Load Balancing for RRAS in Azure | Richard M. Hicks Consulting, Inc.
  2. Always On VPN RRAS Monitoring and Reporting | Richard M. Hicks Consulting, Inc.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: