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 can be done using a scheduled task and my Update-Rasphone.ps1 script from GitHub.
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! 🙂
Jo T
/ September 25, 2020Could you expand more on how you are doing this please? (sorry i know your comment is a year old!)
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! 🙂
Simon Erichstrup
/ April 8, 2020Yes, we tried this also. However, we see that ikev2 connections get established and then fail to work properly due to UDP packets being blocked or meddled with by some ISPs and/or home routers – so SSTP fallback never happens.
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.
James Hawksworth
/ May 28, 2020This still appears to be the case on Win10 1909, just trying to get SSTP fallback to work and IKEv2 keeps failing, where it works fine by itself.
Your workaround still works at least, so many thanks!
Richard M. Hicks
/ May 29, 2020Good to know!
Thomas Gusset
/ July 7, 2021Hi
we found a way to use strong cyber suite with ‘automatic’ NativeProtocolType:
setting a registriy key on client side:
HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
Name = NegotiateDH2048_AES256, Type = DWORD, Value = 2
forces the client to use DH group 14 and AES256
On the server side:
Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA196 -CipherTransformConstants AES256 -DHGroup Group14 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000
This ends up in a crypto suite SHA256, AES256 and DH group 14.
It works well for a certain time (or amount of data), but then the tunnel no longer work. Windows still shows VPN as connected. On the network trace we see only ISAKMP packets in both directions:
client -> server: INFORMATINAL MID=14 Initiator request
server -> client: INFORMATINAL MID=14 Initiator response
no more ESP packets from now on
client -> server: CREATE_CHILD_SA MID=15 Initiator request
server -> client: CREATE_CHILD_SA MID=15 Initiator response
client -> server: CREATE_CHILD_SA MID=16 Initiator request
server -> client: CREATE_CHILD_SA MID=16 Initiator response
… and so on (MID increasing by 1 every time)
We can manually disconnect the VPN connection. After that it connects again automatically and everything works fine for a while.
Interesting detail: just before the first ISAKMP packet we see a UDP packet with ‘BAD UDP LENGTH’ from the client to the server but with different port numbers (not 4500).
Any idea what’s wrong here?
Thanks, Thomas
Richard M. Hicks
/ July 7, 2021No idea, to be honest. There was a recent update to Windows Server 2019 that addressed a known issue with IKEv2 VPN in RRAS. I’d suggest applying the latest updates and testing again. 🙂
https://directaccess.richardhicks.com/2021/06/22/always-on-vpn-updates-for-rras-and-ikev2/
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.
Johan
/ December 10, 2020Hey Richard! Have you been able to confirm if anything has changed with 1909?
Richard M. Hicks
/ December 17, 2020I’ve been told this has been fixed, I just haven’t had time to test it. Watch for a blog post early next year on this. 🙂
Schreibkomitee
/ April 30, 2021It seems they have “fixed” the issue by fixing the documentation. This now clearly says that “Automatic” means SSTP before IKEv2.
Richard M. Hicks
/ May 3, 2021🙂
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.
Shane
/ April 8, 2020I understand that SSTP is not supported on a device tunnel. Can you fall back to SSTP user tunnel if the primary connection is a configured with an IKEv2 Device tunnel? Is it not possible to setup a device tunnel and a user tunnel?
Richard M. Hicks
/ April 8, 2020You can definitely set up both device tunnel and user tunnel, that’s quite common. It wouldn’t failover, necessarily. They are two independent connections. If you configure the user tunnel with SSTP, it will always connect regardless if device tunnel was successful or not.
Simon Erichstrup
/ April 8, 2020Yeah, this is the biggest caveat for me as well. We have implemented User Certs as a “back up” solution for this reason (ikev2 udp traffic being blocked by several ISPs and home routers/firewalls)
However, we need the device tunnelling to ensure pre-logon connectivity and you cannot accomplish this with User tunnelling (afaik).
I hope MS would consider an option with device tunnelling over SSTP.
Richard M. Hicks
/ April 8, 2020No doubt many have asked for this feature. 🙂
Aftaab
/ April 16, 2020Hi Richard, great articles as usual. So you pretty much hijacked all top results in Google keywords for Always On VPN 🙂 .
Do you know if there are any hard limits for SSTP number of ports on RRAS when you set it up in Windows Server 2016/2019? Default for SSTP and others seem to be 128 for most protocols but i can’t see any good documentation for guidance. We have IKEv2 as 1024 ports and SSTP as 128 ports with Automatic fallback but looking to bump those numbers of ports just in case but unsure of impact. Our userbase is circa 500 and we have forced tunnelling so users drop their device tunnel when connecting to user tunnel and with SSTP fallback.
Richard M. Hicks
/ April 17, 2020I would use the word “achieved” instead of “hijacked”. 😉 To answer your question, no, there’s no hard limit on the number of VPN ports you can configure in RRAS (that I’m aware of). I’ve set this as high as 8,000 before without issue. In fact, I just tested now and set both to 12,000. I can’t imagine anyone need more ports than that though. 🙂
Matt
/ June 25, 2020If the a device tunnel is urgently required for some reason, (such as for a user password reset) and IKEv2 connectivity is not available on the local wifi, do you know if the major cellular tethering hotspots in the US such as AT&T, Verizon and T-Mobile support IKEv2 tunneling?
Starbucks wifi?
Richard M. Hicks
/ June 29, 2020Very few ISPs block IKEv2. It’s mostly blocked (or more accurately, not allowed by default) by hotels and corporate guest networks. Coffee shops seem to be reliably open in my experience.
Jeremy Noone
/ July 6, 2020Hey Richard,
Thanks for the articles. I keep thinking I’ve got our VPN ready for production but run into another issue that you’ve seemed to have covered, documented, and shared.
You mentioned security of SSTP vs IKEv2. Aside from an argument for closed vs open source, and SSL 3.0 potential vulnerabilities, I can’t find an articulate or factual argument against it. Do you have any other info?
Richard M. Hicks
/ July 7, 2020There are advantages and disadvantages for using either IKEv2 or SSTP. I feel personally that SSTP is acceptable for most deployments and provides more than enough security when properly configured and optimized. Of course IKEv2 provides the best security options, but has it’s own limitations which I’ve written about here: https://directaccess.richardhicks.com/2019/04/15/always-on-vpn-ikev2-features-and-limitations/.
John
/ July 20, 2020Hi Richard,
We are currently using VPN strategy 14 , however have seen some issues, with connections.
As alluded to above in the comments is 14 still supported?
The MS docs don’t seem to reference 5, 6 , 8 and 14:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rrasm/7574fc0f-3e82-4b69-a4c3-43b588fad4d7?redirectedfrom=MSDN
Thanks
Richard M. Hicks
/ July 21, 2020Yes, VPN strategy 14 is indeed supported. Sadly, the Microsoft documentation is terribly outdated and doesn’t include this information. :/
victor bassey
/ September 29, 2020Is it possible to have a configuration as follows:
Device Tunnel – IKEv2
User Tunnel – SSTP
Both Tunnel uses split tunneling
I currently have a client who has deployed device tunnel (only) with IKev2 but a considerable number of users keep getting issues with their home routers. I found with some, enabling UDP port clamping on their home router sometimes help with stabilizing the connectivity, but others still have issues.
I was thinking of implementing a user tunnel (SSTP) on top of the existing device tunnel if this will help minimize the connectivity issues experienced with just the device IKEv2 based tunnel.
Richard M. Hicks
/ September 30, 2020Absolutely. This is the most common deployment scenario in fact. 🙂
victor bassey
/ September 30, 2020Great! Thanks Richard for the pointer.
Benj
/ October 28, 2020Hi Richard, thanks for you brilliant articles on VPN/DirectAccess.
Just a heads up:
After communications with Premier Support I was made aware of that you can add a registry key to disable Windows updating the VPNstrategy:
reg add HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters /v VPNStrategyUsageDisabled /t REG_DWORD /d 1 /f
OS also needs to be updated past these for the regkey to work:
RS4 (v1803) fixed in https://support.microsoft.com/en-us/help/4534308/windows-10-update-kb4534308
RS5 (v1809) fixed in https://support.microsoft.com/en-us/help/4534321/windows-10-update-kb4534321
19H1 (v1903) fixed in https://support.microsoft.com/en-us/help/4517211/windows-10-update-kb4517211
Richard M. Hicks
/ October 28, 2020Thanks for the update! I was told by Microsoft support quite a while ago that this was fixed, but when I tested it still didn’t work. :/ Have you tested and confirmed operation?
Benj
/ October 29, 2020This is confirmed working in 1809 with latest october patches.<
Support guy mentioned 1909 and later would not need any patch for the regkey to work.
Richard M. Hicks
/ November 1, 2020Good to know!
Sean
/ November 9, 2020I am finding that with this setup though if deployed via intune the next check in it blows out any modifications to VPNStrategy and as a bonus it also disconnects as well :/ If I deploy the profile manually then this key prevents windows from overriding it arbitrarily. I have opened a case to push this as the vpnv2 csp and this particular option are woefully inadequate. I am also pushing the security angle as a mitm could block your sstp and ike attempts, and then your throwing trivially reversible protocols in the mix (Automatic = SSTP, IKEv2, PPTP and then L2TP, as per https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp) with potential mfa type tokens accessible if using the conditional access extensions.
Richard M. Hicks
/ November 9, 2020Thanks for the heads-up! Not sure I ever tested this using Intune provisioning. Good to know it works differently than SCCM/MEMCM deployments. No doubt not being able to specify the exact protocol you want to use, and in which order, is limiting. And with no option to choose SSTP explicitly, using “Automatic” does present a problem by allowing PPTP to be accepted. :/
That said, Microsoft has supposedly fixed this with a registry entry that prevents overwriting the VpnStrategy setting if the administrator changes it. However, I don’t know if this solves your problem with Intune overwriting the entire profile and wiping out that setting. I’ll do some testing and see what I can learn.
Sean
/ November 12, 2020There is a lot broken it seems. I can’t seem to specify the element and have it apply when using nativeprotocoltype automatic. Intune it doesn’t deploy at all (if I remember correctly during our deployment back in April it just errors), via the WMI bridge it will apply but if you look at the IPSecCustomPolicy its blank. I can then patch up the crypto with powershell and it works as intended. I am at a loss, every time I want to optimize Always On I have to give up to keep my sanity 😛 Seems if I had done a full powershell deployment I could have hit all objectives…
Richard M. Hicks
/ November 17, 2020I feel your pain. 🙂
Sean
/ November 12, 2020Also that Microsoft openspec doc about VPNStrategy changed quite recently and doesn’t show half the operable options anymore. The undocumented options still work, just seems that they are being scrubbed 😛
Richard M. Hicks
/ November 17, 2020Very strange indeed!
Justin
/ November 4, 2020Hi Richard, thanks for another great post! Is it possible to set SSTP only in the script without having to use the Automatic tag? I don’t want to use IkeV2 at all as it has been blocked by too many users’ home routers.
Richard M. Hicks
/ November 6, 2020No, the CSP does not include SSTP as a dedicated protocol type unfortunately. The workaround for this is to push out the profile as Automatic, then update VpnStrategy to 6 after deployment using my PowerShell script: https://github.com/richardhicks/aovpn/blob/master/Update-Rasphone.ps1.
Justin
/ November 10, 2020Awesome thank you 🙂
Marko Z
/ December 10, 2020Hello,
can you please write the latest and the best solution for all the problems mentioned in this comments? I’m a bit confused 🙂 Also, how should I configure the scheduled task (which command to run and which arguments) and where is the best place to put the script?
Also, what is the best solution to deploy AlwaysOn VPN profile (with the generated ps1 script). Group Policy, PDQ? Any other way? Under which user deploy script should be run?
Thank you!
Richard M. Hicks
/ December 17, 2020Microsoft has addressed this issue and I’ll be publishing something on it soon. As for Always On VPN profile deployment, the best option is to use Intune. Outside of that, you can use whatever you like (SCCM, PDQ, Active Directory and group policy, etc.).
kjn
/ December 12, 2020What happens if the user tunnel is configured to multiple user profiles at the same machine?
Richard M. Hicks
/ December 17, 2020You can deploy an Always On VPN profile to more than one user on the same machine, but only ONE user (the last one configured) will automatically start. No workaround if you are using Intune, unfortunately. If you are using SCCM or something else, use my PowerShell script with the -AllUserConnection switch and deploy the profile for all users. Here’s a link to my script: https://github.com/richardhicks/aovpn/blob/master/New-AovpnConnection.ps1.
kjn
/ December 21, 2020Thanks! Is “allusersconnection” different thing than device tunnel?
Richard M. Hicks
/ December 22, 2020The -AllUserConnection parameter on my script creates the user tunnel in the context of “all users”, making it available for anyone who logs on to the device. It is still a user tunnel, however. A device tunnel is technically also deployed to all users, but it uses a different OMA URI.
Marko Zaletel
/ December 29, 2020Hello,
I have found another problem. When client connects using Always On VPN, DNS registration happens but the problem is that also user’s local private address gets registered in company DNS, not only Always ON adapter. How can I solve this?
Thank you!
Richard M. Hicks
/ January 6, 2021Try setting the following registry key and let me know if that helps.
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 0
Myth
/ February 17, 2021Hi Richard,
It looks like VPNStrategy 14 or 8 no longer works. Would you be able to confirm you’re seeing the same? Automatic mode is set in ProfileXML and VPNStrategy seems to get overridden with 6 (SSTP mode)
Richard M. Hicks
/ February 24, 2021When you select Automatic for the NativeProtocolType for an Always On VPN connection, indeed it will prefer SSTP over IKEv2 (VpnStrategy = 6). You should be able to override that in rasphone.pbk after the profile is created though. Are you changing it to 8 or 14 then and it still prefers SSTP?
Ian McNamara
/ May 4, 2021I believe this issue has been fixed, at least on my 21H1 Windows 10 Pro devices. I’m testing a new deployment and after modifying Rasphone.pbk (VpnStrategy = 14) connections seem to always default to trying IKEv2 before SSTP .
My test process was to deny UDP 500/4500 traffic to RRAS and AOVPN connects on an SSTP port. After successful SSTP connection, VpnStrategy in Rasphone.pbk remains set to 14. Subsequent tests after allowing UDP 500/4500 in the firewall automatically connect to IKEv2.
No matter which port the VPN is connected to, the Network Connections always shows WAN Miniport (IKEv2). To verify which port type the connection has been made on, I either have to look at the RRAS itself, or view the connection entries in the client event viewer, which show an attempt on IKEv2 and subsequent connection on SSTP, or just a successful connection on IKEv2.
I’ll continue testing real world scenarios to verify the behavior outlined above survives reboots an different public networks, but just wanted to throw this info out there in case anyone found it helpful
Now, if only Microsoft would support automatic connections to device tunnels on 10 Pro operating systems.
Richard M. Hicks
/ May 5, 2021Indeed, Microsoft did change this behavior a while back. Typically you have to set the following registry key.
HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\VPNStrategyUsageDisabled DWORD=1
That will tell Windows not to dynamically update the VpnStrategy value in rasphone.pbk. Did you make this registry change? Or was this the default behavior you observed?
Ian McNamara
/ May 5, 2021I did not make the registry change you describe and the registry key “VPNStrategyUsageDisabled” does not exist on my system.
Richard M. Hicks
/ May 14, 2021If you have Windows 10 2004 or later you can add that key. It may not be present by default.
Andrew Brookes
/ May 20, 2021I have a working RRAS server using IKEv2 for Always on VPN connections.
I want to provide SSTP on this same server. I have applied a public SSL certificate (followed your guide Always On VPN ECDSA SSL Certificate Request for SSTP | Richard M. Hicks Consulting, Inc. (richardhicks.com) ) to the RRAS server.
I selected this certificate in SSL Certificate Binding list on the Security tab of the RRAS server.
I have changed the connection on my test device to use SSTP instead of IKEv2
The test device connects okay when using IKEv2 but when I change the connection to use SSTP, I get the below error
“An existing connection was forcibly closed by the remote host.”
In event viewer, I get the below
CoId={6A025206-A8FA-485E-8D88-4FEB0BBFD0CE}:The initial Secure Socket Tunneling Protocol request could not be successfully sent to the server. This can be due to network connectivity issues or certificate (trust) issues. The detailed error message is provided below. Correct the problem and try again.
An existing connection was forcibly closed by the remote host.
I may well have missing out some configuration but I’m at a loss to know what.
Do you have any advice please Richard?
Many thanks
Andrew Brookes
Richard M. Hicks
/ May 20, 2021Sounds like you have the certificate configured correctly. It could have something to do with trust or the certificate chain. Did you get all of the certificates in the path installed in their respective stores on the VPN server? If you reach out to me directly I’m happy to have a quick look for you.
Andrew Brookes
/ May 21, 2021Hi Richard,
Thanks for your speedy response The problem has been fixed. Our firewall was allowing 443 so I dismissed this as a problem but I’ve since discussed the problem with our network engineer and a change was required to allow it via an application definition. Its now working as expected.
Thank you
Richard M. Hicks
/ May 24, 2021Awesome. Glad you got it sorted out! 🙂
Greg Fisher
/ June 5, 2021Thanks for all the great help on this site – it’s been an amazing help on my journey to deploy AOVPN. I’ve got almost everything working as I want it, but cannot figure out one thing.
It seems that my connections are not respecting the pbk file – specifically the InterfaceMetric setting and the VPNStrategy (the only two settings I’m trying to meddle with). No matter what I change those to, the connection ignores it.
I have already configured IKEv2 and that’s working fine. I’ve also configured SSTP and am trying to use VPNStrategy 14 for SSTP fallback. The machine never tries to connect using SSTP – packet traces show no attempt on 443 after blocking ports 500/4500. The connection will just fail with an 809.
If I create a new VPN Profile and set it up for SSTP, it connects just fine. I am not understanding why or how it’s not respecting the settings in the pbk file. This worked in my lab just fine. It just wont work in production.
This is an all users profile set for always on.
Any help would be greatly appreciated!
Richard M. Hicks
/ June 7, 2021That’s unusual. Are you certain you are editing the correct pbk file? For AllUserConnections it is located in C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk.
Greg Fisher
/ June 7, 2021Thanks for the reply – Yes. I am modifying the all user pbk. What I have found is that if I do set-vpnconnection -tunneltype sstp it will connect with sstp, same if I set it to Ikev2. If I set it to automatic, it always picks IKE, no matter what I set the VPN strategy to, even if the ports are blocked on my firewall. When the IKE ports are blocked, it just fails to connect. It’s very strange.
In the end I think I will just stick with SSTP hard coded so I don’t have to deal with the inevitability that someone’s router will block the IKE ports. Just less to troubleshoot down the line.
I found out recently that my company engaged you to set up our DirectAccess back in 2014/2015. Still using it to this day (not for long though, I hope!)
Richard M. Hicks
/ June 7, 2021Can you tell me if the following registry key is present on your test devices? If it is, what is the value set to?
HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\VPNStrategyUsageDisabled
Glad to hear DirectAccess is still doing well for you. Hopefully, your migration to Always On VPN goes well too! And yes, not a bad idea to just use SSTP, IMO. It just works everywhere and eliminates the pain IKEv2 often causes. 🙂
Greg Fisher
/ June 8, 2021Ahh, yes – I had that registry key set to 1. I must have done that during previous troubleshooting. After setting it to zero, I still found it wasn’t acting like I wanted but ended up figuring out that if the VPN interface is set up for ‘WAN Miniport (SSTP)’, no matter what you set the strategy to, it will always use SSTP. Using set-vpnconnection -tunneltype ikev2 sets the interface back to ‘WAN Miniport (IKEv2)’. Then using set-vpnconnection -tunneltype automatic coupled with update-rasphone -setpreferredprotocol IKEv2 seems to do the trick.
I’m happy that there’s a reasonable explanation for it and that I can repeat the problem but I will likely still just be sticking with SSTP for the reasons you and everyone else speak about here.
Thanks for putting me down the right road with that reg key!
Richard M. Hicks
/ June 8, 2021Thanks for the update, Greg. Glad you got it sorted out. Let me know if there’s anything else you need!
Thomas
/ June 17, 2021Hi Richard
You wrote that SSTP can be used if it is configured securely. You also wrote a good tutorial on how to securely configure IKEv2. What does a secure configuration for SSTP look like? And how can the security parameters of an SSTP connection be checked? I looked at the connection setup with Wireshark, but you can’t see the negotiated parameters there (Wireshark reports ‘ignored Unknown Records’ where the server hello should be).
Richard M. Hicks
/ June 17, 2021Good question! Indeed, it appears I never posted anything regarding SSTP security configuration. I will do that soon, for sure. Look for something early next week, in fact. 🙂
Darren Smith
/ August 19, 2021Hi Richard, Thanks for this, really helped to get my head around some of the quirks we have been seeing. We have had implemented a device tunnel purely IKEv2 and a User tunnel set to Auto. We have the issue where IKEv2 has failed, now working, and ALL users have fallen back to SSTP. SCCM is Device centric and a Task Schedule cant be run as each logged in user.. trying to find a way to run the script as the user to update VPNStrategy from 6 to 14. Also noticed the registry MS released to stop VPNStategy from flopping so will do that via Group Policy.
Trying to avoid having the script kicked off via the login script.
Do you have any ideas?
Richard M. Hicks
/ August 24, 2021If you are using Microsoft Intune/Microsoft Endpoint Manager, Proactive Remediations is your best bet. Otherwise, you might consider using Active Directory group policy preferences to update the file. Details here:
https://www.grouppolicy.biz/2012/02/how-to-use-group-policy-to-configured-ini-files/
Tom Klaver
/ August 24, 2021Sounds familiar Proactive Remedation 🙂
Richard M. Hicks
/ August 25, 2021It should! Thanks again for sharing that with me. I’ve already used it a few times to address issues with Always On VPN when deploying with Microsoft Endpoint Manager/Intune. I’ll do a write-up on it soon, hopefully.
Fernando
/ October 19, 2021Hi Richard, for security reasons we’ve had to remove our always on device tunnel client config and rely on a manual SSTP connection, cert based authentication with added MFA at connection. Here’s the problem, if the wi-fi drops momentarily (say 5 seconds) the SSTP connection is also dropped and user needs to connect again. This happens infrequently but it’s causing user base anger. Is there a way to change the sensitivity of the SSTP connection so that it’s not as sensitive to connection issues so users don’t have to manually reconnect? The Device Tunnel usually automatically reconnected.
Richard M. Hicks
/ October 20, 2021Unfortunately, no. IKEv2 handles this better as it supports the Mobility option, but SSTP doesn’t have an equivalent. You could always try using IKEv2 for user tunnel connections to see if that helps.
Dan
/ December 8, 2021I am seeing default “Automatic” deployed via intune to set vpnstrategy to 8 (ike first)…
Is this a known change? As if we want SSTP doesn’t seem to be a specific option type in intune for it, like there is for IKE?
Richard M. Hicks
/ December 10, 2021I don’t think it is a ‘change’, but rather it is expected behavior. When an Always On VPN profile is first provisioned to an endpoint the VpnStrategy is set to ‘0’. Unfortunately, the VpnStrategy settings documentation isn’t up to date, but in the past ‘0’ meant trying a variety of different protocols in order. It used to start with PPTP then try L2TP, but that’s changed. From observation, I can tell you that in Windows 10/11 IKEv2 is tried first, and if that fails it tries SSTP. Once a successful connection is made, VpnStrategy is updated to use whatever protocol used for the last successful attempt.