Always On VPN Hands-On Training Classes Coming to Denver and New York

Windows 10 Always On VPN Hands-On Training Classes for 2018I’m pleased to announce that I will be bringing my popular three-day Windows 10 Always On VPN Hands-On Training classes to Denver and New York in May and June! Join me May 15-17, 2018 in Denver or June 5-7, 2018 in New York. These training classes 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

Registration is now open for Denver and New York. In addition, spots are still available for the Los Angeles and Chicago sessions. 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.

DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance IssuesPerformance issues with DirectAccess are not uncommon. In fact, there are numerous threads on Microsoft and third-party forums where administrators frequently complain about slow download speeds, especially when using the IP-HTTPS IPv6 transition technology. Based on my experience the problem does not appear to be widespread but occurs with enough regularity that it is worthy of further investigation.

DirectAccess Design

The inherent design of DirectAccess is a major limiting factor for performance. DirectAccess uses a complex and heavy communication channel, with multiple layers of encapsulation, encryption, and translation. Fundamentally it is IPsec encrypted IPv6 traffic, encapsulated in HTTP, and then encrypted with Transport Layer Security (TLS) and routed over IPv4. It is then decrypted, decapsulated, decrypted again, then converted back to IPv4. The high protocol overhead incurred with multiple layers of encapsulation, encryption, and translation result in increased packet fragmentation, which further reduces performance.

DirectAccess Performance

Even under the best circumstances, DirectAccess performance is limited by many other factors, most notably the quality of the network connection between the client and the server. DirectAccess performs reasonably well over high bandwidth, low latency connections. However, network performance drops precipitously as latency increases and packet loss is encountered. This is to be expected given the design of the solution.

Intermediary Devices

It is not uncommon to find intermediary devices like firewalls, intrusion detection systems, malware scanners, and other security inspection devices limit the performance of DirectAccess clients. In addition, many security appliances have bandwidth caps enforced in software for licensing restrictions. Further, incorrect configuration of inline edge devices can contribute to increased fragmentation, which leads to poor performance as well.

Slow Downloads over IP-HTTPS

Many people report that download speeds seem to be artificially capped at 355Kbps. While this seems to be a display bug in the UI, there is plenty of evidence to indicate that, in some scenarios, DirectAccess is incapable of high throughput even over high-quality connections. Some who have deployed DirectAccess and VPN on the same server have reported that download speeds are only limited when using DirectAccess over IP-HTTPS and not with VPN using Secure Socket Tunneling Protocol (SSTP), which also uses TLS. This has led many to speculate that the issue is either a bug or a design flaw in the IP-HTTPS tunnel interface itself.

TCP Window Scaling Issues

In some of the network traces I’ve analyzed I’ve seen evidence that seems to support this theory. For example, a network trace taken when downloading a file over DirectAccess with IP-HTTPS showed the TCP window never scaled beyond 64K, which would seriously impede performance. Interestingly this doesn’t seem to happy when the client uploads files over IP-HTTPS. Clearly something unusual is happening.

Microsoft KB Article

Microsoft recently released a vaguely-worded KB article that appears to lend credence to some of these findings. The article seems to acknowledge the fact there are known issues with DirectAccess performance, but it lacks any specific details as to what the root cause is. Instead, it simply advises migrating to Windows 10 Always On VPN.

Summary

DirectAccess IP-HTTPS performance issues don’t appear to affect everyone, and the problem only seems to apply to file downloads and not to other types of traffic. However, there is mounting evidence of a systemic issue with DirectAccess performance especially over IP-HTTPS. Customers are advised to closely evaluate their uses cases for DirectAccess and if remote clients are frequently required to download large files over a DirectAccess connection, an alternative method of file transfer might be required. Optionally customers can consider evaluating alternative remote access solutions that offer better performance such as Windows 10 Always On VPN or third-party solutions such as NetMotion Mobility.

Additional Resources

Always On VPN and the Future of DirectAccess

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

NetMotion Mobility as an Alternative to Microsoft DirectAccess

DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

DirectAccess and Always On VPN with Trusted Platform Module (TPM) CertificatesTo enhance security when provisioning certificates for DirectAccess (computer) or Windows 10 Always On VPN (user) it is recommended that private keys be stored on a Trusted Platform Module (TPM) on the client device. A TPM is a dedicated security processor included in nearly all modern computers. It provides essential hardware protection to ensure the highest levels of integrity for digital certificates and is used to generate, store, and restrict the use of cryptographic keys. It also includes advanced security and protection features such as key isolation, non-exportability, and anti-hammering to prevent brute-force attacks.

To ensure that private keys are created and stored on a TPM, the certificate template must be configured to use the Microsoft Platform Crypto Provider. Follow the steps below to configure a certificate template required to use a TPM.

  1. Open the Certificate Templates management console (certtmpl.msc) and duplicate an existing certificate template. For example, if creating a certificate for DirectAccess, duplicate the Workstation Authentication certificate template. For Always On VPN, duplicate the User certificate template.
  2. On the Compatibility tab, ensure the Certification Authority and Certificate recipient compatibility settings are set to a minimum of Windows Server 2008 and Windows Vista/Server 2008, respectively.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates
  3. Select the Cryptography tab.
  4. Choose Key Storage Provider from the Provider Category drop down list.
  5. Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

Note: If Microsoft Platform Crypto Provider does not appear in the list above, got to the Request Handling tab and uncheck the option Allow private key to be exported.

Complete the remaining certificate configuration tasks (template display name, subject name, security settings, etc.) and publish the certificate template. Client machines configured to use this template will now have a certificate with private key fully protected by the TPM.

Additional Resources

Trusted Platform Module (TPM) Fundamentals

DirectAccess and Always On VPN Certificate Auto Enrollment

Deploying NetMotion Mobility in Azure

NetMotion MobilityOne of the many advantages NetMotion Mobility offers is that it requires no proprietary hardware to deliver its advanced capabilities and performance. It is a software solution that can be installed on any physical or virtual Windows server. This provides great deployment flexibility by allowing administrators to deploy this remote access solution on their existing virtual infrastructure, which is much less costly than investing in dedicated hardware or virtual appliances.

Cloud Deployment

As customers begin moving their traditional on-premises infrastructure to the cloud, it’s good to know that NetMotion Mobility is fully supported in popular public cloud platforms such as Microsoft Azure. Installing and configuring Mobility on a server in Azure requires a few important changes to a standard Azure VM deployment however. Below is detailed guidance for installing and configuring NetMotion Mobility on a Windows Server 2016 virtual machine hosted in the Microsoft Azure public cloud.

Azure Networking Configuration

Before installing the NetMotion Mobility software, follow the steps below to configure the Azure VM with a static public IP address and enable IP forwarding on the internal network interface.

  1. In the Azure management portal, select the NetMotion Mobility virtual machine and click Networking.
  2. Click on the public-facing network interface.
  3. In the Settings section click IP configurations.
  4. In the IP configurations section click on the IP configuration for the network interface.
  5. In the Public IP address setting section click Enabled for the Public IP address.
  6. Click Configure required settings for the IP address.
  7. Click Create New.
  8. Enter a descriptive name and select Static as the assignment method.
    Deploying NetMotion Mobility in Azure
  9. Click OK
  10. Click Save.Deploying NetMotion Mobility in AzureNote: The process of saving the network interface configuration takes a few minutes. Be patient!
  11. Note the public IP address, as this will be used later during the Mobility configuration.
  12. Close the IP address configuration blade.
  13. In the IP forwarding settings section click Enabled for IP forwarding.Deploying NetMotion Mobility in Azure
  14. Click Save.

NetMotion Mobility Installation

Proceed with the installation of NetMotion Mobility. When prompted for the external address, enter the public IP address created previously.

Deploying NetMotion Mobility in Azure

Next choose the option to Use pool of virtual IP addresses. Click Add and enter the starting and ending IP addresses, subnet prefix length, and default gateway and click OK.

Deploying NetMotion Mobility in Azure

Complete the remaining NetMotion Mobility configuration as required.

Azure Routing Table

A user defined routing table must be configured to ensure that NetMotion Mobility client traffic is routed correctly in Azure. Follow the steps below to complete the configuration.

  1. In the Azure management portal click New.
  2. In the Search the Marketplace field enter route table.
  3. In the results section click Route table.
  4. Click Create.
  5. Enter a descriptive name and select a subscription, resource group, and location.
  6. Click Create.

Deploying NetMotion Mobility in Azure

Once the deployment has completed successfully, click Go to resource in the notifications list.

Deploying NetMotion Mobility in Azure

Follow the steps below to add a route to the route table.

  1. In the Settings sections click Routes.
  2. Click Add.
  3. Enter a descriptive name.
  4. In the Address prefix field enter the subnet used by mobility clients defined earlier.
  5. Select Virtual appliance as the Next hop type.
  6. Enter the IP address of the NetMotion Mobility server’s internal network interface.
  7. Click OK.Deploying NetMotion Mobility in Azure
  8. Click Subnets.
  9. Click Associate.
  10. Click Choose a virtual network and select the network where the NetMotion Mobility gateway resides.
  11. Click Choose a subnet and select the subnet where the NetMotion Mobility gateway’s internal network interface resides.
  12. Click OK.

Note: If clients connecting to the NetMotion Mobility server need to access resources on-premises via a site-to-site gateway, be sure to associate the route table with the Azure gateway subnet.

Azure Network Security Group

A network security group must be configured to allow inbound UDP port 5008 to allow external clients to reach the NetMotion Mobility gateway server. Follow the steps below to create and assign a network security group.

  1. In the Azure management portal click New.
  2. In the Search the Marketplace field enter network security group.
  3. In the results section click Network security group.
  4. Click Create.
  5. Enter a descriptive name and select a subscription, resource group, and location.
  6. Click Create.

Deploying NetMotion Mobility in Azure

Once the deployment has completed successfully, click Go to resource in the notifications list.

Deploying NetMotion Mobility in Azure

Follow the steps below to configure the network security group.

  1. In the Settings section click Inbound security rules.
  2. Click Add.
  3. Enter 5008 in the Destination port ranges field.
  4. Select UDP for the protocol.
  5. Select Allow for the action.
  6. Enter a descriptive name.
  7. Click OK.
    Deploying NetMotion Mobility in Azure
  8. Click Network Interfaces.
  9. Click Associate.
  10. Select the external network interface of the NetMotion Mobility gateway server.

Summary

After completing the steps above, install the client software and configure it to use the static public IP address created previously. Alternatively, configure a DNS record to point to the public IP address and specify the Fully Qualified Domain Name (FQDN) instead of the IP address itself.

Additional Resources

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

NetMotion Mobility as an Alternative to Microsoft DirectAccess

NetMotion Mobility and Microsoft DirectAccess Comparison Whitepaper

NetMotion and Microsoft DirectAccess On-Demand Webinar

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

Enabling Secure Remote Administration for the NetMotion Mobility Console

During the initial setup of a NetMotion Mobility gateway server, the administrator must choose to allow either Secure (HTTPS) or Non-secure (HTTP) connections when using the web-based Mobility Console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Configuring HTTPS

Security best practices dictate HTTPS should be enabled to protect credentials used to log on to the gateway remotely. Immediately after selecting the Secure (https:) option, the administrator is prompted to enter server certificate information. Enter this information and click OK to continue and complete the rest of the configuration as necessary.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Self-Signed Certificate

When logging in to the Mobility console, the administrator is presented with a certificate error indicating there is a problem with the website’s security certificate. This is because the certificate is self-signed by the NetMotion Mobility gateway server and is not trusted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

PKI Issued Certificate

The recommended way to resolve this is to request a certificate from a trusted certification authority (CA). To do this, open the Mobility Management Tool on the Mobility gateway server and click on the Web Server tab.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click on the Server Certificate button and then click New in the Certificate Request section.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In the SAN (subject alternative name) field of the Optional Extension section enter the Fully Qualified Domain Name (FQDN) of the server using the syntax dns:fqdn. Include both the FQDN and the single-label hostname (short name) separated by a comma to ensure both names work without issue. For example:

dns:nm1.lab.richardhicks.net,dns:nm1

Enabling Secure Remote Administration for the NetMotion Mobility Console

Before requesting a certificate from a CA, the root and any intermediate CA certificates must first be imported. Click the Import button next to each, as required.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Copy in the Certificate Request section to copy the Certificate Signing Request (CSR) to the clipboard and then save it to a text file. Now submit the CSR to be signed by the CA using the certreq.exe command. Open an elevated command or PowerShell window and enter the following commands.

certreq.exe -attrib “CertificateTemplate:[TemplateName]” -submit [Path_to_CSR_file]

For example:

certreq.exe -attrib “CertificateTemplate:LabWebServer” -submit certreq.txt

Select a CA from the list and click OK, then save the certificate response when prompted.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Response and specify the location of the certificate response file saved in the previous step.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Once complete, the newly issued certificate will be in place. Click Close to complete the process.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Click Yes when prompted to restart the Mobility console.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Trusted Certificate

Opening the Mobility Console no longer produces a certificate error message with a certificate installed from a trusted CA.

Enabling Secure Remote Administration for the NetMotion Mobility Console

In addition, if you followed the guidance above and included the single-label hostname in the SAN field, accessing the server using the short name will also work without issue.

Enabling Secure Remote Administration for the NetMotion Mobility Console

Summary

Always select the option to use HTTPS to ensure the highest level of security and protection of credentials when remotely administering a NetMotion Mobility gateway server. For optimal security and to provide the best user experience, use a certificate issued and managed by a trusted CA to prevent certificate errors when opening the Mobility console.

Additional Information

NetMotion Mobility as an Alternative to DirectAccess

NetMotion Mobility Device Tunnel Configuration

Comparing NetMotion Mobility and DirectAccess Part 1 – Security

Comparing NetMotion Mobility and DirectAccess Part 2 – Performance

DirectAccess and NetMotion Mobility Webinar

 

%d bloggers like this: