loading...

Windows Server 2019 – DA, VPN, or AOVPN? Which is best?

How to Create Swap File on Ubuntu 19.10 & 19.04

VPN has been around for a very long time, making it a pretty familiar idea to anyone working in IT. Always On VPN certainly brings its share of new capabilities, but under the hood what AOVPN is doing is launching a traditionally configured VPN connection, so the connection flow is similar to what we have always known. In this chapter, we have also discussed quite a bit about DirectAccess in order to bring you up to speed on this alternative method of automatically connecting your remote clients back to the data center. Now that you know there are two great connectivity platforms built into Windows Server 2019 for enabling your mobile workforce, which one is better?

You don’t have to choose! You can actually run both of these technologies side-by-side, even on the same Remote Access Server. Each technology has its pros and cons, and the ways that you use each, or both, will depend upon many variables. Your users, your client computers, and your organization’s individual needs will need to be factored into your decision making process. Let’s discuss some of the differences between DirectAccess and VPN so that you can make intelligent decisions on which connectivity platforms fit into your organization well.

Domain-joined or not?

One of the biggest requirements for a DirectAccess client computer is that it must be domain-joined. While this requirement in and of itself doesn’t seem so major, what it implies can have huge implications. Trusting a computer enough to be joined to your domain more than likely means that the laptop is owned by the company. It also probably means that this laptop was initially built and prepped by the IT team. Companies that are in the habit of allowing employees to purchase their own computers to be used for work purposes may not find that DirectAccess fist well with that model. DA is also not ideal for situations where employees use their existing home computers to connect into work remotely.

In these kinds of situation, such as home and personally-owned computers, VPN may be better suited to the task. You can connect to a VPN (including Always On VPN) from a non-domain-joined Windows 10 machine, and you can even establish VPN connections (manual connections) from many non-Microsoft devices. iOS, Android, Windows phones, and the Mac—all these platforms have a VPN client built into them that can be used to tap into a VPN listener on a Windows Server 2019 Remote Access Server. If your only remote access solution were DirectAccess, you would not be able to provide non-domain-joined devices with a connectivity platform.

Keep in mind that, while the Always On VPN User Tunnel is more flexible than DirectAccess in this regard, if you intend to use the AOVPN Device Tunnel, then your machines will still need to be domain-joined.

Auto or manual launch

There are multiple different ways to look at this one. When discussing whether DirectAccess or a traditional VPN is better, DirectAccess is the clear winner. Nobody wants to make their users open a connection and manually launch it in order to establish VPN connectivity when an automated platform is available to use.

Always On VPN, however, brings automated and seamless connectivity to the VPN world. AOVPN is almost as seamless as DirectAccess in this regard. I say almost because, at the time of writing, it’s fairly difficult to make a Device Tunnel work well. This means that most companies rolling out AOVPN are only using the User Tunnel. In the User Tunnel scenario, the VPN does launch automatically, but not until the user has already passed the login screen. This means that, in these situations, DirectAccess still holds an advantage over AOVPN, because DA connects seamlessly at the login screen. This enables password resets and new domain users to log into DA-connected machines. My hope is that future improvements will enable AOVPN devices and User Tunnels to co-exist well, which will give true always-on connectivity to AOVPN clients.

Software versus built-in

I’m a fan of Ikea furniture. They do a great job of supplying quality products at a low cost, including packaging it up in incredibly small boxes. After you pay for the product, unbox it, put it together, and then test it to make sure it worksit’s great. If you can’t see where this is going, I’ll give you a hint: it’s an analogy for traditional, third-party VPNs. As in, you typically pay a vendor for their VPN product, unbox it, implement it at more expense, then test the product. That VPN software then has the potential to break and need reinstallation or reconfiguration, and will certainly come with software updates that need to be accomplished down the road. Maintenance, maintenance, maintenance.

Maybe I have been watching too many home improvement shows lately, but I am a fan of houses with built-ins. Built-ins are essentially furniture that is permanent to the house, built right into the walls, corners, or wherever it happens to be. It adds value, and it integrates into the overall house much better than furniture that was pieced together separately and then stuck against the wall in the corner.

DirectAccess and Always On VPN are like built-ins. They live inside the operating system. There is no software to install, no software to update, no software to reinstall when it breaks. Everything that DA and AOVPN need is already in Windows today, you just aren’t using it. Oh, and it’s free! Well, built into the cost of your Windows license anyway. There are no user CALs, and no ongoing licensing costs related to implementing one of Microsoft’s remote access solutions.

If your workforce consists of Windows 10 machines, Microsoft DirectAccess or Microsoft Always On VPNs are clear winners when compared to any third-party VPN connectivity solution.

Password and login issues with traditional VPNs

If you have ever worked on the helpdesk for a company that uses a VPN, you know what I’m talking about. There are a series of common troubleshooting calls that happen in the VPN world related to passwords. Sometimes, the user forgets their password. Perhaps their password has expired and needs to be changedugh! VPN doesn’t handle this scenario very well either. Or perhaps the employee changed their expired password on their desktop before they left work for the day, but are now trying to log in remotely from their laptop and it isn’t working.

What is the solution to password problems with VPN? Reset the user’s password and then make the user come into the office in order to make it work on their laptop. Yup, these kinds of phone call still happen every day. This is unfortunate, but a real potential problem with old-school VPNs.

What’s the good news? New Microsoft remote access solutions don’t have these kinds of problem! Since DA and AOVPN are part of the operating system, they have the capability to be connected anytime that Windows is online. This includes the login screen! Even if I am sitting on the login or lock screen, and the system is waiting for me to input my username and password, as long as I have internet access I also have a DirectAccess tunnel, or an Always On VPN Device Tunnel. This means that I can actively do password management tasks. If my password expires and I need to update it, it works. If I forgot my password and I can’t get into my laptop, I can call the helpdesk and simply ask them to reset my password. I can then immediately log in to my DA or AOVPN laptop with the new password, right from my house.

Another cool function that this seamlessness enables is the ability to log in with new user accounts. Have you ever logged into your laptop as a different user account in order to test something? Yup, that works over DA and AOVPN as well. For example, I am sitting at home and I need to help one of the sales guys troubleshoot some sort of file permission problem. I suspect it’s got something to do with his user account, so I want to log in to my laptop as him in order to test it. The problem is that his user account has never logged into my laptop before. With VPN, not a chance; this would never work. With DirectAccess, piece of cake! I simply log off, type in his username and password, and bingo. I’m logged in, while still sitting at home in my pajamas.

It is important to note that you can run both DirectAccess and VPN connections on the same Windows Server 2019 Remote Access Server. This enables you to host clients who are connected via DA, via AOVPN, and also via traditional VPN connections if you have non-Win10 machines that need to connect. If any of these connectivity technologies have capabilities that you could benefit from, use them all!

Port-restricted firewalls

One of the other common VPN-related helpdesk calls has always been My VPN won’t connect from this hotel. Unfortunately, most protocols that VPNs use to connect are not firewall-friendly. Chances are that your router at home allows all outbound traffic, and so from your home internet connection everything is fine and dandy when connecting with a VPN protocol. But take that same laptop and connection over to a public coffee shop, or a hotel, or an airport, and suddenly the VPN fails to connect, with a strange error. This is usually caused by that public internet connection flowing its traffic through a port-restricting firewall. These firewalls restrict outbound access, oftentimes blocking things such as ICMP and UDP, which can interfere with VPN connections. In the most severe cases, these firewalls may only allow two outbound ports: TCP 80 for HTTP and TCP 443 for HTTPS website traffic. Then they block everything else.

In the event that you are sitting behind a port-restricted firewall, how do these newer remote access technologies handle connectivity?

DirectAccess is built to handle this scenario out of the box. Remember those three different protocols that DA can use to connect? The fallback option is called IP-HTTPS, and it flows its traffic inside TCP 443. So, even while sitting behind the most severe firewalls, DA will generally connect automatically and without hesitation.

Always On VPN is generally deployed (as it should be) with best-practices in mind, which includes prioritizing IKEv2 as the VPN connectivity protocol. In fact, some companies deploy AOVPN with only IKEv2. For these folks, a port-restricting firewall would be detrimental to that user’s VPN connection, as IKEv2 uses UDP ports to connect. It wouldn’t work. So, hopefully, the main point you take from this is that, when setting up AOVPN, make sure that you take the necessary steps to also enable SSTP VPN connectivity as a fallback method. SSTP also flows traffic inside TCP 443, which can then get outbound traffic, even through hardcore firewalls.

Super important:

The AOVPN Device Tunnel can only use IKEv2. If you are behind a port-restricting firewall and are relying on a Device Tunnel for connectivity, it’s not going to work. The AOVPN User Tunnel is the only one capable of doing SSTP fallback.

In fact, I recently worked on this exact scenario with someone who was trying to decide whether they wanted to set up DirectAccess or Always On VPN for their remote machines. This was a company that manages computers for numerous hospitals and doctors’ offices, and they did not have WAN links into those offices. The offices did have internet access though, and so we needed the ability to keep those computers automatically connected back to the main data center at all times. So far in the scenario, either DirectAccess or Always On VPN would fit the bill. Then, during testing, we discovered that many hospital networks restrict outbound internet access. The only way that DA would connect was via IP-HTTPS, and the only way that AOVPN would connect was via SSTP. Not a problem, right? Except that it was. You see, these remote workstations are often treated as kiosk, walk-up machines, where dozens of different employees could walk up at any moment and log into them. Oftentimes, this means that users are logging into these machines who have never logged into them before, so they don’t have cached credentials on those computers.

If you haven’t figured it out already, we had no choice but to go with DirectAccess in this scenario. DA is always connected at the login screen, even when using its “fallback” IP-HTTPS method. Always On VPN, however, can only do IKEv2 at the logon screen, because the Device Tunnel requires IKEv2. This uses UDP and was blocked by the firewall, so the only way that AOVPN would connect was by using SSTP, but that wasn’t available until the User Tunnel could launch, which was only after the user had logged into the machine. It was an extremely interesting real-world use case that helped shed some light on the decision-making process you may need to take for your own environments.

Manual disconnect

If you aren’t already convinced that old-school, traditional VPNs are yesterday’s news, let’s throw another point at you. When you use VPNs that require the user to manually launch the connection, you are relying on the user themselves to keep that machine managed, patched, and up to date. Sure, you may have automated systems that do these things for you, such as WSUS, SCCM, and Group Policy. But when the laptop is out and about, roaming around away from the LAN, those management systems can only do their jobs when the user decides to establish a VPN connection. It’s very possible that a laptop could spend weeks completely outside the corporate network, connecting to dozens of insecure hotspots while that employee works their way around the Caribbean on a cruise ship. After weeks of partying and Netflix, they then connect back into the LAN or via VPN to do some work, and wouldn’t you know it, that machine has been offline for so long that it’s picked up all kinds of fun and creative new software that you now have to deal with.

Not so with the Microsoft remote access tools! Providing an automatic connectivity option such as Always On VPN or DirectAccess means that the laptop would have been connected and receiving all of its security policies and patches during that entire vacation.

In fact, to take it one step further, on a DirectAccess-connected machine, the user cannot disable their DA tunnels even if they want to. You do have the ability to provide them with a Disconnect button, but that basically just fakes out the connection from the user’s perspective to make it feel to them like DA is offline. In reality, the IPsec tunnels are still flowing in the background, always allowing management-style tasks to happen.

Native load-balancing capabilities

To cut a long story short, DirectAccess is the winner here. The Remote Access Management Console in Windows Server 2019 has built-in capabilities for configuring and managing arrays of DA servers. You can stack multiple DA servers on top of each other, tie them together in load-balanced arrays, and provide redundancy and resiliency right from inside the console, without any extra hardware or traditional load-balancer consideration. You can even configure something called DirectAccess multisite, where you can configure DirectAccess servers that reside in different geographical locations together in arrays, giving cross-site resiliency. Almost every company that runs DirectAccess configures a redundant environment, providing either inner-site load balancing or multisite, or sometimes both, because these capabilities are built in and easy to configure.

Unfortunately, these capabilities are not (not yet, anyway) ported over into the Microsoft VPN world. Whether you are connecting Windows 7 clients via traditional VPN connectivity or getting Windows 10 clients to connect using Always On VPN, the backend infrastructure of RRAS VPN is the same, and has no built-in accommodation for multiple servers or sites. It is certainly possible to do so, making that VPN system redundant, but that would require you to set it up on your own by using external load balancers and, oftentimes, would require the use of global site/server load balancers to make that traffic flow properly.

Anyone who has set up load-balanced VPNs of any flavor in the past may be well aware of this process and be able to configure that easily, and that is great. But this is definitely a limiting factor for small business customers who have a limited number of servers, network equipment, and IT experience. All in all, the extra capabilities built into the console related to DirectAccess put it a step ahead of any VPN solution in terms of building up your remote access infrastructure to be resilient to failure.

Distribution of client configurations

The last primary consideration that you need to take into account when deciding which direction you want to go in for remote access is the method by which client-side settings get pushed down to their respective computers.

  • Third-party VPN: We have already discussed the downsides to dealing with software applications for third-party VPN vendors. If you can use something baked into the Windows operating system instead, that seems like a no-brainer.
  • Always On VPN: The recommended way to roll out AOVPN settings to client computers is through the use of an MDM solution, namely either SCCM or Intune. If you have one of these systems, rolling out AOVPN settings to your workforce is a breeze. If you do not have one of those systems, it is still possible, but not a straightforward process.
  • DirectAccess: I think DA’s approach to client settings distribution is definitely the easiest to work with, and the most flexible. You have to keep in mind that DirectAccess is only for your domain-joined systems. Given that you can expect all clients to be domain-joined, you have access to rolling DirectAccess connectivity settings out via Group Policy, which exists inside any Microsoft-driven infrastructure.

I genuinely hope that we will see a Group Policy distribution option added in the future for Always On VPN configuration rollouts. If such a capability were introduced, I am completely confident that it would immediately become the most popular way to roll out AOVPN settings.

To summarize this whole topic, when comparing DirectAccess against traditional, manual-launch VPNs, DA cleanly takes first prize. There really is no comparison. Now that we have Always On VPN at our disposal, the benefits of one over the other (DA or AOVPN) are quite fuzzy. They both accomplish a lot of the same things, but in different ways. The primary deciding factors for most customers so far seem to be client-side rollout capabilities, whether or not they have access to an MDM solution, and how important Device Tunnel connectivity is to them. Microsoft’s goal is for AOVPN to have feature parity with DirectAccess, and it’s getting close. Always On VPN also has some advanced authentication features that DirectAccess does not have, such as integration with Windows Hello for Business or Azure MFA.

Comments are closed.

loading...