My Always On VPN configuration with Microsoft Intune and Configuration Manager explained

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: 567814

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

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

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 ๐Ÿ™‚

5 thoughts on “My Always On VPN configuration with Microsoft Intune and Configuration Manager explained”

  1. I have seen the issues on multiple builds on Windows as well with DNS.
    It looks like the issue is most with a specific modem device from the ISP which has Ipv6 as DNS server on LAN connection. Often on wifi it works without an issue.
    The issue is especially when you have a DNS record in place both internal and publically availabe as for Outlook for example is often the case.

    In some cases at build 1803 (not sure if this is still an issue) i had to force the VPN profile to get a lower metric than local network card before the issue was resolved.

    Reply
    • Thanks for sharing that, and I concur with your observation. I’ve only seen it when devices are connected via specific equipment ๐Ÿ™‚

      Reply
  2. Hi Martin, I have successfully deployed an always-on VPN across 100+ of our users using SCEP and machine certificates, however one of them is located in a location where VPN connections are blocked to Azure over IKEv2. As I already had a working solution my plan was to follow this guide and add a second configuration purely for this and any other similarly affected users in future and simply change to the Automatic method, adopting SSTP. Unfortunately no matter what settings I use in the EAP security I am told that no certificates exist that can be used with EAP, despite it working fine on IKEv2 with the same certificates but no EAP specific config.
    Do you have any ideas as to what I may have done wrong or if I’m simply missing something?
    Thanks, Lee

    Reply
  3. Splendid article Martin. I have one follow-up question. During your deployment, did you encounter any problems with the remediation of the VPN-Profile when it was deployed from Intune?

    Reply
    • I have seen it take some time for the assignment status to settle in. Initially, it often comes back with error, though the clients have received it just fine. I’ve learned to ignore that, as the assignment status always seem to settle in the following days after initial assignment or when doing changes to the existing profile.

      Reply

Leave a Comment

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