In my previous post, I talked about the new VPN support for user-driven Hybrid Azure AD Join.  I described the key VPN requirements:

• The VPN connection either needs to be automatically established (e.g.
  “always on”) or it needs to be one that the user can manually initiate from the
  Windows logon screen.  For the “manually initiate” case, that typically means a VPN client that leverages the RAS capabilities and pre-logon authentication hook (PLAP) capabilities that has been in Windows for several years.
• The needed VPN configuration needs to be applied during device ESP.  Usually this means a Win32 app delivered by Intune.  The configuration of those Win32 VPN clients varies by vendor, but often this configuration is bundled into the installer itself (not delivered separately).

As the official docs don’t get into the specifics for what third-party VPN clients can be used, I thought it would be useful to review what will and won’t work.  In many cases, that really means what we think will work, because we don’t happen to have environments available to try out all of these VPN solutions ourselves.  But we can read their public documentation, looking for specific capabilities.

First though, let’s talk about what we know won’t work today:

• Third-party UWP VPN plug-ins.  There are some UWP-based VPN plug-ins available in the Microsoft Store, but these cannot be installed and used prior to the user signing into the device.  Hence you need to use a “fat” VPN client, a Win32 app that can be deployed to the device, or alternatively the in-box Windows VPN client.
• User certificate authentication.  You can’t deliver a user cert to a device before the user signs in, and if the user can’t sign in before getting that user cert, then you can see the obvious chicken-and-egg problem.
• DirectAccess.  While we can provision the offline domain join blob over the internet, the ODJ Connector doesn’t have the ability to deliver the needed certificates and polices as part of that ODJ blob.  (You can provision DirectAccess later if you want, since the GPOs can be applied with VPN connectivity.)

So let’s do a quick run-through of the third-party VPN clients that we believe will work, either based on customer reports during the private preview process or on our reading of the available documentation.

• Cisco AnyConnect.  This supports a feature called “Start before logon” (SBL) that integrates with the Windows logon screen using PLAP.  This feature needs to be explicitly enabled as described in the Cisco docs.
• Pulse Secure.  As described in the Pulse Secure documentation, the “Credential provider for Windows” feature enables users to establish a VPN connection prior to signing into Windows.
• Palo Alto Global Protect.  The “Pre-logon” feature described in the Global Protect documentation also enables users to establish a VPN connection prior to signing into Windows.
• Checkpoint.  While I don’t seem to be able to access the Checkpoint documentation around this any more, it did describe the “Auto Connect / Always Connected” feature that enables the device to automatically establish a VPN connection.
• Citrix NetScaler.  The “AlwaysON” feature described in the NetScaler documentation describes the available option for establishing a VPN connection (although the authentication requirements are not clear).
• SonicWall NetExtender.  The “NetExtender On Startup” feature as described in the SonicWall documentation enables a VPN connection prior to the Windows logon process.
• F5 BIG-IP Edge Client.  The F5 documentation describes a “Dialup Entry/Windows Logon Integration” feature that enables the user to establish a VPN connection from the Windows logon page.

For those of you who have already set up one of these VPN clients to be deployed via Intune for the Autopilot VPN scenario, if you are willing to share the specifics of the configuration (e.g. the Win32 app setup and any related device configuration profiles), let me know.

It’s also possible to use Windows Always On VPN device tunnels.  As I noted in a past blog post, this is a little tricky to set up, but once it is set up it works well.  As noted in the Intune “In Development” documentation, there is work being done to make the device tunnel profile easier to create:

When you create a VPN profile using the IKEv2 connection type, there are new settings you can configure (Devices > Configuration profiles > Create profile > Windows 10 and later for platform > VPN for profile > Base VPN):

• Device Tunnel: Allows devices to automatically connect to VPN without requiring any user interaction, including user log on. This feature requires you to enable Always On, and use Machine certificates as the authentication method.
• Cryptography suite settings: Configure the algorithms used to secure IKE and child security associations, which allow you to match client and server settings.

So that is coming soon.

If you have questions about which VPN clients will work, please see the second part of this post: Windows Autopilot user-driven Hybrid Azure AD Join: Which VPN clients work?