- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
- SmartDeploy: Easy software and OS deployment - Tue, Oct 1 2019
DirectAccess is a bit of a snob, always talking about Teredo tunneling and IPv6, only hanging out with the Enterprise clients. While I exaggerate just a little, DirectAccess can be intimidating to set up and limiting in implementation. For the most part, Microsoft has stopped improving DirectAccess. Instead, their focus is Always On VPN. Beginning in Windows 10 1607, Microsoft changed their recommendation for VPN connectivity. With Windows 10 1607 clients, Microsoft recommends "that you use Always On VPN instead of DirectAccess."
Always On VPN has three overlapping technology segments (server, client, and network). We are going to start with an overview of Always On VPN and cover the components required for setup. The second article will cover server setup. Article three will outline client configurations and connections. The final piece will cover network changes, advanced configurations, and additional troubleshooting. Before we look at the components, let's see why Always On VPN is the recommended form of remote access.
The Always On VPN is ready to connect
VPNs, DirectAccess, and Always On: a comparison ^
Unlike a traditional VPN, this iteration of Remote Access is designed to be persistent. A user automatically connects to your network by connecting to any external network. With 1607, we can configure this on a per-user basis, and the VPN client uses your rules to decide when to connect automatically.
It can connect upon launching certain applications, when looking for certain hosts, or stay in an always-connected state. With 1709, we can configure device connections as well. This can allow users to log on to a new laptop at an offsite location. In other words, it eliminates the whole there are currently no logon servers available paradox. Traffic in both versions is two way and management capable. Offsite clients can process Group Policy, receive updates, and even be remotely controlled. In part three, we will configure these connection rules. This setup uses the native Windows 10 1607+ VPN client. Users can enroll without having to install any additional client software.
Unlike DirectAccess, Always On VPN is a dual stack technology. It supports IPv4 and IPv6. As you will see in part four, this will make your firewall configuration much easier.
Where DirectAccess required domain-joined Enterprise or Education edition clients, Always On does not require those specific Windows 10 editions. Clients do not even need to be domain joined.
For advanced deployments, it can integrate with Windows Hello for Business as well as Azure Multi-Factor Authentication (MFA). While the server and network configuration for Always On VPN is simpler than DirectAccess, traditional client configuration is not.
Currently, you have to configure the Always On VPN client through PowerShell, SCCM, or Intune. There is not a native Always On VPN client-side extension for Group Policy. It is possible to automate PowerShell enrollment for organizations without SCCM or Intune. This requires changes to the default client configuration scripts though. The third article of this series will cover this part as well.
Where to configure Always On VPN ^
Always On VPN ties together many different technologies. First, you need to configure a set of servers—Network Policy Server (NPS), Certificate Authority (CA), and Remote Access. Next, you have to enroll clients (users at first, 1709+ devices for pre-logon connections). Finally, you have to connect your remote clients to your on-premises infrastructure securely through several network changes. All three sections overlap a bit, but we will break them up into logical segments.
The Always On VPN server infrastructure relies on technologies you have probably already deployed. Other than your DC/DNS servers, this configuration requires a NPS (RADIUS) server, a CA server, and a Remote Access (Routing/VPN) server. These servers do not need to be at 2016. 2012 R2 servers will work just fine. This series will assume that you already have servers with those roles enabled on them and that you just need to make the modifications necessary for the Always On VPN setup.
Along with the NPS, CA, and Remote Access servers, you will need a bit of network configuration. Remote clients will connect over UDP ports 500 and 4500 to your Remote Access server. This section will focus on a single server setup. Organizations should use failover or a load balancer for high availability though. This Remote Access server will straddle your public network and private network. If physical, it will require two network interface controllers (NICs). Virtual machines (VMs) will require correct virtual LAN (VLAN) placement for the host.
The Remote Access server will need a public DNS record and a client-trusted certificate installed on it. The certificate name will need to match the Remote Access server name. The steps in this part of the guide will be generic because there are so many types of firewalls, routers, and switches. The VM discussion will focus on Hyper-V.
Clients interact with this setup by talking to the CA first. Let's look at a user on a remote device. To authenticate, this user's device would need a specific VPN certificate issued to it. In this guide, we will use Active Directory (AD) security groups to issue this certificate to selected users automatically. The user profile on the remote device would already have the Always On VPN connection configured. This connection checks the network status on a defined basis. When the status matches rules you configure, it initiates a connection to the public interface of your Remote Access server.
The Remote Access server, through the internal interface, validates this request against your Network Policy server. If the connection request is valid, it allows clients to connect and places them in an IP pool you specify during the Remote Access server setup.
Depending on your network configuration, you can constrain clients to certain network segments or allow them normal on-premises-like access.
The configuration required for Always On VPN setup overlaps server, network, and client setup. In part two, we will walk through the server setup required for an Always On VPN environment. As you proceed through this guide, refer back to this post if you are confused about where items tie together.