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.

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.

Always On VPN and RRAS in Azure

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

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

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.

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.

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

Leave a comment

46 Comments

  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.

    Reply
    • Justin

       /  September 27, 2019

      Sorry this is meant to be P2S VPN not P2P.

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

      Reply
  2. Lemmings

     /  November 25, 2019

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

    Reply
    • Not at the moment. It is in the queue however. Look for that blog post in the near future! 🙂

      Reply
      • IT Manager

         /  July 14, 2021

        Richard, 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.

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

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

    Reply
    • 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. 🙂

      Reply
      • 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,

      Ed

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

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

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

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

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

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

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

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

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

      Reply
      • 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 🙂

    Reply
  11. kdurigan

     /  November 1, 2020

    Hi 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

    Reply
    • For 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.

      Reply
  12. kdurigan

     /  November 1, 2020

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

    Reply
    • I 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!

      Reply
  13. Fredrik

     /  November 2, 2020

    Thanks 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)

    Reply
    • Configuring 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.

      Reply
  14. James Cook

     /  November 12, 2020

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

    Reply
    • Not 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.

      Reply
  15. Chris

     /  November 30, 2020

    Thanks 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?

    Reply
    • Assuming 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. 🙂

      Reply
  16. Ian Campbell

     /  December 1, 2020

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

    Reply
  17. Nate

     /  January 20, 2021

    Hi,

    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

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

      Reply
      • Nate

         /  February 6, 2021

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

      • Thanks for the kind words, Nate! 🙂

      • Ken Durigan

         /  February 12, 2021

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

      • I’ve not tried this with any other cloud provider. It could very well work in AWS, just not something I’ve tried myself.

  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.
  3. Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN | Richard M. Hicks Consulting, Inc.
  4. Always On VPN Client IP Address Assignment Methods | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading