Always On VPN and Windows Routing and Remote Access Service (RRAS)

Always On VPN and Windows Routing and Remote Access Service (RRAS)

As I’ve written about in the past, Windows 10 Always On VPN has many advantages over DirectAccess. One of the most important features is that Always On VPN is completely infrastructure independent. Always On VPN is implemented entirely on the client side, so there is no reliance on Windows infrastructure servers at all. In theory, you could deploy an Always On VPN solution using an entirely third-party backend infrastructure. This is crucial because many organizations already have security infrastructure in place today. However, there are still some compelling reasons to choose Windows Server 2016 as the VPN server to support Windows 10 Always On VPN.

Considerations for Windows Server

Windows Server 2016 includes a very capable VPN server in the Routing and Remote Access Service (RRAS) role. Using Windows Server 2016 RRAS will meet the requirements for many deployment scenarios. RRAS also provides some unique advantages too. The following are some important considerations for choosing RRAS for VPN.

Easy to Deploy

The RRAS role in included in all Windows server network operating systems and can be enabled easily using the GUI or PowerShell. RRAS is mature and well-documented, making installation and configuration simpler. In fact, all of the Microsoft Windows 10 Always On VPN documentation guidance references RRAS.

Reduced Costs

No investment in proprietary hardware is required, because RRAS runs on Windows Server 2016 and can be deployed on existing virtual infrastructure. Deploying additional RRAS virtual machines enables quick and efficient scaling up of the solution without the need to deploy additional expensive hardware. Importantly, RRAS requires no additional per-client or per-device licensing. In addition, RRAS can be managed using existing Windows administration skill sets and does not require dedicated, and often expensive solution-specific expertise.

Modern Protocol Support

RRAS includes support for modern VPN protocols such as Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). IKEv2 is the protocol of choice or most deployments, and is required for supporting the device tunnel. SSTP is a firewall-friendly protocol that ensures remote Windows clients can connect from anywhere. Layer Two Tunneling Protocol over IPsec (L2TP/IPsec) and Point-to-Point Tunneling Protocol (PPTP) are also supported for legacy client compatibility.


Although Windows 10 Always On VPN can be implemented using third-party VPN servers, it’s important not to overlook Windows server either. Windows Server 2016 RRAS has some important advantages over third-party infrastructure. RRAS is mature and well understood, with an abundance of published documentation available. Leveraging RRAS eliminates the need for costly proprietary hardware and client licensing, while at the same time reducing administrative overhead and streamlining support. RRAS also includes native support for modern VPN protocols, ensuring reliable client connectivity from any location.

Additional Resources

3 Important Advantages of Windows 10 Always On VPN over DirectAccess 

Windows 10 Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know About Always On VPN 

Leave a comment


  1. Eric Yew

     /  September 5, 2018

    Hi you know if it’s possible to lock down a User Tunnel VPN from being modified by a user? I know device tunnel is not editable by standard user, but curious if it was possible to lock down a user tunnel VPN profile.

    • There is no way to prevent a user from modifying the Always On VPN user tunnel. There is a “lockdown VPN” option which prevents users from tampering with the settings, but it also prevents any Internet access when the VPN is not connected.

  2. Marc

     /  November 26, 2019

    We’ve been using AoVPN device tunnels for a few months now and have noticed that in RRAS we’re seeing a lot of sessions showing per device. Each of these sessions has a different connection time/duration, so it doesnt seem like its generating multiple IPSEC sessions or showing a different session for each SA as far as I can tell.

    Is this normal or is there something remedial we’ve missed to force/limit clients to only open one device tunnel session?

    • This seems to be pretty common in my experience. Not sure there’s a problem, but it could be the result of client connections not disconnecting gracefully, leaving some orphaned sessions behind. FYI, there is a known issue with RRAS where some IKEv2 connections are never terminated, even though there’s no client connected. The only workaround is to restart the RemoteAccess service or restart the server.

  3. Bobby

     /  March 6, 2020

    Hi Richard, Whats your your take on having a RRAS and NPS roles on the same server?

    • For proof-of-concept testing/evaluation or small production deployments I have no problem using NPS that is installed along with RRAS. I would avoid installing the NPAS role on the VPN server though. If you need full NPS functionality it is best to use a separate NPS server.

  4. Craig Wilson

     /  March 13, 2020

    Hi Richard,

    Can you tell me how does the solution scale? I mean typically when deploying a single RRAS instance with IKEv2 what would be the amount of clients expected before this service would suffer performance issues? Are we talking 500 concurrent users, 1000 or higher?


    • With a moderately provisioned virtual machine (e.g. 4 CPUs and 8GB RAM) you can expect to support 1,000 to 1,500 concurrent connections without much trouble. You can likely push that to 2,000 to 2,500 with 8 CPUs and 16GB RAM. Much past that I’d suggest adding more servers as this workload responds better to scaling out vs. scaling up.

  5. Jesper

     /  April 20, 2020

    Hi Richard,
    What should i except in throughput on a SSTP user tunnel? In average I get around 6-700kbps. Both the server and clients have much more available bandwidth. Is this what RRAS can handle per client or have you seen better performance?
    Tested with different versions of Windows 10. Server is running 2016.

    • Depends, really. I routinely see 20-30 Mbits/sec when I use iPerf. I will typically see much less if I’m just trying to copy a file though.

  6. Ian Salgado

     /  June 7, 2021

    Hi Richard,

    do you have a post where you show how to setup “Always ON VPN (IKEv2) without a RRAS ? (may using a firewall + ActiveDirectory/NPS server ?)

    thank you



    • I don’t, unfortunately. Windows Server RRAS is by far the most popular solution, so that’s what I end up working with most. I have done some work with Cisco and Palo Alto using their native clients and also IKEv2, just haven’t documented any of that. Honestly though, you should be able to find published guidance on the Internet for configuring whatever solution you choose. From there, you just need to configure the same IKEv2 settings on the client and it should work. It’s even easier if you use the vendor’s plug-in client. I do have a sample Always On VPN XML configuration file for Palo Alto on my GitHub if that helps at all.

  1. Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Service (RRAS) | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Certificate Requirements for IKEv2 | Richard M. Hicks Consulting, Inc.
  3. Always On VPN SSL Certificate Requirements for SSTP | Richard M. Hicks Consulting, Inc.
  4. Always On VPN Options for Azure Deployments | Richard M. Hicks Consulting, Inc.
  5. Error Importing Windows Server RRAS Configuration | Richard M. Hicks Consulting, Inc.
  6. Always On VPN and RRAS with Single NIC | Richard M. Hicks Consulting, Inc.
  7. Always On VPN RRAS Monitoring and Reporting | Richard M. Hicks Consulting, Inc.
  8. Always On VPN SSTP Load Balancing with Citrix NetScaler ADC | Richard M. Hicks Consulting, Inc.
  9. Inbox Accounting Database Management | 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