Windows 10 Always On VPN is infrastructure independent and can be implemented using third-party VPN devices. It is not necessary to deploy any Windows servers at all to support an Always On VPN solution. However, in a recent blog post I outlined some compelling reasons to consider using Windows Server’s Routing and Remote Access Service (RRAS) feature to terminate VPN connections. RRAS supports both modern and legacy VPN protocols, each with their own advantages and disadvantages. The choice of which protocols to support will be determined by many factors, but it is important to understand the capabilities of each to make an informed decision.
RRAS VPN Protocols
Windows RRAS supports the following VPN protocols.
- Internet Key Exchange version 2 (IKEv2) – RFC7296
- Secure Sockets Tunneling Protocol (SSTP) – Microsoft
- Layer Two Tunneling Protocol over IPsec (L2TP/IPsec) – RFC2661
- Point-to-Point Tunneling Protocol (PPTP) – RFC2637
There are pros and cons associated with each of these VPN protocols. Here’s a breakdown of each.
IKEv2
This IPsec-based VPN protocol is the preferred choice for deployments where the highest level of security is required. The latest version of IKE (v2) features streamlined messaging during connection establishment and enhanced session management that reduce protocol overhead and improve performance.
Advantages: Best security options.
Disadvantages: Firewalls may block required UDP ports.
SSTP
SSTP is an excellent alternative to IKEv2 and is recommended for most deployments. It uses industry standard Transport Layer Security (TLS), making it widely accessible from most locations. It provides good security out of the box but can be improved upon with additional configuration. SSTP lends itself well to load balancing, making it much easier to scale out than IKEv2. Optionally, TLS can be offloaded to an Application Delivery Controller (ADC) to reduce resource utilization on the RRAS server and further improve performance.
Advantages: Easy to configure with firewall friendly access.
Disadvantages: Fewer security options than IKEv2.
L2TP
While technically supported for Always On VPN, L2TP is a legacy VPN protocol that offers no real advantages over IKEv2. Its use is unnecessary and should be avoided.
Advantages: None.
Disadvantages: Firewalls may block required UDP ports.
PPTP
PPTP is considered an obsolete VPN protocol with many known security vulnerabilities. Its use should be avoided at all costs.
Advantages: None.
Disadvantages: Insecure.
Summary
The recommendation is to use SSTP for user-based VPN connections to ensure operational reliability and optimum performance. Use IKEv2 only when the highest level of security is required. Avoid the use of L2TP/IPsec and PPTP at all costs.
Additional Resources
Frequently Asked Questions about Microsoft’s PPTP Implementation
Always On VPN and Windows Server Routing and Remote Access Services (RRAS)
Windows 10 Always On VPN and the Future of DirectAccess
5 Things DirectAccess Administrators Should Know about Always On VPN
3 Important Advantages of Windows 10 Always On VPN over DirectAccess
Diemtar
/ October 2, 2018Hi! Thanks for sharing all your knowledge with us. Can you tell me how to configure SSTP as a fallback for clients that are unable to establish an IKEv2 connection due to restricted firewall access, please? How do you tell the client to prefer IKEv2 and fallback to SSTP? Thank you very much!
Dietmar
Richard M. Hicks
/ October 4, 2018Today it is not possible to configure *automatic* fallback to SSTP when IKEv2 is not available. If you define the NativeProtocolType in your ProfileXML as “Automatic” it will always use SSTP and never IKEv2. I’m hoping that in the future Microsoft changes this, however. For now, if you want SSTP fallback it would have to be configured as a separate manual connection.
Tim
/ October 9, 2018Yes you can, but it’s a manual config file change I’m afraid. For the user in question go to %appdata%\Microsoft\Network\Connections\Pbk and open the rasphone.pbk file in a text editor (Notepad.exe for example) – change the line VpnStrategy=6 to VpnStrategy=8. I found this when I came across the issue that SSTP is tried first THEN IKEv2. The VpnStrategy line dictates which order the different methods are attempted. Here are my findings:
VPNStrategy=
0 = IKEv2 , SSTP , PPTP then L2TP
1 = PPTP
2 = PPTP , IKEv2 , SSTP then L2TP
3 = L2TP
4 = L2TP , IKEv2 , SSTP then PPTP
5 = SSTP
6 = SSTP , IKEv2 , PPTP then L2TP
7 = IKEv2
8 = IKEv2 , SSTP , PPTP then L2TP
Richard M. Hicks
/ October 13, 2018Sort of. 😉 The problem with manually editing the VPNStrategy setting in the rasphone.pbk file is that it does not persist. If you set it to 8 and IKEv2 is unavailable, it will revert to 6. Of course you could script something that changes that setting every time you launch the VPN, but that’s not very elegant. 😉 Hoping Microsoft will address this in the future!
Robert Olsen
/ November 7, 2018We have solved it by scheduling this task (Trigger when computer is idle):
powershell.exe -Command “$infile=$env:APPDATA+’\Microsoft\Network\Connections\Pbk\rasphone.pbk’; $content = (Get-Content -Path $infile -Raw) -replace ‘VpnStrategy=6′,’VpnStrategy=8’ | Set-Content -Path $infile”
Elegant? No, but it does the job without interferring with the user…
Richard M. Hicks
/ November 9, 2018Clever! Definitely not elegant but if it works, it works! 🙂
Robert Olsen
/ November 6, 2018Hello!
You write “SSTP can be enabled as a fallback for clients that are unable to establish an IKEv2 connection due to restricted firewall access.” Where does one do that? If we configufe “Automatic” as the protocol, the connection will try SSTP and then IKEv2 (effectively always connecting over SSTP). Are there any clever ways to make the client have SSTP only as a fallback? The alternatives, as I see it, is to use SSTP for Always On VPN, have a manual VPN pushed out or having a HTTPS DirectAccess as a fallback, none of those is a really good alternative, especially when you are planning to replace our HTTPS DirectAccess (which works pretty much everywhere).
Robert Olsen
/ November 6, 2018Oh, I saw that the question was somewhat already answered above… I guess we have to script a solution in the phonebook then.
Richard M. Hicks
/ November 9, 2018SSTP can certainly be used as a fallback option, but the limitation today is that it is stick and doesn’t every try IKEv2 again. :/ Hoping that Microsoft will address this behavior in the future!
William
/ February 6, 2019Robert Olsen – Great PoSH script/scheduled task.
We have a solution using Group Policy Preferences > Windows Settings > Ini Files and levering GPP to update the line of ‘VpnStrategy’ with a value of 8.
Richard M. Hicks
/ February 9, 2019That is a fantastic idea. Thanks for sharing that tip! I’m assuming this has been working well for you then? Accomplishing the goal of enforcing IKEv2 with fallback to SSTP?
William Fulmer
/ February 9, 2019Working well so far…obviously Microsoft intended that GPP item to be used for .ini and.inf files, so this is a ‘bit’ unorthodox, but it works – similar to the PowerShell Scheduled Task as above.
If only Microsoft would provide native controls for ‘true’ fallback (but not permanently).
Richard M. Hicks
/ February 9, 2019Ok, good to know. I’m going to test it myself over the next few weeks as I’m traveling and see how well it works. My concern is that there might be a timing issue. For example, if an IKEv2 connection fails and SSTP is used, normally the VpnStrategy setting will revert to “6”. So when would GPP reset that to 8 or 14? I’m wondering if it might take a few connections to get this sorted, perhaps caused by a group policy application timing issue. Regardless, it’s better than nothing. Without this workaround you’d have SSTP exclusively!
“
willfulmer
/ February 11, 2019Roger that. With background refresh and Group Policy, this should apply within 90 minutes. Better than any alternative at this point!
Richard M. Hicks
/ February 11, 2019Thanks!
Rick
/ June 11, 2020Hi Richard,
We have launched Always On VPN for the past month and have users on Win10 1709 and 1909. We have noticed the occasional drop of the vpn on both versions but 1909 does seem more stable. Although at least once every day or two we are noticing the device will disconnect from vpn whilst still connected to the internet is this expected behavior or should the solution be more stable?
I can confirm that internet has not dropped out and machine is in use when this occurs.
Richard M. Hicks
/ June 13, 2020Always On VPN is much more stable and reliable with later releases, 1909 being the best so far. Not a lot of data on 2004 at the moment but looks good in my testing. There are a number of things that can cause client disconnects of course. However, this is nothing new for Always On VPN. It seems very few deployments are completely without issues of some sort. 😉