Introduction

This is another post, I have wanted to do for some time now. Always On VPN is not something new, but many organizations are moving away from Direct Access, and Always On VPN seems to be the preferred and logical choice for many – including ours.

Also, I don’t think that the current outbreak of COVID-19 has missed anyone’s attention, which is why working from home and remote via VPN has become highly relevant these days.

This post will not go into details on the infrastructure required in order to setup Always On VPN (Remote Access Server, Network Policy Server, PKI etc.), but rather explain the configurations made on the client with Microsoft Intune and Configuration Manager. I will also elaborate on my experiences, again from the perspective of a production environment.

Finally, a big shout out to Michael Mardahl for always being a tremendous help. Go follow this dude. He’s amazing at what he does. 🙂

Microsoft Intune

Configuring the Always On VPN client on Windows 10 can be done i numerous ways. Microsoft Intune came out as the obvious choice for us, as this is being done with a GUI (and we co-manage our devices with Resource access policies being managed in the cloud).

• Note: The alternatives are messing around with Powershell and deploying a script, which in return creates the VPN profile for you. This is the more difficult choice, but can be necessary, if you need a configuration which is not possible through Intune.

A quick peek at the overall settings of the Always On VPN configuration in Microsoft Intune down below. I will elaborate on each where it makes sense.

Base VPN

The Base VPN settings are configured like below:

• Connection name: Always On VPN
  • This is just the display name of the connection.
• Servers: aovpn.imab.dk
  • This is the entry point. This is the IP address or FQDN where the VPN client tries to establish a connection to.

• Connection type: Automatic
  • This is the protocol being used and the VPN strategy of the connection

Attention: This particular part of the configuration is especially interesting, as the recommended protocol is IKEv2.

However, selecting Automatic will result in a VPN strategy, where the Windows 10 client is attempting to establish a VPN connection using SSTP first and then IKEv2.

• Note: You can verify and see the VPN strategy by browsing the Application event log as shown below:

What most are trying to accomplish here though, is to use IKEv2 first and then SSTP as the fallback option.

Note: Using IKEv2 is not without obstacles, and in my experience, you cannot solely rely on IKEv2 as the primary protocol. IKEv2 is not permitted everywhere, why you must have a fallback option like SSTP in place (which practically translates into HTTPS).

In order to achieve the desired VPN strategy, you will have to do some modifying of the rasphone.pbk file (AppData\Roaming\Microsoft\Network\Connections\Pbk).

Powershell

Over on my GitHub page at https://github.com/imabdk, as well as down below, you will find a script which is capable of modifying the local rasphone.pbk file and the VPN strategy.

The script accepts and requires the parameter: -strategyNumber, and the input is validated to only accept any of the numbers: 5 – 6 – 7 – 8 – 14

The numbers translates as following:

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

<#
.SYNOPSIS
    This script reads the current AlwaysOn VPN strategy and changes it to the set value if required.
   
.DESCRIPTION
    This script reads the current AlwaysOn VPN strategy and changes it to the set value if required.
    This is to cater for situation where Windows 10 automatically changes the VPN strategy to something undesirable.

    Intune currently only supports setting the connection type to either IKEv2, L2TP, PPT or automatic. 
    If you want a different strategy, you will need to use a script like this.

.PARAMETER strategyNumber
    Specify the desired VPN strategy by number. The options are:

    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

.NOTES
    Filename: Set-VPNStrategy.ps1
    Version: 1.0
    Author: Martin Bengtsson
    Blog: www.imab.dk
    Twitter: @mwbengtsson
    
#> 

[cmdletbinding()]
param(
    [Parameter(Mandatory=$true)]
    [ValidateSet("5","6","7","8","14")]
    [string]$strategyNumber
)

function Get-VPNStrategy() {
    
    switch ($strategyNumber) {
        5 {$strategyDesc = "Only SSTP is attempted"}
        6 {$strategyDesc = "SSTP is attempted first"}
        7 {$strategyDesc = "Only IKEv2 is attempted"}
        8 {$strategyDesc = "IKEv2 is attempted first"}
        14 {$strategyDesc = "IKEv2 is attempted followed by SSTP"}
    }
    
    $rasphonePath = "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk"

    if (Test-Path $rasphonePath) {
        try {
            $currentStrategy = (Get-Content $rasphonePath) -like "VpnStrategy=*"
        }
        catch { }
    }
    else {
        Write-Verbose -Verbose -Message "The path for rasphone.pbk does not exist"
    }
    Write-Output $currentStrategy
}

function Set-VPNStrategy() {

    switch ($strategyNumber) {
        5 {$strategyDesc = "Only SSTP is attempted"}
        6 {$strategyDesc = "SSTP is attempted first"}
        7 {$strategyDesc = "Only IKEv2 is attempted"}
        8 {$strategyDesc = "IKEv2 is attempted first"}
        14 {$strategyDesc = "IKEv2 is attempted followed by SSTP"}
    }

    $rasphonePath = "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk"
    $currentStrategy = Get-VPNStrategy
    $newStrategy = "VpnStrategy=$strategyNumber"

    if ($currentStrategy) {
        if ($currentStrategy -ne $newStrategy) {
            try {
                (Get-Content $rasphonePath).Replace($currentStrategy,$newStrategy) | Set-Content $rasphonePath
                Write-Verbose -Verbose -Message "VPN strategy is now configured to: $newStrategy"
                Write-Verbose -Verbose -Message "The VPN strategy description is: $strategyDesc"
            }
            catch { 
                Write-Verbose -Verbose -Message "Failed to apply new VPN strategy"
            }
        }
        elseif ($currentStrategy -eq $newStrategy) {

            Write-Verbose -Verbose -Message "VPN strategy is already properly configured to: $currentStrategy"
            Write-Verbose -Verbose -Message "The VPN strategy description is: $strategyDesc"
        }
    }
}

try {
    Write-Verbose -Verbose -Message "Script is running"
    Set-VPNStrategy
}

catch {
    Write-Verbose -Verbose -Message "Something went wrong during running of the script"
}

finally {
    Write-Verbose -Verbose -Message "Script is done running"
}

Configuration Manager

Above Powershell script is something you can run on a schedule, and therefore always make sure the VPN strategy on your devices is a given value.

• powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File .\Set-VPNStrategy.ps1 -strategyNumber 14
• powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File .\Set-VPNStrategy.ps1 -strategyNumber 8
• powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File .\Set-VPNStrategy.ps1 -strategyNumber 7
• powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File .\Set-VPNStrategy.ps1 -strategyNumber 6
• powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File .\Set-VPNStrategy.ps1 -strategyNumber 5

Below is a snippet of the package in my environment, which has a program for each of the available VPN strategies:

Below another example from the Software Center in my environment, illustrating that this is something you are able to deploy to whatever device that needs it.

A real world scenario might be, that some devices might need a configuration of Always On VPN, that currently isn’t supported by the GUI in Microsoft Intune.

Intune Continued

Base VPN

The authentication lies within PEAP (Protected Extensible Authentication Protocol), and the configuration needed here is based on some exported XML.

This piece of XML basically comes from the VPN connection, which initially was made manually and tested as working.

Below the example of my VPN connection. This is the one created automatically by Intune once the configuration profile has been assigned, but the profile created manually will obviously be similar.

Note: Create the piece of XML needed for the configuration profile with below 2 lines of Powershell

$Vpn = Get-VpnConnection -Name 'Always On VPN'
$Xml = $Vpn.EapConfigXmlStream.InnerXml | Out-File .\eap.xml -Encoding ASCII

DNS Settings

DNS! Boy this one initially caused me some headaches.

My domain imab.dk exists both externally and internally, and while aovpn.imab.dk only resolves externally, that can cause some connection issues if aovpn.imab.dk isn’t excluded from the NRPT rules.

So if you include your entire domain like I do, and tell the VPN client to resolve DNS lookups internally, make sure you exclude the FQDN for the Always On connection by not configuring any DNS servers. This will make sure that aovpn.imab.dk is always resolved externally. This should make sure that you don’t face the issue I did, where aovpn.imab.dk was being looked up internally, which of course caused the connection to fail.

Split Tunneling

This part is pretty straight forward. You configure the various destination prefixes which you want to have routed through your VPN server. That’s usually all of your internal LAN, or at least the networks you want your VPN clients to be able to reach from the Always On VPN connection.

I’m mentioning this part regardless, as in a split tunneling scenario, there might be some very specific websites which has access granted through IP validation. In other words, these type of websites, you will want to browse as coming from inside of your corporate network. The only way I could get this to work properly, was to simply fetch the said websites IP and configure it with a prefix of 32.

Note: I know IP addresses are subject to change, but some providers are actually able to provide you with an IP address which is considered static.

Note: Further to above configuration, depending on the setup on your VPN server, you might need additional configuration in terms of adding permanent routes using ADD ROUTE, sending the traffic onwards to a gateway which has Internet access. I’m going to spare you on the technical details on this part for now. 🙂

Other gotchas?

For now I’ve only stumbled across one other oddity, which again is related to how DNS does it magic.

This is not directly related to each device or the configuration hereof, but rather the ISP or the equipment providing the Internet connection. I don’t have comprehensive details here, but on a small percentage of our devices, once the device was connected through VPN, the device had difficulties doing any local naming resolution lookups.

Turned out that Smart Multi-Homed Name Resolution is evil and we had to turn it off on those experiencing the issue:

ENJOY 🙂