One 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
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
Matt
/ April 3, 2019I 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
Richard M. Hicks
/ April 3, 2019Thanks 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.
Matt
/ April 3, 2019Sounds 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?
Richard M. Hicks
/ April 4, 2019Typically, yes. I don’t recall seeing a plug-in provider that used anything other than TLS.
Matt
/ April 4, 2019Are 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.
Richard M. Hicks
/ April 4, 2019Using 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, 2019OK, 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.
Richard M. Hicks
/ April 5, 2019Correct. 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, 2019If 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.
Richard M. Hicks
/ April 10, 2019Sounds 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.
Matt
/ April 10, 2019The 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?
Richard M. Hicks
/ April 10, 2019To 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.
Richard
/ May 2, 2019The 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……
Richard M. Hicks
/ May 2, 2019Using 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.
Colin
/ July 16, 2019Richard,
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. 🙂
Richard M. Hicks
/ July 17, 2019I’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?
Colin
/ July 17, 2019Fortinet would be my preference.
Richard M. Hicks
/ July 18, 2019Ok, I’ll try to put something together soon. 🙂
Colin Small
/ July 18, 2019Thanks Richard! I’m really curious about the whole certificate internal CA, Authentication, RADIUS, device tunnels.. etc..
Karsten Hentrup
/ August 8, 2019Hiho Richard,
a Plugin Profile for Palo Alto will be nice! 😉
Greets, Karsten…
Richard M. Hicks
/ August 13, 2019I have a sample ProfileXML for Always On VPN using Palo Alto Global Protect and plugin profile on my GitHub here: https://github.com/richardhicks/aovpn/blob/master/ProfileXML_PaloAlto.xml. Enjoy!
Karsten Hentrup
/ August 14, 2019Hi Richard,
thank you very much! I’ll try to build a native + Plugin profile to Palo Alto.
Were you successfull with a native IKEv2 Profile in your Environment?
Greets, Karsten…
Richard M. Hicks
/ August 15, 2019I never tried using the native client with the Palo Alto. It supports IKEv2 though, so I think it should work.
Gareth
/ November 26, 2019Hi, was anything put together for a Fortinet based solution? I’d be interested to see a high level design if anyone had something they could share?
Richard M. Hicks
/ November 26, 2019It’s on my list of articles to write, but it keeps getting pushed farther down the list. Also, a busy consulting schedule has kept me from writing as often as I’d like. Hope to get to it sometime in the future though. 🙂
Cristhian
/ September 4, 2023Were you able to do the lab with forti? do you have an example of a windows profile for forti?
Thank you very much
Richard M. Hicks
/ September 5, 2023It’s been quite some time since I worked with a Fortinet device. The configuration profile was quite simple. I’ve uploaded an example to my GitHub here.
https://github.com/richardhicks/aovpn/blob/master/ProfileXML_Fortinet.xml
Louis
/ July 28, 2019Cisco 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.
Richard M. Hicks
/ July 30, 2019There’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.
Colin
/ July 30, 2019You 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..
Tiifraly
/ November 11, 2019I dont get this AOVPN+PaloAlto big picture like everyone else.. So Is it possible to use PaloAlto Firewalls instead of Windows RRAS server? And if so, we can use windows native AOVPN profiles (with free PluginPackageFamilyName PaloaAlto) to make VPN connections with win10 clients? Not necessary need of any PaloAlto GlobalProtect software. Thanks 🙂
Richard M. Hicks
/ November 13, 2019That’s correct. A Windows 10 Always On VPN client can be configured to use the Palo Alto Global Protect plug-in provider for Windows 10 and an Always On VPN profile can be provisioned to clients using this client. You can find a sample ProfileXML file for Always On VPN using Palo Alto Global Protect here: https://github.com/richardhicks/aovpn/blob/master/ProfileXML_PaloAlto.xml.
Allan
/ December 2, 2019But still, only User tunnel, no device tunnel right?
Richard M. Hicks
/ December 5, 2019Correct. It might be possible to configure the device tunnel to work with non-Microsoft VPN platforms, but I’m not familiar with how to do that. In theory if your VPN server supported device certificate authentication it should work though.
hihfkjsdhf
/ December 9, 2019Hi, I am trying to find some information on – Always ON VPN working with Android end user devices, do you know if this is possible ? We have mixture of devices in our environmnet with bigger part MS and looking the option to implement Always ON for corp devices, but would that work with the mobile ( Android & iOS) corp devices ? We are using Sophos as our MDM
Richard M. Hicks
/ December 15, 2019The VPN server used by Windows 10 Always On VPN clients can be used for other non-Microsoft platforms, assuming that they use the same authentication scheme or that NPS is configured to use a different authentication scheme for non-Microsoft devices.
Simon
/ April 23, 2020Is there any information about setting this up anywhere? I have a nice DirectAccess setup running but want to move to AoV using Cisco ASA as the VPN gateways.
Richard M. Hicks
/ April 24, 2020Not to my knowledge. I’ve been asked to post content on implementing Windows 10 Always On VPN with third-party devices on a few occasions but haven’t been able to prioritize this yet. Hope to be able to get something published at some point. Not sure when though.
Julien Potier
/ May 13, 2020Hi Richard. Is this possible to use non windows VPN clients to connect to a RRAS server presumably using IKEv2 since SSTP is proprietary ?
Richard M. Hicks
/ May 14, 2020Absolutely. IKEv2 is an open standard and as long as the client and server are configured using the same security parameters, and the client can use whatever authentication protocol is required, it should work.
Matt
/ June 26, 2020Since third party plug-ins only support user tunnels, can you use the Cisco AnyConnect plug-in for the user tunnel and the native VPN client for the device tunnel simultaneously or have device tunnel switch over to user tunnel after the user gets logged in?
Does Cisco Firepower ASAs support connecting to both (user tunnel via plug-in and device tunnel via native Windows 10 settings)?
Richard M. Hicks
/ June 29, 2020Yes, you can. Nothing prevents you from using the native VPN client and IKEv2 for the device tunnel while using the plug-in provider for the user tunnel. In fact, as they are two separate and distinct connections, I’ve actually seen deployments where RRAS was used for the device tunnel and another VPN device was used for the user tunnel. 🙂
Matt
/ June 29, 2020So, if there is overlapping connectivity with the device tunnel and user tunnel, there will not be a conflict? For instance, if the user tunnel includes everything in the device tunnel plus more.
Does the device tunnel drop when the user signs into the user tunnel?
Richard M. Hicks
/ June 29, 2020No conflicts. The routing table will sort it out. More specific routes will be preferred, and if there are matching routes the route metric will decide which physical interface the traffic is sent over. Should work without issue. 🙂
Matt
/ June 28, 2020Would it ever make sense to use Microsoft’s AOVPN together with Cisco’s VPN hardware and AnyConnect UWP plug-in when, if you have a Cisco hardware and AnyConnect licensing anyway, you could instead use Cisco’s management VPN tunnel and their version of always on VPN or automatically starting user VPN?
It looks like the Cisco management VPN tunnel is equivalent to a device tunnel with Microsoft’s AOVPN without the IKEv2 firewall blocking limitations.
AnyConnect profiles can be configured for automatically connecting using certificates just like AOVPN and looks like it can be the same or an even better user experience than AOVPN.
Richard M. Hicks
/ June 29, 2020Absolutely. However, it would probably be best to use Cisco’s technology entirely as opposed to trying to make it work with Windows 10 Always On VPN. Same goes for Palo Alto. 🙂
grahampriley
/ August 25, 2020Hi Richard, most of the documentation for Windows 10 AOVPN suggests using Microsoft’s NPS server to handle the authentication for user tunnels but since we have Cisco ISE I was wondering if it is possible to use this instead. Do you know if this is possible? We already have AOVPN Device Tunnels configured via MS RRAS which is working fine and we need to start using User Tunnels.
Thanks,
Graham
Richard M. Hicks
/ August 25, 2020Any RADIUS implementation should work, including Cisco ISE. 🙂