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

27 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
  4. Colin

     /  July 16, 2019

    Richard,

    Any chance of you making a post of an example configuration/process with a third-party VPN solution?

    I would like to take advantage Fortinet if I could (using RRAS at the moment) but I struggle to find much information about configuring Windows 10 for Always On VPN with a third-party solution.

    How are the settings handled on each side… how are things like RADIUS/Internal CA’s utilized etc..

    I’m not sure how much work an article like that would be for you but I’d love to see something along these lines.

    It really seems like third-party solutions are the way to go and the future of AOVPN as opposed to RRAS (in my opinion).

    I’d settle for some links that cover this topic somewhere else though if you or another subscriber have any to share. 🙂

    Reply
    • I’ve considered this, but it might end up being a rather lengthy article. 🙂 I agree that using a dedicated security device for VPN connections is ideal, but RRAS is popular because it is inexpensive and easy to implement, manage, and scale. RRAS combined with an existing edge firewall ultimately ends up being the architecture of choice for most deployments for those reasons. That said, I have deployed Always On VPN using a variety of third-party firewall/VPN devices and from experience I can tell you they are all a little different and have their own unique limitations.

      I currently have SonicWall, Fortinet, and Palo Alto firewalls in my lab I can use to put some guidance together. Any preference for which one first?

      Reply
  5. Louis

     /  July 28, 2019

    Cisco Anyconnect, NCP Entry Point etc have a trusted network feature which basically makes their client location aware ie inside outside the corp network and work well by themselves.
    We liked DA as it was built into windows but it was a little quirky too. Now that Microsoft has killed it off in favour of AOVPN, we had to look at that.
    We hit various issues ie we couldn’t DNAT to a RRAS because we were already using IPsec on our Sophos UTM which also didn’t support IKEv2.
    We also didn’t like the fact that AOVPN uses the standard IPSec ports which could create an issue with public networks blocking it.
    We are now moving towards using SSTP on windows 10 as this uses port 443 and has more chance of getting through.
    Microsoft also has enabled some powershell commands which allow us to auto trigger the VPN by application, DNS and trusted networks.
    It’s working quite nicely at the moment with NPS certificate authentication although we have yet got to find a way for it to use a backup or load balanced route eg try VPN2 if VPN1 doesn’t respond etc.
    Currently, we have an auto connection to site A for x amount of clients with a manual backup connection for site B and vice versa.

    Reply
    • There’s no native option for failover/redundancy. However, you can implement more than on VPN server and use a load balancer to distribute requests between them. If you want geographic redundancy you can implement VPN servers in different locations and use GSLB (appliance or cloud service) to route client requests.

      Reply
    • Colin

       /  July 30, 2019

      You should be able to use a load balancer to balance connections between two or more nodes. If one goes down the clients can connect to one that is still up.

      fqdn –> vip@lb –> n1, n2, n3 etc..

      Reply
  1. Always On VPN Options for Azure Deployments | Richard M. Hicks Consulting, Inc.

Leave a Reply to Richard 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: