Always On VPN and Third Party VPN Devices

Always On VPN and Third Party VPN DevicesOne of the most important advantages Windows 10 Always On VPN has over DirectAccess is infrastructure independence. That is, Always On VPN does not rely exclusively on a Windows Server infrastructure to support Always On VPN connections. Always On VPN will work with many third-party firewalls and VPN devices, as long as they meet some basic requirements.

Advantages

Third-party firewalls or VPN devices offer some important advantages over Windows Servers running the Routing and Remote Access Services (RRAS), both in terms of security and performance.

Security

Dedicated security devices (physical or virtual) provide better security than a common Windows server. They commonly run specialized, security-hardened operating systems that are highly secure and resistant to attack. In addition, these solutions typically allow the administrator to define policy to restrict access to internal resources and do so in a centralized way. This is often easier to implement and manage than using traffic filters on the client side. They often include advanced security features such as URL filtering and malware inspection to better protect remote clients. Some solutions include Hardware Security Module (HSM) integration to further enhance security.

Performance

Purpose-built solutions often provide better throughput and performance than do Windows Servers by virtue of their proprietary operating systems. This allows for better network throughput and the ability to support many more connections per device.

Disadvantages

The main drawbacks for using a third-party device are cost and administrative overhead. Third-party solutions must be acquired, for which there is typically a non-trivial cost associated. They often need additional per-user licensing. In addition, many of these solutions require specialized skill sets to implement, manage, and support which could further increase the overall cost of the solution.

Interoperability Requirements

Any firewall or VPN device can be used for Always On VPN as long as they support the Internet Key Exchange version 2 (IKEv2) VPN protocol for remote access connections. Most modern firewalls today support IKEv2, but some (such as the Sophos XG firewall) do not. Check with your vendor to validate support.

Native Client

If the firewall or VPN device supports IKEv2 for remote access connections, the native Windows VPN provider can be used to establish an Always On VPN connection. The native provider is used when the Always On VPN ProfileXML is configured using the NativeProfile element.

Plug-In VPN Client

One crucial drawback to using IKEv2 is that it is commonly blocked by firewalls. Many third-party VPN vendors offer a plug-in client that enables support for TLS-based transport, which is more firewall friendly than IKEv2. Plug-in VPN providers are available in the Microsoft store.

Below is a current list of available third-party VPN plug-in providers for Windows 10. (Updated April 5 to now include Cisco AnyConnect!)

  • Check Point Capsule
  • Cisco AnyConnect
  • F5 Access
  • Fortinet Forticlient
  • Palo Alto GlobalProtect
  • Pulse Secure
  • SonicWall Mobile Connect

Always On VPN and Third-Party VPN Devices

Note: Win32 VPN client applications from third-party vendors are not supported with Windows 10 Always On VPN.

Additional Information

What is the Difference Between DirectAccess and Always On VPN?

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Leave a comment

14 Comments

  1. Matt

     /  April 3, 2019

    I noticed Cisco AnyConnect is now available in the Windows Store.
    Does it now work with Always On VPN?
    https://www.microsoft.com/en-us/p/anyconnect/9wzdncrdj8lh

    Reply
    • Thanks for the tip. I hadn’t noticed that! So yes, with a plug-in provider now available in the Windows store it should be possible to create an Always On VPN connection using Cisco AnyConnect. I’ll have to do some testing with that soon to confirm.

      Reply
      • Matt

         /  April 3, 2019

        Sounds good.
        When plug-ins are used, does that automatically mean that the connections will use port 443 TLS for both the user and device tunnels?

      • Typically, yes. I don’t recall seeing a plug-in provider that used anything other than TLS.

      • Matt

         /  April 4, 2019

        Are you sure that the device tunnel will also be TLS when the plug-in is used?
        I thought the third party UWP plug-ins only work for user tunnels.
        I can’t find any information on setting the device tunnel to TLS to completely eliminate all IKEv2 network requirements.

      • Using third-party plug-in providers is not supported with the device tunnel. You can only use the native (built-in) VPN client when deploying the Windows 10 Always On VPN device tunnel.

      • Matt

         /  April 4, 2019

        OK, so does that mean the only networking option ever available for a device tunnel is IKEv2?
        We were hoping to have a reliable connection at the login screen that won’t be blocked by firewalls so users can reset their forgotten passwords and then be able to log in with the new password connecting to an on-premises domain controller.

        The device tunnel won’t be very useful otherwise and we would just skip it to eliminate extra complexity in the configuration.

      • Correct. The device tunnel can only use IKEv2 so it is possible there will be occasions where users will be behind a restrictive firewall that blocks it and won’t be able to connect. The user tunnel will work assuming it uses SSTP, however.

      • Matt

         /  April 10, 2019

        If the AnyConnect plugin works for AOVPN, maybe we won’t need a device tunnel at all if we combine AOVPN with Windows Hello For Business.
        With Windows Hello for Business, if a user forgets their AD password and needs it reset, they should still be able to log in locally with their PIN or biometric login.
        Once logged into the device, the user can get online to change their password via self-service password reset.
        Once the password is reset, they would then need to somehow update their cached credentials to match the password change (lock and uinlock screen while connected to the user tunnel).
        Will the use tunnel still connect and communicate with domain controllers if the cached credentials don’t match the user’s updated password?
        .

        If WHFB plus AOVN works in this scenario, the only real need for a device tunnel would be if there are no cached credentials and/or the user forgets their Hello PIN and boimetric login also isn’t available.

        This would be a clunky process to update forgotten passwords compared to having a working device tunnel at the login screen, but it could be a workaround if it actually works.

      • Sounds feasible assuming you have enabled self-service password reset. No need to talk to a domain controller over the VPN to change a password at that point.

  2. Matt

     /  April 10, 2019

    The actual password change isn’t the main issue. The user can call the help desk to get their password changed even if self-service password reset isn’t available.
    The issue I’m trying to solve is how to get the cached credentials updated if the user doesn’t remember the last saved password and a device tunnel isn’t available.

    Does the user tunnel still work when the cached credentials on the laptop don’t match the current password on the domain? Will the password mismatch prevent the tunnel from authenticating or cause the user’s account to lock out?

    Reply
    • To my knowledge there’s only one way to update cached credentials and that’s to log on with valid credentials. 🙂 If you are using client certificate authentication I don’t think this would be a problem though, because the user name defined on the certificate is mapped to a domain account. As long as the account isn’t expired or disabled then I’d think it would work. If you’re using username/password it’s a different story of course.

      Reply
  3. Richard

     /  May 2, 2019

    The use of a third party is an interesting idea as I am looking to deploy in the cloud and AZURE specifically says no RRAS and AWS doesn’t really say either way. I am wondering if deploying on a Cisco solution may overcome this. Does anyone know if I can still use device and user tunnels with third party devices and native Windows vpn client functionality though? And any other restrictions I need to be aware of. I have built using the Windows build guides and that worked fine but cant find much on using anything else……

    Reply
    • Using third-party VPN devices in the cloud is probably the best (and most supportable) alternative. For the record, I’ve deployed RRAS in Azure and AWS numerous times without issue. “Not supported” is different than “doesn’t work”. 😉 In theory, any VPN device that supports IKEv2 should be able to support device tunnels. In Azure specifically, another option is to use the Azure VPN gateway. However, that option does not support device tunnel.

      Reply

Leave a 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: