Always On VPN IKEv2 and SSTP Fallback

Always On VPN IKEv2 and SSTP FallbackA 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.

Always On VPN IKEv2 and SSTP Fallback

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.

Always On VPN IKEv2 and SSTP Fallback

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

Leave a comment

20 Comments

  1. Colin

     /  January 15, 2019

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

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

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

    Reply
  3. Colin Pazdzior

     /  February 12, 2019

    Just 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
    }

    —————————————————————————————-

    Reply
  4. Shane

     /  March 15, 2019

    I 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

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

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

      Reply
  6. Luke Flack

     /  August 5, 2019

    Hi 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

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

      Reply
  7. Chris

     /  September 12, 2019

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

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

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

    Reply
  9. Daniel

     /  October 28, 2019

    I 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

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

      Reply
  1. Always On VPN SSTP Load Balancing and SSL Offload | Richard M. Hicks Consulting, Inc.
  2. Always On VPN IKEv2 Features and Limitations | Richard M. Hicks Consulting, Inc.

Leave a Reply to David Kafrissen Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: