Always On VPN Device Tunnel Missing in Windows 10 UI

Always On VPN Device Tunnel Missing in Windows 10 UIUnlike DirectAccess, Always On VPN connections are provisioned to the user, not the machine. Beginning with Windows 10 release 1709 Microsoft introduced the device tunnel option to provide feature parity with DirectAccess. The device tunnel provides pre-logon network connectivity to support important deployment scenarios such as logging on without cached credentials and unattended remote systems management.

Device Tunnel Configuration

Guidance for creating and deploying a device tunnel connection can be found here. It’s important to note that the device tunnel is always on by default. Also, there can only be a single device tunnel configured per device. You must remove an existing device tunnel before configuring a new one.

Known Issues

After configuring a Windows 10 Always On VPN device tunnel the administrator may notice two anomalies. First, the device tunnel is missing in the Windows UI after it is created. Second, viewing the status of the device tunnel connection using PowerShell indicates the connection is “disconnected” even though it is connected.

Device Tunnel Missing

As you can see below, event though both a device and user tunnel have been provisioned, the Windows UI reports only a single Always On VPN connection, that being the user connection.

Always On VPN Device Tunnel Missing in Windows 10 UI

However, the device tunnel does appear in the Network Connections control panel applet (ncpa.cpl), as shown here.

Always On VPN Device Tunnel Missing in Windows 10 UI

This is expected and by design. The device tunnel is not displayed to the user in the Windows UI as it is provisioned to the machine, not the user. It appears on the Control Panel because the applet is capable of enumerating both user and system connections.

Device Tunnel Disconnected

The status of the Windows 10 Always On VPN device tunnel connection can be viewed by running the Get-VpnConnection -AllUserConnection PowerShell command. However, at the time of this writing, PowerShell always reports the connection status as “Disconnected”. This appears to be a bug; one which Microsoft is hopefully working to address.

Always On VPN Device Tunnel Missing in Windows 10 UI

Summary

The Windows 10 Always On VPN device tunnel option allows administrators to enable scenarios previously supported with DirectAccess, including logging on without cached credentials and unattended remote support. Not all deployments require a device tunnel, but it is an important option available to administrators to address specific use cases.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN RasMan Device Tunnel Failure

Deleting a Windows 10 Always On VPN Device Tunnel

 

Comparing DirectAccess and NetMotion Mobility Webinar – October 2018

CORRECTION: This webinar will take place 14:00 BST on Thursday, 25 October.

DirectAccess on Windows Server 2016 CoreFor many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.

As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.

NetMotion Mobility as an Alternative to DirectAccessNetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.

To learn more about NetMotion Mobility, join me on Thursday, 25 October at 14:00 BST for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!

DirectAccess and NetMotion Mobility Webinar

Always On VPN Multisite with Azure Traffic Manager

Always On VPN Multisite with Azure Traffic ManagerEliminating single points of failure is crucial to ensuring the highest levels of availability for any remote access solution. For Windows 10 Always On VPN deployments, the Windows Server 2016 Routing and Remote Access Service (RRAS) and Network Policy Server (NPS) servers can be load balanced to provide redundancy and high availability within a single datacenter. Additional RRAS and NPS servers can be deployed in another datacenter or in Azure to provide geographic redundancy if one datacenter is unavailable, or to provide access to VPN servers based on the location of the client.

Multisite Always On VPN

Unlike DirectAccess, Windows 10 Always On VPN does not natively include support for multisite. However, enabling multisite geographic redundancy can be implemented using Azure Traffic Manager.

Azure Traffic Manager

Traffic Manager is part of Microsoft’s Azure public cloud solution. It provides Global Server Load Balancing (GSLB) functionality by resolving DNS queries for the VPN public hostname to an IP address of the most optimal VPN server.

Advantages and Disadvantages

Using Azure Traffic manager has some benefits, but it is not with some drawbacks.

Advantages – Azure Traffic Manager is easy to configure and use. It requires no proprietary hardware to procure, manage, and support.

Disadvantages – Azure Traffic Manager offers only limited health check options. Azure Traffic Manager’s HTTPS health check only accepts HTTP 200 OK responses as valid. Most TLS-based VPNs will respond with an HTTP 401 Unauthorized, which Azure Traffic Manager considers “degraded”. The only option for endpoint monitoring is a simple TCP connection to port 443, which is a less accurate indicator of endpoint availability.

Note: This scenario assumes that RRAS with Secure Socket Tunneling Protocol (SSTP) or another third-party TLS-based VPN server is in use. If IKEv2 is to be supported exclusively, it will still be necessary to publish an HTTP or HTTPS-based service for Azure Traffic Manager to monitor site availability.

Traffic Routing Methods

Azure Traffic Manager provide four different methods for routing traffic.

Priority – Select this option to provide active/passive failover. A primary VPN server is defined to which all traffic is routed. If the primary server is unavailable, traffic will be routed to another backup server.

Weighted – Select this option to provide active/active failover. Traffic is routed to all VPN servers equally, or unequally if desired. The administrator defines the percentage of traffic routed to each server.

Performance – Select this option to route traffic to the VPN server with the lowest latency. This ensures VPN clients connect to the server that responds the quickest.

Geographic – Select this option to route traffic to a VPN server based on the VPN client’s physical location.

Configure Azure Traffic Manager

Open the Azure management portal and follow the steps below to configure Azure Traffic Manager for multisite Windows 10 Always On VPN.

Create a Traffic Manager Resource

  1. Click Create a resource.
  2. Click Networking.
  3. Click Traffic Manager profile.

Create a Traffic Manager Profile

  1. Enter a unique name for the Traffic Manager profile.
  2. Select an appropriate routing method (described above).
  3. Select a subscription.
  4. Create or select a resource group.
  5. Select a resource group location.
  6. Click Create.

Always On VPN Multisite with Azure Traffic Manager

Important Note: The name of the Traffic Manager profile cannot be used by VPN clients to connect to the VPN server, since a TLS certificate cannot be obtained for the trafficmanager.net domain. Instead, create a CNAME DNS record that points to the Traffic Manager FQDN and ensure that name matches the subject or a Subject Alternative Name (SAN) entry on the VPN server’s TLS and/or IKEv2 certificates.

Endpoint Monitoring

Open the newly created Traffic Manager profile and perform the following tasks to enable endpoint monitoring.

  1. Click Configuration.
  2. Select TCP from the Protocol drop-down list.
  3. Enter 443 in the Port field.
  4. Update any additional settings, such as DNS TTL, probing interval, tolerated number of failures, and probe timeout, as required.
  5. Click Save.

Always On VPN Multisite with Azure Traffic Manager

Endpoint Configuration

Follow the steps below to add VPN endpoints to the Traffic Manager profile.

  1. Click Endpoints.
  2. Click Add.
  3. Select External Endpoint from the Type drop-down list.
  4. Enter a descriptive name for the endpoint.
  5. Enter the Fully Qualified Domain Name (FQDN) or the IP address of the first VPN server.
  6. Select a geography from the Location drop-down list.
  7. Click OK.
  8. Repeat the steps above for any additional datacenters where VPN servers are deployed.

Always On VPN Multisite with Azure Traffic Manager

Summary

Implementing multisite by placing VPN servers is multiple physical locations will ensure that VPN connections can be established successfully even when an entire datacenter is offline. In addition, active/active scenarios can be implemented, where VPN client connections can be routed to the most optimal datacenter based on a variety of parameters, including current server load or the client’s current location.

Additional Information

Windows 10 Always On VPN Hands-On Training Classes

Always On VPN Hands On Training Classes Coming to Dallas and San Francisco

Windows 10 Always On VPN Hands-On Training Classes for 2018Two more dates for my popular three-day Windows 10 Always On VPN Hands-On Training classes have been added to the schedule for 2018! Classes are now forming in Dallas, October 23-25 and in San Francisco, November 13-15, 2018. These training classes will cover all aspects of designing, implementing, and supporting an Always On VPN solution in the enterprise. The following topics will be covered in detail.

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability+
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Windows 10 Always On VPN Hands-On Training Classes for 2018

Register Today

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

Group discounts are available! Private training sessions for large organizations are also available upon request.

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Certificate Requirements for SSTPThe Windows Server 2016 Routing and Remote Access Service (RRAS) is commonly deployed as a VPN server for Windows 10 Always On VPN deployments. Using RRAS, Always On VPN administrators can take advantage of Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP) VPN protocol. SSTP is a Transport Layer Security (TLS) based VPN protocol that uses HTTPS over the standard TCP port 443 to encapsulate and encrypt communication between the Always On VPN client and the RRAS VPN server. SSTP is a firewall-friendly protocol that ensures ubiquitous remote network connectivity. Although IKEv2 is the protocol of choice when the highest level of security is required for VPN connections, SSTP can still provide very good security when implementation best practices are followed.

SSTP Certificate

Since SSTP uses HTTPS for transport, a common SSL certificate must be installed in the Local Computer/Personal/Certificates store on the RRAS VPN server. The certificate must include the Server Authentication Enhanced Key Usage (EKU) at a minimum. Often SSL certificates include both the Server Authentication and Client Authentication EKUs, but the Client Authentication EKU is not strictly required. The subject name on the certificate, or at least one of the Subject Alternative Name entries, must match the public hostname used by VPN clients to connect to the VPN server. Multi-SAN (sometimes referred to as UC certificates) and wildcard certificates are supported.

Always On VPN Certificate Requirements for SSTP

Certification Authority

It is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure. This reduces the chance of failed VPN connection attempts caused by the CRL being offline or unreachable.

Using an SSL certificate issued by an internal, private CA is supported if the CRL for the internal PKI is publicly available.

Key Type

RSA is the most common key type used for SSL certificates. However, Elliptic Curve Cryptography (ECC) keys offer better security and performance, so it is recommended that the SSTP SSL certificate be created using an ECC key instead.

Always On VPN Certificate Requirements for SSTP

To use an ECC key, be sure to specify the use of a Cryptographic Next Generation (CNG) key and select the ECDSA_P256 Microsoft Software Key Storage Provider (CSP) (or greater) when creating the Certificate Signing Request (CSR) for the SSTP SSL certificate.

Always On VPN Certificate Requirements for SSTP

Most public CAs will support certificate signing using ECC and Elliptic Curve Digital Signature Algorithm (ECDSA). If yours does not, find a better CA. 😉

Forward Secrecy

Forward secrecy (sometimes referred to as perfect forward secrecy, or PFS) ensures that session keys can’t be compromised even if the server’s private key is compromised. Using forward secrecy for SSTP is crucial to ensuring the highest levels of security for VPN connections.

To enforce the use of forward secrecy, the TLS configuration on the VPN server should be prioritized to prefer cipher suites with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Authenticated Encryption

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption that provides better data protection and integrity compared to older block or stream ciphers such as CBC or RC4.

To enforce the use of authenticated encryption, the TLS configuration on the VPN server should be prioritized to prefer cipher suites that support Galois/Counter Mode (GCM) block ciphers.

Important Note: In Windows Server 2016, GCM ciphers can be used with both RSA and ECC certificates. However, in Windows Server 2012 R2 GCM ciphers can only be used when an ECC certificate is used.

SSL Offload

Offloading SSL to a load balancer or application delivery controller (ADC) can be enabled to improve scalability and performance for SSTP VPN connections. I will cover SSL offload for SSTP in detail in a future post.

Summary

SSTP can provide good security for VPN connections when implementation and security best practices are followed. For optimum security, use an SSL certificate with an EC key and optimize the TLS configuration to use forward secrecy and authenticated cipher suites.

Additional Information

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN Certificate Requirements for IKEv2

3 Important Advantages of Always On VPN over DirectAccess

Microsoft SSTP Specification on MSDN

Comparing DirectAccess and NetMotion Mobility

Comparing DirectAccess and NetMotion Mobility With DirectAccess approaching the end of its useful lifetime, many organizations are considering alternative solutions to provide seamless, transparent, always on remote connectivity for their field-based workers. Microsoft is positioning Windows 10 Always On VPN as the replacement for DirectAccess. While it provides many new features that were missing from DirectAccess, it has its own unique limitations and shortcomings.

NetMotion Mobility

Comparing DirectAccess and NetMotion Mobility NetMotion Mobility is an excellent alternative to DirectAccess and Always On VPN, and it has many advantages over both native Microsoft offerings. NetMotion Mobility offers better security and performance. It provides deep visibility with broad client support, and the solution is easier to support than DirectAccess.

Comparing DirectAccess and NetMotion Mobility

If you’d like to learn more about how NetMotion Mobility compares with DirectAccess, you will find detailed comparison information in my Comparing NetMotion Mobility and DirectAccess article series on the NetMotion blog.

Comparing NetMotion Mobility and DirectAccess – Security
Comparing NetMotion Mobility and DirectAccess – Performance
Comparing NetMotion Mobility and DirectAccess – Visibility
Comparing NetMotion Mobility and DirectAccess – Supported Clients
Comparing NetMotion Mobility and DirectAccess – Support

NetMotion Mobility in Action

Watch the following videos to see NetMotion Mobility in action.

NetMotion Mobility Demonstration Video
NetMotion Mobility and Skype for Business Demonstration Video

DirectAccess Alternative

NetMotion Mobility is a premium remote access solution with many of the same characteristics as DirectAccess; seamless, transparent, and always on. It is feature rich with numerous compelling benefits over native Microsoft remote access technologies. Organizations seeking a solution to replace Microsoft DirectAccess would benefit greatly from NetMotion Mobility.

Learn More

If you’d like to learn more about NetMotion Mobility, or if you’d like to evaluate their solution, fill out the form below and I’ll respond with more information.

DirectAccess Selective Tunneling

DirectAccess Selective TunnelingDirectAccess administrators, and network administrators in general, are likely familiar with the terms “split tunneling” and “force tunneling”. They dictate how traffic is handled when a DirectAccess (or VPN) connection is established by a client. Split tunneling routes only traffic destined for the internal network over the DirectAccess connection; all other traffic is routed directly over the Internet. Force tunneling routes all traffic over the DirectAccess connection.

Force Tunneling

DirectAccess uses split tunneling by default. Optionally, it can be configured to use force tunneling if required. Force tunneling is commonly enabled when DirectAccess administrators want to inspect and monitor Internet traffic from field-based clients.

Note: One-time password user authentication is not supported when force tunneling is enabled. Details here.

Drawbacks

Force tunneling is not without its drawbacks. It requires that an on-premises proxy server be used by DirectAccess clients to access the Internet, in most cases. In addition, the user experience is often poor when force tunneling is enabled. This is caused by routing Internet traffic, which is commonly encrypted, over an already encrypted connection. The added protocol overhead caused by double encryption (triple encryption if you are using Windows 7!) along with using a sub-optimal network path increases latency and can degrade performance significantly. Also, location-based services typically fail to work correctly.

Selective Tunneling

“Selective Tunneling” is a term that I commonly use to describe a configuration where only one or a few specific public resources are tunneled over the DirectAccess connection. A common use case is where access to a cloud-based application is restricted to the IP address of a corporate proxy or firewall.

Using the Name Resolution Policy Table (NRPT) and taking advantage of DirectAccess and its requirement for IPv6, DirectAccess administrators can choose to selectively route requests for public hosts or domains over the DirectAccess connection. The process involves defining the public Fully Qualified Domain Name (FQDN) as “internal” in the DirectAccess configuration and then assigning an on-premises proxy server for DirectAccess clients to use to access that namespace.

Enable Selective Tunneling

While some of the selective tunneling configuration can be performed using the Remote Access Management console, some of it can only be done using PowerShell. For this reason, I prefer to do everything in PowerShell to streamline the process.

Run the following PowerShell commands on the DirectAccess server to enable selective tunneling for the “.example.com” domain.

$namespace = “.example.com” # include preceding dot for namespace, omit for individual host
$dnsserver = Get-ItemPropertyValue –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters -Name DnsServers

Add-DAClientDnsConfiguration -DnsSuffix $namespace -DnsIpAddress $dnsserver -PassThru

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $rule -GpoName $gpo

If Windows 7 client support has been enabled, run the following PowerShell commands on the DirectAccess server. If multisite is enabled, run these commands on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $downlevelrule -GpoName $downlevelgpo

To remove a namespace from the NRPT, run the following PowerShell command.

Remove-DAClientDnsConfiguration -DnsSuffix $namespace

Caveats

While selective tunneling works well for the most part, the real drawback is that only Microsoft browsers (Internet Explorer and Edge) are supported. Web sites configured for selective tunneling will not be reachable when using Chrome, Firefox, or any other third-party web browser. In addition, many web sites deliver content using more than one FQDN, which may cause some web pages to load improperly.

Additional Resources

DirectAccess Force Tunneling and Proxy Server Configuration

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Deleting an Always On VPN Device Tunnel

Deleting an Always On VPN Device TunnelWindows 10 Always On VPN supports both a user tunnel for corporate network access, and a device tunnel typically used to provide pre-logon network connectivity and to support manage out scenarios. The process of testing Always On VPN is often an iterative one involving trial and error testing to fine tune the configuration parameters to achieve the best experience. As a part of this process it will often be necessary to delete a connection at some point. For the user tunnel the process is simple and straightforward. Simply disconnect the session and delete the connection in the UI.

Deleting an Always On VPN Device Tunnel

Deleting a device tunnel connection presents a unique challenge though. Specifically, there is no VPN connection in the UI to disconnect and remove. To delete an Always On VPN device tunnel, open an elevated PowerShell window and enter the following command.

Get-VpnConnection -AllUserConnection | Remove-VpnConnection -Force

If the device tunnel is connected when you try to remove it, you will receive the following error message.

The VPN connection [connection_name] cannot be removed from the global user connections. Cannot
delete a connection while it is connected.

Deleting an Always On VPN Device Tunnel

The device tunnel must first be disconnected to resolve this issue. Enter the following command to disconnect the device tunnel.

rasdial.exe [connection_name] /disconnect

Remove the device tunnel connection using PowerShell once complete.

Deleting an Always On VPN Device Tunnel
Additional Resources

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

What’s The Difference Between DirectAccess and Always On VPN?

Windows 10 Always On VPN Recommendations for Windows Server 2016 Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN Hands-On Training

What is the Difference Between DirectAccess and Always On VPN?

Always On VPN Device Tunnel Configuration Guidance Now AvailableDirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.

Security

DirectAccess provides full network connectivity when a client is connected remotely. It lacks any native features to control access on a granular basis. It is possible to restrict access to internal resources by placing a firewall between the DirectAccess server and the LAN, but the policy would apply to all connected clients.

Windows 10 Always On VPN includes support for granular traffic filtering. Where DirectAccess provides access to all internal resources when connected, Always On VPN allows administrators to restrict client access to internal resources in a variety of ways. In addition, traffic filter policies can be applied on a per-user or group basis. For example, users in accounting can be granted access only to their department servers. The same could be done for HR, finance, IT, and others.

Authentication and Management

DirectAccess includes support for strong user authentication with smart cards and one-time password (OTP) solutions. However, there is no provision to grant access based on device configuration or health, as that feature was removed in Windows Server 2016 and Windows 10. In addition, DirectAccess requires that clients and servers be joined to a domain, as all configuration settings are managed using Active Directory group policy.

Windows 10 Always On VPN includes support for modern authentication and management, which results in better overall security. Always On VPN clients can be joined to an Azure Active Directory and conditional access can also be enabled. Modern authentication support using Azure MFA and Windows Hello for Business is also supported. Always On VPN is managed using Mobile Device Management (MDM) solutions such as Microsoft Intune.

Performance

DirectAccess uses IPsec with IPv6, which must be encapsulated in TLS to be routed over the public IPv4 Internet. IPv6 traffic is then translated to IPv4 on the DirectAccess server. DirectAccess performance is often acceptable when clients have reliable, high quality Internet connections. However, if connection quality is fair to poor, the high protocol overhead of DirectAccess with its multiple layers of encapsulation and translation often yields poor performance.

The protocol of choice for Windows 10 Always On VPN deployments is IKEv2. It offers the best security and performance when compared to TLS-based protocols. In addition, Always On VPN does not rely exclusively on IPv6 as DirectAccess does. This reduces the many layers of encapsulation and eliminates the need for complex IPv6 transition and translation technologies, further improving performance over DirectAccess.

Supportability

DirectAccess is a Microsoft-proprietary solution that must be deployed using Windows Server and Active Directory. It also requires a Network Location Server (NLS) for clients to determine if they are inside or outside the network. NLS availability is crucial and ensuring that it is always reachable by internal clients can pose challenges, especially in very large organizations.

Windows 10 Always On VPN supporting infrastructure is much less complex than DirectAccess. There’s no requirement for a NLS, which means fewer servers to provision, manage, and monitor. In addition, Always On VPN is completely infrastructure independent and can be deployed using third-party VPN servers such as Cisco, Checkpoint, SonicWALL, Palo Alto, and more.

Summary

Windows 10 Always On VPN is the way of the future. It provides better overall security than DirectAccess, it performs better, and it is easier to manage and support.

Here’s a quick summary of some important aspects of VPN, DirectAccess, and Windows 10 Always On VPN.

Traditional VPN DirectAccess Always On VPN
Seamless and Transparent No Yes Yes
Automatic Connection Options None Always on Always on, app triggered
Protocol Support IPv4 and IPv6 IPv6 Only IPv4 and IPv6
Traffic Filtering No No Yes
Azure AD Integration No No Yes
Modern Management Yes No (group policy only) Yes (MDM)
Clients must be domain-joined? No Yes No
Requires Microsoft Infrastructure No Yes No
Supports Windows 7 Yes Yes Windows 10 only

Always On VPN Hands-On Training

If you are interested in learning more about Windows 10 Always On VPN, consider registering for one of my hands-on training classes. More details here.

Additional Resources

Always On VPN and the Future of Microsoft DirectAccess

5 Important Things DirectAccess Administrators Should Know about Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over DirectAccess

Always On VPN Hands-On Training Coming to Chicago

Windows 10 Always On VPN Hands-On Training Classes for 2018Recently I announced the availability of Windows 10 Always On VPN hands-on training classes. The first class is set for March 27-29 in Los Angeles. By popular demand, I’m pleased to announce that I’ll be delivering another class April 10-12 in Chicago. This training class will cover all aspects of designing, implement, and supporting an Always On VPN solution in the enterprise. These three-day courses will cover topics including…

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability+
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Windows 10 Always On VPN Hands-On Training Classes for 2018

Register Today

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

%d bloggers like this: