Windows Server 2019 – Always On VPN

How to find files and file listing on ubuntu

Giving a user access to a VPN connection traditionally means providing them with a special network connection link that they can launch, enter credentials to pass authentication, and then be connected to their work environment’s network in order to communicate with company resources. After launching a VPN, users can open their email, find documents, launch their line-of-business applications, or otherwise work in the same ways that they can when physically sitting in their office. Also, when connected via a VPN, management of their laptop is possible, enabling successful a communication flow for systems such as Group Policy and SCCM. VPN connections offer great connectivity back to your network, but (remember, we are talking about traditional, regular VPN connections here) they only work when the user manually launches them and tells them to work. Anytime that a user has not connected to their VPN, they are navigating the internet with no connectivity back to the company data center. This also means that a traditional VPN connection obviously has no form of connectivity on the Windows login screen, because, until they get logged into the computer and find their way to the Windows desktop, users have no way of launching that VPN tunnel. This means that anything that might try to happen at the login screen, such as live authentication lookups, or during the login process, such as Group Policy processing or logon scripts, will not function via a traditional VPN.

Always On VPN (AOVPN), just as you have probably guessed based on the name, is simply the idea of making a VPN connection continuous and automatically connected. In other words, any time that the user has their laptop outside the office walls and is connected to the internet, a VPN tunnel back to the corporate network is automatically established, ideally with zero user input to the process. This enables users to forget about the VPN altogether, as it is simply always connected and ready for them to use. They can log into their machines, launch their applications, and start working. It also means that IT management functions such as security policies, updates, and installer packages can push out to client machines a greater percentage of the time, since we no longer wait for the user to decide when they want to connect back to work; it happens automatically and pretty much all the time.

There are actually three different ways in which Always On VPN can be triggered on the client machine, and none of them involve the user having to launch a VPN connection:

  • AOVPN can be configured to truly be Always On, meaning that as soon as internet access is available, it will always attempt to connect.
  • Another option is application triggering, which means that you can configure AOVPN to launch itself only when specific applications are opened on the workstation.
  • The third option is DNS name-based triggering. This calls the VPN connection into action when particular DNS names are called for, which generally happens when users launch specific applications.

Since you obviously don’t need Always On VPN to be connected and working when your laptop is sitting inside the corporate network, we should also discuss the fact that AOVPN is smart enough to turn itself off when the user walks through those glass doors. AOVPN-enabled computers will automatically decide when they are inside the network, therefore disabling VPN components, and when they are outside the network and need to launch the VPN tunnel connection. This detection process is known as Trusted Network Detection. When configured properly, Always On VPN components know what your company’s internal DNS suffix is, and then it monitors your NIC and firewall profile settings in order to establish whether or not that same suffix has been assigned to those components. When it sees a match, it knows you are inside the network and then disables AOVPN.

Types of AOVPN tunnel

Before we get started on the particulars of the client and server components required to make AOVPN happen, there is an important core topic that needs to be understood in order to make appropriate decisions about how you want to utilize AOVPN in your company. There are two very different kinds of VPN tunnel that can be used with Always On VPN: a User Tunnel and a Device Tunnel. As you will learn later in this chapter, the ability to have two different kinds of tunnel is something included with AOVPN in order to bring it closer to feature parity with DirectAccess, which also has this dual-tunnel mentality. Let’s take a minute and explore the purposes behind the two tunnels.

User Tunnels

The most common way of doing AOVPN in the wild (so far), a User Tunnel is authenticated on the user level. User certificates are issued from an internal PKI to your computers, and these certificates are then used as part of the authentication process during connection. User Tunnels carry all of the machine and user traffic, but it is very important to note that user Tunnels cannot be established while the computer is sitting on the login screen, because user authentication has not happened at that point. So, a User Tunnel will only launch itself once a user has successfully logged into the computer. With only a User Tunnel at play, the computer will not have connectivity back to the corporate network for management functions until someone has logged into the computer, and this also means that you will be relying on cached credentials in order to pass through the login prompt.

Device Tunnels

A Device Tunnel is intended to fill the gaps left by only running a User Tunnel. A Device Tunnel is authenticated via a machine certificate, also issued from your internal PKI. This means that the Device Tunnel can establish itself even prior to user authentication. In other words, it works even while sitting at the Windows login screen. This enables management tools such as Group Policy and SCCM to work regardless of user input, and it also enables real-time authentication against domain controllers, enabling users to log into the workstation who have never logged into it before. This also enables real-time password expiry resets.

Device Tunnel requirements

A User Tunnel can work with pretty much any Windows 10 machine, but there are some firm requirements in order to make use of a Device Tunnel. In order to roll out a Device Tunnel, you need to meet the following requirements:

  • The client must be domain-joined.
  • The client must be issued a machine certificate.
  • The client must be running Windows 10 1709 or newer, and only Enterprise or Education SKUs have this capability.
  • A Device Tunnel can only be IKEv2. This is not necessarily a requirement, but is important to understand once we get around to discussing what IKEv2 is and why it may or may not be the best connectivity method for your clients.

AOVPN client requirements

It is important to understand that the Always On part of Always On VPN is really client-side functionality. You can utilize AOVPN on a client computer in order to connect to many different kinds of VPN infrastructure on the backend. We will talk about that shortly, in the AOVPN server components section.

While creating regular, manual VPN connections has been possible on Windows client operating systems for 15 or 20 years, Always On VPN is quite new. Your workforce will need to be running Windows 10 in order to make this happen. Specifically, they will need to be running Windows 10 version 1607 or a more recent version.

The following are the supported SKUs:

  • Windows 10 1607+
  • Windows 10 1709+
  • Windows 10 1803+

Wait a minute—that doesn’t make any sense. Why list those three items separately if they are inclusive of one another? Because, while technically Always On VPN was officially introduced in Windows 10 1607, it has had some improvements along the way. Let’s list those again, with a brief summary of what has changed over the years:

  • Windows 10 1607: The original capability to auto-launch a VPN connection, thus enabling Always On VPN.
  • Windows 10 1709: Updates and changes included the addition of Device Tunnel. If you intend to run a Device Tunnel for computer management purposes (and most enterprises will), then consider 1709 to be your minimum OS requirement.
  • Windows 10 1803: Includes some fixes that were discovered from 1709. In reality, what this means is that I never see anyone implementing Always On VPN unless they are running 1803. Thankfully, the Windows 10 update platform is much improved, meaning that many more companies are rolling out newer versions of Win10 on an ongoing basis, and upgrading to 1803 is much less painful than, say, a Windows XP to Windows 7 migration.

Whether you are running 1607, 1709, 1803, or 1809the particular SKU within those platforms does not matter. Well, it hardly matters. Always On VPN works with Windows 10 Home, Pro, Enterprise, and all of the other flavors. That is, the User Tunnel works with all of those.

It is important enough to point out once again: if you want to utilize a Device Tunnel with Always On VPN, using domain-joined, Windows 10 Enterprise or Education SKUs is a firm requirement.

Domain-joined

As we have already established, when you’re interested in using the AOVPN Device Tunnel, your client computers must be domain-joined. However, if you are okay with only running the User Tunnel for AOVPN access, then there are no domain-membership requirements. Clients still need to be running Windows 10 1607 or newer, but they could be any SKU and could even be home computers that are joined to simple workgroups; no domain is required.

This is emphasized specifically in Microsoft documentation in many places, because it enables Always On VPN to be utilized (somewhat) with the Bring Your Own Device (BYOD) crowd. While this is interesting, I don’t foresee it being at all common that companies would allow employees’ personal computers to be connected to their VPN. Most organizations are trying to cater in a small way to the BYOD market by providing access to some resources via the cloud, such as Office 365 for email and documents. But connecting those personal computers and devices back to your network with a full-scale layer 3 VPN tunnel? I don’t think so. That is the stuff of security administrators’ nightmares.

Rolling out the settings

Let’s say you have all of the server-side parts and pieces ready to roll for VPN connectivity, and in fact you have successfully established the fact that you can create ad hoc traditional VPN connections to your infrastructure with no problems. Great! Looks like you are ready from the infrastructural side. Now, what is necessary to get clients to start doing Always On connections?

This is currently a bit of a stiff requirement for some businesses. The configuration itself of the Always On VPN policy settings isn’t terribly hard; you just have to be familiar with the different options that are available, decide on which ones are important to your deployment, and put together the configuration file/script. While we don’t have the space here to cover all of those options in detail, the method for putting those settings together is generally to build out a manual-launch VPN connection, tweak it to the security and authentication settings you want for your workforce, and then run a utility that exports that configuration out to some configuration files. These VPN profile settings come in XML and PS1 (PowerShell script) flavors, and you may need one or both of these files in order to roll the settings around to your workforce. The following is a great starting point for working with these configurations: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections.

Once you have created your configuration files, you then face the task of pushing that configuration out to the clients. You ideally need to have a mobile device management (MDM) solution of some kind in order to roll the settings out to your workforce. While many technologies in the wild could be considered to be MDMs, the two that Microsoft is focused on are System Center Configuration Manager (SCCM) and Microsoft Intune.

If you have SCCM on-premise, great! You can easily configure and roll out PowerShell-based configuration settings to your client computers and enable them for Always On VPN.

Perhaps you don’t have SCCM, but you are cloud-focused and you have all of your computers tapped into Intune? Wonderful! You could alternatively use Intune to roll out those AOVPN settings via XML configuration. One of the benefits of taking the Intune route is that Intune can manage non-domain-joined computers, so you could theoretically include users’ home and personal computers in your Intune managed infrastructure, and set them up to connect.

SCCM and Intune are great, but not everybody is running them. There is a third option for rolling out Always On VPN settings via PowerShell scripting. While this is plan B from Microsoft (they would really prefer you to roll out AOVPN via an MDM), I’m afraid that PowerShell will be the reality for many SMB customers who want to utilize AOVPN. The biggest downside to using PowerShell in order to put AOVPN settings in place is that PowerShell needs to be run in elevated mode, meaning that it’s difficult to automate because the logged on user (which is where you need to establish the VPN connection) needs to be a local administrator for the script to run properly.

I am hopefully and anxiously waiting for the day that they announce a Group Policy template for rolling out Always On VPN settings, but so far, there is no word on whether or not that will ever be an option. Everyone has Group Policy; not everyone has MDM. You will read in a few moments that the rollout of Microsoft DirectAccess connectivity settings (an alternative to AOVPN) is done via Group Policy, which is incredibly easy to understand and manage. As far as I’m concerned, at the time of writing, DirectAccess holds a major advantage over AOVPN in the way that it handles the client-side rollout of settings. But, make sure you check out Microsoft Docs online to find the latest information on this topic, as AOVPN is being continuously improved and there will likely be some changes coming to this area of the technology.

AOVPN server components

Now that we understand what is needed on the client side to make Always On VPN happen, what parts and pieces are necessary on the server/infrastructure side in order to allow these connections to happen? Interestingly, the Always On component of AOVPN has nothing to do with server infrastructure; the Always On part is handled completely on the client side. Therefore, all we need to do on the server side is make sure that we can receive incoming VPN connections. If you currently have a workforce who are making successful VPN connections, then there is a good chance that you already have the server infrastructure necessary for bringing AOVPN into your environment.

Remote Access Server

Obviously, you need a VPN server to be able to host VPN connections, right? Well, not so obviously. In Windows Server, the role that hosts VPN, AOVPN, and DirectAccess connections is called the Remote Access role, but you can actually get Always On VPN working without a Windows Server as your Remote Access Server. Since the Always On part is client-side functionality, this enables VPN server-side infrastructures to be hosted by third-party vendors. Even though that is technically accurate, it’s not really what Microsoft expects; nor is it what I find in the field. In reality, those of us interested in using Microsoft Always On VPN will be using Microsoft Windows Server in order to host the Remote Access role, which will be the inbound system that our remote clients connect to.

A lot of people automatically assume that AOVPN is married to Windows Server 2019 because it’s a brand-new technology and Server 2019 was just released, but that is actually not the case at all. You can host your VPN infrastructure (the Remote Access role) on Server 2019, Server 2016, or even Server 2012 R2. It works the same on the backend, giving clients a place to tap into with their VPN connections.

After installing the Remote Access role on your new Windows Server, you will find that the majority of the VPN configuration happens from the Routing and Remote Access (RRAS) console. While configuring your VPN, you will find that there are multiple protocols that can be used in order to establish a VPN connection between client and server, and you should have at least a brief understanding of what those different protocols are. I’ll list them here in order of strongest and most secure, all the way down to don’t touch this one!

IKEv2

The newest, strongest and, all-in-all, best way to connect your client computers via VPN or AOVPN, IKEv2 is the only way to connect the AOVPN Device Tunnel. IKEv2 requires machine certificates to be issued to your client computers in order to authenticate. This generally means that if you want clients to connect via IKEv2, those clients will be domain-joined. It is very important to note that IKEv2 uses UDP ports 500 and 4500 to make its connection.

SSTP

Considered to be the fallback method for connecting AOVPN connections, SSTP uses an SSL stream in order to connect. Because of this, it requires an SSL certificate to be installed on the Remote Access Server, but does not require machine certificates on the client computers. SSTP uses TCP port 443, and so it is able to connect even from inside very restrictive networks where IKEv2 may fail (because of IKEv2’s reliance on UDP).

L2TP

Not generally used for AOVPN deployments, L2TP is able to establish VPN connections by using certificates or a pre-shared key. Since you already have two better protocols at your disposal, you shouldn’t be using this one.

PPTP

While still a valid configuration option inside RRAS, stay away from this guy! PPTP has essentially been cracked, and if you are still running VPN connections based on PPTP, you basically need to consider those traffic streams to be unencrypted and clear-text over the internet.

Certification Authority (CA)

Machine certificates, user certificates, SSL certificates… Oh, my! Clearly you need to be familiar with working with and deploying certificates in order to make use of Always On VPN. This is becoming more and more common with newer, well-secured technologies of any flavor. The major requirement here is that you will need to have PKI inside your environment and at least one Windows CA server in order to issue the necessary certificates. The following is a list of the places in which certificates could be used by an AOVPN infrastructure:

  • User certificates: These are the certificates issued to your VPN users from an internal CA, used for authentication of the User Tunnel.
  • Machine certificates: These are certificates issued to your workstations (mostly laptops) from an internal CA, used for authentication of the Device Tunnel.
  • SSL certificate: Installed on your Remote Access Server in order to validate the incoming traffic for SSTP VPN connections.
  • VPN and NPS machine certificates: Your Remote Access Server, as well as your NPS servers, which we will talk about in just a minute, require machine certificates issued from your internal CA.

Network Policy Server (NPS)

NPS is basically the authentication method for VPN connections. When a VPN connection request comes in, the Remote Access Server hands that authentication request over to an NPS server in order to validate who that user is, and also to verify that the user has permissions to log in via the VPN.

Most commonly when working with Microsoft VPN connections, we configure NPS so that it allows only users who are part of a certain Active Directory Security Group. For example, if you create a group called VPN Users and then point NPS to that group, it will only allow users whom you have placed inside that group make successful VPN connections.

NPS is another Windows Server role that can be hosted on its own system or spread across multiple servers for redundancy. As with the Remote Access role itself, there is no Server 2019 requirement for NPS. You could easily deploy it on previous versions of Windows Server just as well.

In small environments that have just a single Remote Access Server, it is common to co-host the NPS role right on the same server that is providing VPN connectivity.

Comments are closed.