A while back I wrote about the various VPN protocols supported for Windows 10 Always On VPN. The two most common are Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). The article covers in detail each protocol’s advantages and disadvantages. To summarize, IKEv2 provides the best security (when configured correctly!) and SSTP is firewall-friendly ensuring ubiquitous access. Ideally an Always On VPN connection will attempt to use the more secure IKEv2 first, then fallback to SSTP only when IKEv2 is unavailable. Unfortunately, Always On VPN connections do not work this way today.
IKEv2 and SSTP
IKEv2 and SSTP are not mutually exclusive. When using Windows Routing and Remote Access Service (RRAS) as the VPN server, both protocols can be configured and enabled for VPN clients. To allow VPN clients to automatically select a protocol, the NativeProtocolType element in ProfileXML can be set to Automatic.
IKEv2 with SSTP Fallback?
In theory, with the NativeProtocolType set to Automatic, the Windows 10 client would first attempt to establish an IKEv2 connection, then fall back to SSTP if IKEv2 is not available. In practice, this is not the case.
SSTP Preferred over IKEv2
In operation, setting the NativeProtocolType to Automatic results in the Windows 10 client attempting to establish a VPN connection using SSTP first! If the SSTP connection fails, only then will IKEv2 be used. The only scenario in which I can imagine SSTP failing and IKEv2 being successful would be if SSTP is not supported by the VPN server. Sadly, this scenario may result in failed connections due to a bug in the way ProfileXML settings are processed. Details here.
VPN Strategy
The initial VPN protocol selection behavior is dictated by the VpnStrategy setting of the Always On VPN connection in the rasphone.pbk file. This file can be found under C:\Users\[username]\AppData\Roaming\Microsoft\Network\Connections\Pbk. The documentation on the Microsoft website is terribly outdated and does not include the following important VpnStrategy settings pertinent to Windows 10 Always On VPN connections.
- 5 = Only SSTP is attempted
- 6 = SSTP is attempted first
- 7 = Only IKEv2 is attempted
- 8 = IKEv2 is attempted first
- 14 = IKEv2 is attempted followed by SSTP
Always On VPN Default Behavior
For Always On VPN, when the NativeProtocolType is set to Automatic in ProfileXML, VpnStrategy is set to 6 by default, which means the connection will attempt to use SSTP first. If it fails, IKEv2 will be attempted.
If the NativeProtocolType in ProfileXML is set to IKEv2, VpnStrategy is set to 7 and only IKEv2 is used. A connection using SSTP is never attempted.
Workaround
Setting the VpnStrategy to 8 or 14 will force the client to attempt an IKEv2 connection first. However, this setting is dynamically updated by Windows and is subject to change. For example, if an IKEv2 connection fails and SSTP is successful, Windows will then set the VpnStrategy to 6 and all subsequent VPN connection attempts will use SSTP first. Because of this it will be necessary to update the VpnStrategy setting each time prior to establishing a VPN connection. This will require some clever scripting and perhaps automation using a scheduled task based on an event trigger. I will leave that custom configuration as an exercise for the reader. If you’ve developed something to address this challenge, please feel free to share in the comments below. 🙂
Additional Information
Always On VPN Protocol Recommendations for Windows Server RRAS
Always On VPN IKEv2 Security Configuration
Always On VPN Certificate Requirements for IKEv2
Always On VPN IKEv2 Load Balancing with KEMP LoadMaster Load Balancer
Colin
/ January 15, 2019I imagine Microsoft will eventually address this and have Automatic work as expected. They have already said they plan on addressing the manage-out issue (really looking forward to this one bwt).. this should just be another bug fix I would imagine? Might be better to just live with it for now rather than going custom script crazy just to have Microsoft come in and change the behavior.
Richard M. Hicks
/ January 15, 2019I expect the same. No doubt many customers are complaining about this behavior. Today, my advice is to pick one protocol or the other and go with it. If you really need the additional security of IKEv2, go with that and accept that there may be some coverage gaps. You can always provide a manual VPN connection using SSTP as a backup in those cases. If you don’t need the highest level of security, SSTP is an excellent choice that still provides very good security when configured correctly, and most likely meets the security requirements for most organizations anyway. When Microsoft gets this sorted out, then enabling automatic protocol selection might make more sense. 🙂
willfulmer
/ February 6, 2019Currently using 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! 🙂
Colin Pazdzior
/ February 12, 2019Just wrote this – now for the scheduled task triggers!
—————————————————————————————-
#This script checks local user VPN strategy and overrides it – this is important as Windows
#dynamically changes and updates this, often to undesired settings.
#Get rasphone.pbk path for local user
$RASPhone = ($env:USERPROFILE) + ‘\Appdata\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk’
#Get current VPN Strategy (5=SSTP only, 6=SSTP first, then others, 7= IKEv2 only, 8=IKEv2
#first, then others, 14=IKEv2 then SSTP
$OldVPNStrategy = (Get-Content $RASPhone) -like “VpnStrategy=?”
#Set desired VPN Strategy – should be 14 for IKEv2 preferred and SSTP as fallback
$NewVPNStrategy = “VpnStrategy=14”
#Check if current VPN Strategy matches desired, end if true, continue if false
If ($OldVPNStrategy -ne $NewVPNStrategy)
{
(Get-Content $rasphone).Replace($OldVPNStrategy,$NewVPNStrategy) | Set-Content $RASPhone
}
—————————————————————————————-
Richard M. Hicks
/ February 12, 2019Another good option. Thanks for sharing! 🙂
Shane
/ March 15, 2019I have a question regarding the setup of SSTP. I have setup a radius and RRAS server and can connect using the device tunnel using IKEv2. I am trying to setup a user tunnel using SSTP, but running into issues. Do you have any specific information on what needs to be setup on the RRAS and Radius server in order for that to work?
Thanks!
Shane
Richard M. Hicks
/ March 15, 2019Try this: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-nps. 🙂
David Kafrissen
/ July 26, 2019HI
We are looking to migrate from our DA server to Always on Server.
We were going to use the existing DA server, but this doesn’t look like we can as the current RRAS security setting for Authentication is on Windows Auth and not Radius.
From following along on the MS site they want Radius.
Should I just build a new server and point to the existing NPS server (also the DA server)?
Thanks
David
Richard M. Hicks
/ July 26, 2019It’s a good idea to separate VPN and DirectAccess anyway, so I’d suggest going that route. It will make your life much easier in the end. 🙂
Luke Flack
/ August 5, 2019Hi Richard,
I have specified the excryption settings in the CryptographySuite eliment of the ProfileXML, and on the server. When I set the NativeProtocolType to IKEv2 it connects fine.
When I set the NativeProtocolType to Automatic I find that SSTP works fine but the encryption settings in ProfileXML do not seem to apply for IKEv2.
When I set the VpnStrategy to 8 or 14 IKEv2 always fails and moves on to SSTP. If I set the VpnStrategy to 7 (IKEv2 only) it will not connect at all giving me a Policy match error.
I have run a network trace and I can see that the old default 3DES is being presented by the client.
The only difference in the ProfileXML is changing the NativeProtocolType from IKEv2 to Automatic.
Is this a bug? I’m running Windows 1709 at the moment.
Thanks,
Luke
Richard M. Hicks
/ August 5, 2019This is a bug that Microsoft is aware of, but I’m not sure if they are actively working to address it. Essentially if you import ProfileXML with custom cryptography settings and the native protocol type set to “automatic”, the custom cryptography settings get imported incorrectly. This will result in SSTP working but IKEv2 failing with policy mismatch errors. The only workaround at this time is to set the native protocol type to “IKEv2”, and then change to automatic later by updating the entry in rasphone.pbk using PowerShell, group policy preferences, or something else.
Chris
/ September 12, 2019Just a quick question regarding IKEv2 and SSTP Fallback with a LoadBalancer like Netscaler in Front.
I guess then I need to Offload SSL on the Netscaler because I need to configure the VIP to listen to UDP 500 / 4500 (IKEv2) and TCP 443 (HTTPS). I cannot use SSL Bridge and IKE on the same VIP.
Is this correct?
Richard M. Hicks
/ September 12, 2019I’m not aware of any limitations like that. I’ve configured other load balancers using multiple ports on the same VIP without issue (Kemp, F5, etc.). Expect the same would hold true for NetScaler too. Shouldn’t have to offload TLS in that scenario.
Dietmar
/ September 23, 2019Today I created a workaround for 3 problems we came across: multi-user support of AlwaysOn VPN user tunnel (auto-trigger), VPN strategy set to 14 and the missing IPSec settings in the rasphone.pbk (which is a Microsoft confirmed behavior if the native protocol type is set to Automatic. You can save the PowerShell-Script (the one you use for ConfigMgr deployment) to a folder which the user cannot modify. Then create a schedulded task, run it every time a user logs on, and in SYSTEM context. With this config every user who logs on gets the profile every time installed (very handy, stable and fast). That way the RasMan service is proper configured to auto-trigger the connection, it’s seemless to the users and… it works! Additionally I added the following lines to the script
#######################################
# Workaround for missing VPN settings
#######################################
$Benutzer = ($objuser.value).ToString()
$Benutzer = ($Benutzer.Split(“\”))[1]
(Get-Content -Path “C:\Users\$Benutzer\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk”) | `
ForEach-Object {$_ -replace ‘VPNStrategy=.*’, ‘VPNStrategy=14’} | `
ForEach-Object {$_ -replace ‘NumCustomPolicy=.*’, “NumCustomPolicy=1 `r`nCustomIPSecPolicies=020000000200000003000000030000000200000003000000”} | `
Set-Content -Path “C:\Users\$Benutzer\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk” -Force
Restart-Service RasMan -Force
These lines correct the VPNStrategy to 14 every time a user logs on, corrects NumCustomPolicy to 1 and add a line CustomIPSecPolicies with the IPSec settings.
This works like a charm for us. Now we are ready to deploy AlwaysOn VPN.
Cheers, Dietmar
Richard M. Hicks
/ October 7, 2019Awesome. Thanks for sharing! 🙂
Daniel
/ October 28, 2019I do not know if anyone had the same experiences, but we had different problems with Always-On-VPN (such as trusted network detection sometimes didn’t work, random disconnects during the day or an unstable connection) but since we’re not using VPNStrategy 14 anymore, the problems are all gone so far. With VPNStrategy 7 everything works much better! Maybe Microsoft is not supporting VPNStrategy 14 anymore and is doing bugfixes only with the “GUI-visible” connection modes? However, just wanted to share this experience if somebody has similar issues. We used a scheduled task to check the setting in the rasphone file.
Greetz Daniel
Richard M. Hicks
/ October 28, 2019Thanks for the feedback! No question Always On VPN seems to be more reliable when you choose a single transport. Hoping that Microsoft addresses the persistency issue with the VpnStrategy setting in the future for sure.
Tom Klaver
/ December 10, 2019One small tip when you create a task by SCCM in Task Schedule to run the Always On VPN Profile script during a user logon to update VPNStrategy setting. Don’t forget to add the option $Settings=New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries. Otherwise the task is not executed when the machine is on battery 🙂
$Location=$PSScriptRoot + ‘\VPN_Profile.ps1’
if (! (test-path -Path C:\AlwaysOnVPN) -eq ‘False’)
{
New-Item -Path C:\ -Name AlwaysOnVPN -ItemType Directory -Force
}
Copy-Item -Path $Location -Destination C:\AlwaysOnVPN -Force
$Trigger=New-ScheduledTaskTrigger -AtLogOn
$User= “NT AUTHORITY\SYSTEM” # Specify the account to run the script
$Settings=New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries
$Action= New-ScheduledTaskAction -Execute “PowerShell.exe” -Argument “-ExecutionPolicy ByPass -NoProfile -File C:\AlwaysOnVPN\VPN_Profile.ps1” #Specify what program to run and with its parameters
Register-ScheduledTask -TaskName “Always On VPN Configuration” -Trigger $Trigger -User $User -Action $Action -Settings $Settings –Force # Specify the name of the task
Robin
/ February 14, 2020Hello Richard,
Any news on this, do we still have to change the VpnStrategy value all the time, or can we have IKEv2 as default?
Richard M. Hicks
/ February 14, 2020The fix is supposed to be included in 1903/1909 but it hasn’t worked in my testing. Once I get it sorted out I’ll definitely post something.
Simon Erichstrup
/ February 25, 2020Hi Richard,
First off, thank you for all your great articles on this subject.
I am running Device Tunnels with ikev2 and continously run into ISPs medling with the UDP packets rendering my VPN solution disfunctional.
I read your articel and enabled SSTP but clients now simply get a prompt for username and password.
After some digging I realize device tunneling and SSTP does not work together 😦
What are my options?
User Tunnelling is of course a way to go, but I would rather not go that way.
Can I alter my setup in some way to make the device certs usable as authentication through SSTP through a tweak, fix or revert back to a Dial-In VPN perhaps?
Any insights would be helpfull.
Richard M. Hicks
/ February 26, 2020Indeed, the device tunnel uses IKEv2 exclusively. There is not support on the device tunnel for the SSTP protocol today, unfortunately. I’m not aware of any native options for establishing a device tunnel using SSTP. However, there may be other ways to hack something together. It’s not something I’ve tried, but it would be an interesting experiment for sure. I’ll add it to my list of things to investigate and let you know what I find. 🙂
Simon Erichstrup
/ February 26, 2020Hi again,
Thanks for your respons.
I hope to find some time to play with this as well
Regards Simon
Maurice
/ March 30, 2020Hi Richard,
Would it be possible to setup an IKEv2 Device Tunnel and fall back to an SSTP user tunnel if IKEv2 is failing?
Richard M. Hicks
/ March 30, 2020No. The device tunnel requires IKEv2 and uses it exclusively. There’s currently no support for SSTP on the device tunnel at the moment.