Always On VPN - DirectAccess+ for Windows 10

Always On VPN is easy to use and easy to implement. Follow this four-part guide as we turn Remote Access into a seamless and persistent connection for your Windows 10 mobile devices.

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.

Manually setting advanced properties for Always On VPN adapters

Manually setting advanced properties for Always On VPN adapters

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.

DirectAccess and the (Always On) VPN server roles

DirectAccess and the (Always On) VPN server roles

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.

IPv4 and IPv6 settings on the Remote Access server

IPv4 and IPv6 settings on the Remote Access server

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.

Want to write for 4sysops? We are looking for new authors.

Read 4sysops without ads by becoming a member!

  1. Alex Hansen 3 years ago

    Looking forward for the next part of this series!


  2. Author

    Thanks Alex - here is part 2:


  3. Chris Glasier 3 years ago

    A lot like the older remote access, at another job we used health certificates making sure the system met certain requirements before allowing the client to connect.  If it didn't meet certain criteria the client was direct to a DMZ area where things like AV was updated and firewall issues were resolved, then when the health cert rules were met the client was allowed to connect.


    • Author

      Yep - you are right that it is very similar to Remote Access with Network Access Protection. I guess, what is old is new again.


  4. Diemtar 2 years ago

    Hi! Great posts! Thank you very much! However, I have two questions. First: How to configure the internal and external ipv4 adapter address? Internal adapter: IP address, subnet mask, gateway? dns servers?; External adapter: ip address, subnet mask, gateway?, dns servers?. DirectAccess allows no gateway configuration on internal adapter and no dns server configuration on external adapter. Is it possible to get screenshots of the ipv4 configuration of the network adapters?

    Second: If I enable the RemoteAccess Service on that machine neither remote desktop nor ping works. Did you encounter the same problems. How did you solve this?

    Thank you very much. Dietmar


    • Author

      You don't need a gateway for your internal adapter but everything else is fine. External needs a gateway but no DNS is fine.

      The remote access service issue sounds like a firewall problem. Did you find out a solution to that problem?


      • Dietmar 2 years ago

        This server is placed between two firewall and my colleagues misconfigured some NAT stuff... It had nothing to do with the server itself or routing service...


  5. Tor Marius 2 years ago


    i have installed Always on VPN and it works like a charm, the only thing idont quite get is how i can give this to a nondomain joined computer(for external users). is that possible?




    • Author

      It is possible. If you have intune, it is easier - just create the profile and push it to the managed client.

      If the machine is managed only by the external user, it is a bit more work. You will need to get a user a certificate that they can use and get it installed on the remote machine. You then need to create the VPN profile using the setup script.


  6. Tor Marius 1 year ago

    thank you for the answer.

    how can i issue a certificate to a user that is not in the domain?
    i tried to create a user in my domain with the same name that the external consulent is using on his computer. i then tried to give him that certificate, but i got this errormesage:

    Cant connect to Alwayson
    A certificate could not be
    used with this extensible authentication protocol


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account