Always On VPN is a new Remote Access solution from Microsoft. It meets the needs of information workers using remote or roaming computers to access resources on the private corporate network. It’s known as “the new DirectAccess” because DirectAccess (DA) is no longer being developed. Always On VPN is simpler to deploy than DA, but it only supports Microsoft Windows Server 2016 and Windows 10 version 1607 and later as VPN clients.

Moving on from DirectAccess

When Microsoft released Forefront Unified Access Gateway (UAG) in 2007, it included a new feature for Microsoft: DirectAccess (DA). DA has lived on in Windows Server as an optional Remote Access role service.

For several reasons, not the least of which is a complex dependency on Group Policy, DA has not been adopted widely and successfully. The successor solution for easy remote worker client connectivity is called Always On VPN.

Feature Comparison of Always On VPN and DirectAccess

Always On VPN has more configuration options than DirectAccess (DA) and in that sense, has improved functionality. The primary VPN protocols supported are IKE v2 and SSTP (TLS). Here are some distinguishing differences between DA and Always On VPN:

• All Windows 10 editions work: DA only worked in the AD domain model and required specific Windows client SKUs (precluding BYOD). Always On VPN does not require an AD domain and works with all Windows 10 client editions allowing for BYOD scenarios.
• No NAT64: DA used rather complex IPv6 translation services to function. Always On VPN uses a dual IPv4/IPv6 stack that doesn’t depend on NAT64/DNS64 translation services.
• No Global Entry: DA had a sophisticated global access point mechanism that provided multiple remote access entry points and geo-redundancy. Always On VPN has no native multisite-equivalent feature without the use of third-party networking equipment or services such as Azure Traffic Manager or a third-party global server load balancer. (Users can manually select an appropriate VPN endpoint if you define multiple entries in the Always On VPN profile.)
• No AD (or GPO) Needed: DA required AD domain Group Policy, while Always on VPN has no dependency on AD or group policy. Instead with Always On VPN, you configure clients by using Windows PowerShell, System Center Configuration Manager, or Intune (or a third-party MDM provider) to create a VPN connection.
• Infrastructure Independence: The back-end of the solution is partially infrastructure independent, that is: The VPN server(s) and RADIUS server(s), can be all-Windows Servers or you can switch out third-party VPN and RADIUS providers. You will still need a Microsoft NPS server (that can point to your third-party RADIUS).

How does Always On VPN work

Think of Always On VPN as a Microsoft-standard RAS back-end that requires certificates for authentication, and a scripted modification to a client PC that creates a VPN connection (a WAN miniport network adapter) with the desired policies enforced. There are no infrastructure features to install specific to Always On VPN.

Server-side: Familiar Microsoft server technologies like Network Policy Server (NPS), Certificate Authority (CA), and Remote Access are used to create the Always On VPN environment.

Client-side: The client side is controlled by declarative RAS client policy, applied by running a PowerShell script on the client computer. SCCM and InTune are supported to deploy the client configuration as well.

• One or more Remote Access Servers (RAS) in a dual-firewalled perimeter network receive inbound Windows 10 client requests to connect.
• The RAS servers have two NICs each, one Internet-facing NIC on the external perimeter network and the other NIC on the internal perimeter network.
• The RAS server checks with a RADIUS server inside the private network. Figure 1 shows the connection process for Always On VPN.

Figure 1- Infrastructure that is required to deploy Always On VPN

The connection process depicted in Figure 1 is comprised of the following steps: (source: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/always-on-vpn-technology-overview )

1. Using public DNS servers, the VPN client performs a name resolution query for the IP address of the VPN gateway. [Windows Server or third party VPN provider.]
2. Using the IP address returned by DNS, the built-in Windows 10 or Windows Server 2016 VPN client (configured with Always on VPN settings) sends a connection request to the VPN gateway.
3. The VPN gateway is also configured as a Remote Authentication Dial In User Service (RADIUS) Client; the VPN RADIUS Client sends the connection request to the organization/corporate NPS server for connection request processing. [Windows Server or third party RADIUS provider.]
4. The NPS server processes the connection request, including performing authorization and authentication, and determines whether to allow or deny the connection request.
5. The NPS server forwards an Access-Accept or Access-Deny response to the VPN gateway.
6. The connection is initiated or terminated based on the response that the VPN server received from the NPS server.

VPN deployment modes and DirectAccess migrations

New with Always On VPN are configuration options around device or user authentication–unlike DA which was only device-centric. Always On VPN, like DirectAccess, does require a PKI infrastructure. You can use a domain CA and AD domain GPO to issue device and/or user certificates, as well as any third party CA and certificate issuing method.

• Device-centric: In one mode, Always On VPN uses device certificates and device-initiated connection through a feature called Device Tunnel. That connection can be initiated automatically and is persistent, resembling a DirectAccess infrastructure tunnel connection. The Device Tunnel can be specific to route to corporate networks, or you can configure policies to require all traffic to flow though the corporate firewall, that is, no Internet without VPN.
• User-centric: By using user certificates, the Always On VPN client connects automatically, but it does so at the user level (after user sign-in) instead of at the device level (before user sign-in). The experience is still seamless to the user, but it supports more advanced authentication mechanisms, like Windows Hello for Business (think biometric sign-in including facial recognition) and Azure Multi-Factor Authentication (MFA).

Tips to consider when migrating from DirectAccess to Always On VPN:

• Start with configuration options that are comparable to what you have (like computer authentication, as in DA), and then move to other modes as business needs indicate (such as user authentication with other service integration).
• Also consider that funneling all device Internet traffic through corporate anti-malware services results in better network security by reducing the attack surface of roaming computers.
• The computer certificates you deployed for DA will work as computer certificates with Always On VPN. You may well need to add user certificates to your PKI operations planning and support since issuing user certificates is less common than computer certificates in many enterprises.

Configure and Test the Always On VPN Client connection

All the magic of the Always On VPN is in the VPN client connection file imported to the Windows 10 or Windows Server 2016 computer.

The profile is created by a script named VPN_Profile.ps1, and you generate the script from a computer that is already successfully connected via RAS (in your desired Always On VPN configuration) using a manually-configured VPN profile named “template”.

1. On the computer with the working “template” VPN connection, download the latest MakeProfile.ps1 script from Microsoft: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections#bkmk_fullscript
2. Edit MakeProfile.ps1 to configure the parameters at the top of the file similar to that shown in Figure 2. The $DnsSuffix, $TrustedNetwork, and $DomainName parameters will usually be the same, except for $DomainName having a leading dot (“.”).

    

   

Figure 2- Modify the sections in the green box at the top of MakeProfile.ps1, name your model VPN connection ‘template’

1. Run MakeProfile.ps1 in an elevated PowerShell session on the client computer. The “template” VPN connection information will be merged with the edited parameters to create the files “VPN_Profile.PS1” and “VPN_Profile.xml” on the Desktop. These are the only two files you need to proceed to deploy Always On VPN.
2. Install the Always On VPN client VPN connection via these methods:
   1. Local: Run VPN_Profile.PS1 locally in an elevated PowerShell session
   2. SCCM: Distribute VPN_Profile.PS1 via SCCM as a standard PowerShell script
   3. InTune: Include VPN_Profile.xml as Custom XML in a Windows 10 VPN setting
3. Test the Always On VPN client as follows:
   1. After applying the VPN client configuration by scripting or automation, connect the computer to your internal network. The Always On VPN client configuration will show you are internally connected by comparing the client DNS suffix value with the VPN policy.
   2. Move the computer to an external network. Within a few seconds, Windows should detect the change in network location and automatically start the Always On VPN profile.

Tags: #MVPBuzz #WinServ #PowerShell #VPNClient #DirectAccess #sysctr #SCCM #InTune