All posts in category DirectAccess

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.

Leave a comment
by Richard M. Hicks on June 4, 2018  •  Permalink
Posted in Always On VPN, AOVPN, DirectAccess, DirectAccess Deprecated, DirectAccess End of Life, DirectAccess EOL, end of life, Enterprise, enterprise mobility, EOL, Mobility, NetMotion, NetMotion Mobility, Remote Access, Security, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on June 4, 2018

https://directaccess.richardhicks.com/2018/06/04/comparing-directaccess-and-netmotion-mobility/

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft IntuneWindows 10 Always On VPN is the replacement for Microsoft’s popular DirectAccess remote access solution. It provides the same seamless, transparent, always on remote connectivity as DirectAccess. Where DirectAccess relied heavily on classic on-premises infrastructure such as Active Directory and Group Policy, Always On VPN is infrastructure independent and is designed to be provisioned and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune.

Intune and Always On VPN

Until recently, provisioning Windows 10 Always On VPN connections involved manually creating a ProfileXML and uploading to Intune using a custom profile. This has proven to be challenging for many, as the process is unintuitive and error prone.

A recent Intune update now allows administrators to create a basic Windows 10 Always On VPN deployment. Although it still has its limitations, it will go a long way to making the adoption of Always On VPN easier.

Prerequisites

Certificates must first be provisioned to all clients before deploying Windows 10 Always On VPN using Intune. In addition, if using a third-party VPN client, the VPN plug-in software must be installed prior to deploying the VPN profile.

Test VPN Connection

It is recommended that a test VPN connection be created on a client machine locally before deploying an Always On VPN profile using Intune. This allows the administrator to test connectivity and validate Extensible Authentication Protocol (EAP) settings. Once complete, run the following PowerShell commands to extract the EAP configuration settings to a file for later publishing with Intune.

$Vpn = Get-VpnConnection -Name [Test VPN connection name]
$Xml = $Vpn.EapConfigXmlStream.InnerXml | Out-File .\eapconfig.xml -Encoding ASCII

Deploying Always On VPN with Intune

Follow the steps below to deploy an Always On VPN connection using Intune.

Create a VPN Profile

  1. Open the Microsoft Intune management portal.
  2. Click Device configuration.
  3. Click Profiles.
  4. Click Create profile.

Deploying Windows 10 Always On VPN with Microsoft Intune

  1. Enter a name for the VPN profile.
  2. Enter a description (optional).
  3. From the Platform drop-down menu select Windows 10 and later.
  4. From the Profile type drop-down menu select VPN.
  5. In the Settings section click Configure.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define VPN Profile Settings

  1. Click Base VPN.
  2. Enter a name for the connection.
  3. Enter a description and provide the Fully Qualified Domain Name (FQDN) of the VPN server. If it will be the default server select True and click Add.
  4. Enter a description and provide the FQDN for any additional VPN servers, as required.
  5. From the Connection type drop-down list choose the preferred connection type.
  6. In the Always On section click Enable.
  7. Select Enable to Remember credentials at each logon (optional).
  8. Click Select a certificate.
  9. Choose a client authentication certificate and click Ok.
  10. Paste the contents of eapconfig.xml (saved previously) in the EAP Xml field.
  11. Click Ok.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define Additional Settings

You can also configure the following optional VPN settings using Intune.

  • Apps and Traffic Rules
  • Conditional Access
  • DNS Settings
  • Proxy
  • Split Tunneling

Deploying Windows 10 Always On VPN with Microsoft Intune

After configuring any required additional settings, click Create.

Assign VPN Profile

  1. Click Assignments.
  2. From the Assign to drop-down menu choose Selected Groups.
  3. Click Select groups to include.
  4. Choose an Azure Active Directory group to apply the VPN profile and click Select.
  5. Click Save.

Deploying Windows 10 Always On VPN with Microsoft Intune

Limitations

Although the ability to provision Always On VPN using Microsoft Intune without using a custom profile is welcome, it is not without its limitations. At the time of this writing, only Always On VPN user profiles can be configured. A device tunnel, which is optional, must be configured manually using a custom profile. In addition, the Intune user interface lacks the ability to define settings for the following parameters:

  • Exclusion routes
  • Name Resolution Policy Table (NRPT) exemptions
  • Lockdown mode
  • DNS registration
  • Trusted network detection
  • Custom IKEv2 cryptography policy

To make changes to the default settings for any of the above parameters, a ProfileXML must be created manually and provisioned with Intune using a custom policy.

Additional Information

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

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN and the Name Resolution Policy Table (NRPT)

Windows 10 Always On VPN Hands-On Training

11 Comments
by Richard M. Hicks on May 21, 2018  •  Permalink
Posted in Always On VPN, AOVPN, certificates, DirectAccess, DNS, enterprise mobility, Mobility, name resolution policy table, PowerShell, Remote Access, Windows 10
Tagged , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on May 21, 2018

https://directaccess.richardhicks.com/2018/05/21/deploying-windows-10-always-on-vpn-with-microsoft-intune/

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

2 Comments
by Richard M. Hicks on May 14, 2018  •  Permalink
Posted in DirectAccess, Enterprise, enterprise mobility, IPv6, IPv6 Transition, Mobility, Multifactor Authentiction, multisite, name resolution policy table, NRPT, OTP, PowerShell, Remote Access, Security, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on May 14, 2018

https://directaccess.richardhicks.com/2018/05/14/directaccess-selective-tunneling/

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

NetMotion Mobility for DirectAccess Administrators – Split vs. Force TunnelingDirectAccess employs a split tunneling network model by default. In this configuration, only network traffic destined for the internal network (as defined by the administrator) is tunneled over the DirectAccess connection. All other network traffic is routed directly over the Internet.

Force Tunneling Use Cases

For a variety of reasons, administrators may want to configure DirectAccess to use force tunneling, requiring all client traffic be routed over the DirectAccess connection, including public Internet traffic. Commonly this is done to ensure that all traffic is logged and, importantly, screened and filtered to enforce acceptable use policy and to prevent malware infection and potential loss of data.

DirectAccess and Force Tunneling

Enabling force tunneling for DirectAccess is not trivial, as it requires an on-premises proxy server to ensure proper functionality when accessing resources on the public Internet. You can find detailed guidance for configuring DirectAccess to use force tunneling here.

NetMotion Mobility and Force Tunneling

With NetMotion Mobility, force tunneling is enabled by default. So, if split tunneling is desired, it must be explicitly configured. Follow the steps below to create a split tunneling policy.

Create a Rule Set

  1. Open the NetMotion Mobility management console and click Policy > Policy Management.
  2. Click New.
  3. Enter a descriptive name for the new rule set.
  4. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Create a Rule

  1. Click New.
  2. Enter a descriptive name for the new rule.
  3. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define an Action

  1. Click on the Actions tab.
  2. In the Addresses section check the box next to Allow network traffic for address(es)/port(s).NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. In the Base section select Pass through all network traffic.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define the Internal Network

  1. In the Policy rule definition section click the address(es)/port(s) link.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  2. Click Add.
  3. In the Remote Address column select Network Address.
  4. Enter the network prefix and prefix length that corresponds to the internal network.
  5. Click Ok.
  6. Repeat the steps above to add any additional internal subnets, as required.
  7. Click Ok.
  8. Click Save.
  9. Click Save.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Assign the Policy

  1. Click on the Subscribers tab.
  2. Choose a group to assign the policy to. This can be users, groups, devices, etc.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. Click Subscribe.
  4. Select the Split Tunneling policy.
  5. Click Ok.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Validation Testing

With split tunneling enabled the NetMotion Mobility client will be able to securely access internal network resources over the Mobility connection, but all other traffic will be routed over the public Internet. To confirm this, first very that internal resources are reachable. Next, open your favor Internet search engine and enter “IP”. The IP address you see should be the IP address of the client, not the on-premises gateway.

Summary

I’ve never been a big fan of force tunneling with DirectAccess. Not only is it difficult to implement (and requires additional infrastructure!) the user experience is generally poor. There are usability issues especially with captive portals for Wi-Fi, and performance often suffers. In addition, enabling force tunneling precludes the use of strong user authentication with one-time passwords.

With NetMotion Mobility, force tunneling is on by default, so no configuration changes are required. The user experience is improved as NetMotion Mobility intelligently recognizes captive portals. Performance is much better too. In addition, NetMotion Mobility is more flexible, allowing for the use of OTP authentication with force tunneling. Also, with NetMotion Mobility force tunneling is not a global setting. You can selectively apply force tunneling to users and/or groups as necessary.

Additional Information

NetMotion Mobility as an Alternative for Microsoft DirectAccess

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

 

1 Comment
by Richard M. Hicks on April 2, 2018  •  Permalink
Posted in DirectAccess, enterprise mobility, Mobility, Multifactor Authentiction, NetMotion, NetMotion Mobility, OTP, Remote Access, Security, VPN, Windows 10, Windows Server 2016
Tagged , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on April 2, 2018

https://directaccess.richardhicks.com/2018/04/02/netmotion-mobility-for-directaccess-administrators-split-vs-force-tunneling/

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

NetMotion Mobility for DirectAccess Administrators – Trusted Network DetectionDirectAccess clients use the Network Location Server (NLS) for trusted network detection. If the NLS can be reached, the client will assume it is on the internal network and the DirectAccess connection will not be made. If the NLS cannot be reached, the client will assume it is outside the network and it will then attempt to establish a connection to the DirectAccess server.

Critical Infrastructure

DirectAccess NLS availability and reachability is crucial to ensuring uninterrupted operation for DirectAccess clients on the internal network. If the NLS is offline or unreachable for any reason, DirectAccess clients on the internal network will be unable to access internal resources by name until the NLS is once again available. To ensure reliable NLS operation and to avoid potential disruption, the NLS should be highly available and geographically redundant. Close attention must be paid to NLS SSL certificate expiration dates too.

NetMotion Mobility

NetMotion Mobility does not require additional infrastructure for inside/outside detection as DirectAccess does. Instead, Mobility clients determine their network location by the IP address of the Mobility server they are connected to.

Unlike DirectAccess, NetMotion Mobility clients will connect to the Mobility server whenever it is reachable, even if they are on the internal network. There are some advantages to this, but if this behavior isn’t desired, a policy can be created that effectively replicates DirectAccess client behavior by bypassing the Mobility client when the client is on the internal network.

Configuring Trusted Network Detection

Follow the steps below to create a policy to enable trusted network detection for NetMotion Mobility clients.

Create a Rule Set

  1. From the drop-down menu in the NetMotion Mobility management console click Policy and then Policy Management.
  2. Click New.
  3. Enter a descriptive name for the new rule set.
  4. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Create a Rule

  1. Click New.
  2. Enter a descriptive name for the new rule.
  3. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Define a Condition

  1. Click on the Conditions tab.
  2. In the Addresses section check the box next to When the Mobility server address is address.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  3. In the Policy rule definition section click the equal to address(es) (v9.0) link.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  4. Click Add.
  5. Select Mobility server address.
  6. Select the IP address assigned to the Mobility server’s internal network interface.
  7. Click Ok.
  8. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Define an Action

  1. Click on the Actions tab.
  2. In the Passthrough Mode section check the box next to Enable/disable passthrough mode.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  3. Click Save.
  4. Click Save.

Assign the Policy

  1. Click on the Subscribers tab.
  2. Choose a group to assign the policy to. This can be users, groups, devices, etc.
    NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection
  3. Click Subscribe.
  4. Select the Trusted Network Detection policy.
  5. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Validation Testing

The NetMotion Mobility client will connect normally when the client is outside of the network. However, if the Mobility client detects that it is connected to the internal interface of the Mobility server, all network traffic will bypass the Mobility client.

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Summary

Trusted network detection can be used to control client behavior based on their network location. Many administrators prefer that connections only be made when clients are outside the network. DirectAccess clients use the NLS to determine network location and will not establish a DirectAccess connection if the NLS is reachable.

NetMotion Mobility trusted network detection relies on detecting the IP address of the Mobility server to which the connection was made. This is more elegant and effective than the DirectAccess NLS, and more reliable too.

Additional Information

Enabling Secure Remote Administrator for the NetMotion Mobility Management Console

NetMotion Mobility Device Tunnel Configuration

Deploying NetMotion Mobility in Azure

1 Comment
by Richard M. Hicks on March 26, 2018  •  Permalink
Posted in DirectAccess, enterprise mobility, Mobility, NetMotion, NetMotion Mobility, Remote Access, VPN, Windows 10, Windows Server 2016
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on March 26, 2018

https://directaccess.richardhicks.com/2018/03/26/netmotion-mobility-directaccess-trusted-network-detection/

Unable to Generate DirectAccess Diagnostic Log in Windows 10 v1709

There are numerous reports that generating the DirectAccess troubleshooting log fails on Windows 10 v1709. DirectAccess administrators have been reporting that the process seems to fail during the creation of the log file, leaving it truncated and incomplete. To resolve this issue, open an elevated PowerShell window and enter the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NcaSvc\” -Name SvcHostSplitDisable -PropertyType DWORD -Value 1 -Force

The computer must be restarted for this change to take effect. If initial testing of this workaround is successful, the registry setting can be pushed out to all DirectAccess clients using Active Directory Group Policy Preferences.

4 Comments
by Richard M. Hicks on March 15, 2018  •  Permalink
Posted in DirectAccess, PowerShell, Remote Access, troubleshooting, Windows 10
Tagged , , , , , , , ,

Posted by Richard M. Hicks on March 15, 2018

https://directaccess.richardhicks.com/2018/03/15/unable-to-generate-directaccess-diagnostic-log-in-windows-10-v1709/

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

DirectAccess Troubleshooting and the Windows 10 Network Connectivity AssistantOne of the first places administrators look for information about the DirectAccess client connection is the Network Connectivity Assistant (NCA). The NCA is used to view current connection status and to gather detailed information that is helpful for troubleshooting failed DirectAccess connections. The NCA was first integrated with the client operating system beginning with Windows 8. Similar functionality can be extended to Windows 7 clients by installing and configuring the Windows 7 DirectAccess Connectivity Assistant (DCA).

NCA

The DirectAccess NCA can be accessed by pressing the Windows Key + I and then clicking on Network & Internet and DirectAccess. Here you’ll find a helpful visual indicator of current connectivity status, and for multisite deployments you’ll also find details about the current entry point.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

DirectAccess Missing?

If DirectAccess does not appear in the list, open an elevated PowerShell window and restart the Network Connectivity Assistant service (NcaSvc) using the following command.

Restart-Service NcaSvc

If you receive the error “Failed to start service ‘Network Connectivity Assistant (NcaSvc)‘”, ensure that the client operating system is Enterprise or Education edition. The NCA service will always fail to start on Professional edition as it is not a supported DirectAccess client.

Log Collection

The DirectAccess NCA also provides access to crucial troubleshooting information. Clicking on the Collect button creates a detailed diagnostic log file that is often helpful for troubleshooting DirectAccess connectivity issues.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Troubleshooting Info Missing?

The option to collect a log, and email it to your IT admin will only be displayed if a support email address is defined in the DirectAccess configuration. To define a support email address, open the Remote Access Management console and perform the following steps.

1. Click Edit on Step 1.
2. Click Network Connectivity Assistant.
3. Enter an email address in the Helpdesk email address field.
4. Click Finish to complete Step 1.
5. Click Finish to apply the changes.

Email Program

Microsoft assumes that an end user will be generating the DirectAccess client troubleshooting log and will be emailing them to their administrator. If an email program is not installed on the client, the following information is displayed.

There is no email program associated to perform the requested action. Please install an email program or, if one is already installed, create an associate in the Default Programs control panel.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

If you wish to simply view the log file on the client and not email them, you can find the generated DirectAccess troubleshooting log file in HTML format in the following location.

%SystemDrive%\Users\%Username%\AppData\Local\Temp

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Unable to Generate Log Files

There are numerous reports that generating the DirectAccess troubleshooting log fails on Windows 10 v1709. DirectAccess administrators have been reporting that the process seems to fail during the creation of the log file, leaving it truncated and incomplete. To resolve this issue, open an elevated PowerShell window and enter the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NcaSvc\” -Name SvcHostSplitDisable -PropertyType DWORD -Value 1 -Force

The computer must be restarted for this change to take effect. If initial testing of this workaround is successful, the registry setting can be pushed out to all DirectAccess clients using Active Directory Group Policy Preferences.

Additional Information

Installing and Configuring DirectAccess Connectivity Assistant 2.0 on Windows 7 Clients

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight

Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course on Pluralsight

Implementing DirectAccess with Windows Server 2016 Book

5 Comments
by Richard M. Hicks on March 15, 2018  •  Permalink
Posted in DirectAccess, enterprise mobility, multisite, NCA, network connectivity assistant, PowerShell, Remote Access, troubleshooting, Windows 10, Windows 8.1
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 15, 2018

https://directaccess.richardhicks.com/2018/03/15/directaccess-troubleshooting-windows-10-network-connectivity-assistant/

DirectAccess IP-HTTPS and Symantec SSL Certificates

DirectAccess IP-HTTPS and Symantec SSL CertificatesAn SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click here.

Symantec Issued Certificates

Symantec is a popular commercial SSL certificate provider that has been commonly used for many years. However, due to integrity issues associated with their PKI management practices, Google and Mozilla announced they will soon be deprecating these certificates. This means users who browse to an HTTPS web site protected with a Symantec SSL certificate will receive a warning in their browser indicating the certificate is not trusted.

DirectAccess IP-HTTPS

It is important to note that there is no impact at all for DirectAccess when the server is configured to use an SSL certificate issued by Symantec. There is nothing you need to do to address this issue in this scenario. However, if a wildcard certificate is installed on the DirectAccess server and it is also used on other public-facing web servers in the organization, it is likely that the certificate will replaced, perhaps by another certificate provider. In this case, DirectAccess IP-HTTPS must be configured to use the new or updated SSL certificate.

Updating IP-HTTPS SSL Certificate

To update the DirectAccess IP-HTTPS SSL certificate, import the SSL certificate along with the private key in to the local computer certificate store on each DirectAccess server. Next identify the thumbprint of the new SSL certificate. Finally, open an elevated PowerShell command window and enter the following command.

$thumbprint = “ssl_cert_thumbprint”
$cert = Get-ChildItem -Path cert:\localmachine\my | where {$_.thumbprint -eq $thumbprint}
Set-RemoteAccess -SslCertificate $cert -PassThru

Be sure to replace “ssl_cert_thumbprint” with the actual thumbprint of your SSL certificate. 😉 In addition, for load-balanced and/or multisite deployments, run these PowerShell commands on each server in the enterprise.

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess IP-HTTPS Null Cipher Suites Not Available 

DirectAccess IP-HTTPS Performance Issues

Leave a comment
by Richard M. Hicks on March 5, 2018  •  Permalink
Posted in certificates, DirectAccess, Encryption, IP-HTTPS, IPv6, IPv6 Transition, multisite, PKI, PowerShell, public key infrastructure, Remote Access, Security, SSL and TLS, transition technology, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on March 5, 2018

https://directaccess.richardhicks.com/2018/03/05/directaccess-ip-https-and-symantec-ssl-certificates/

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

3 Comments
by Richard M. Hicks on February 19, 2018  •  Permalink
Posted in DirectAccess, encapsulation, Encryption, IP-HTTPS, IPv6, IPv6 Transition, Remote Access, SSL and TLS, transition technology, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 19, 2018

https://directaccess.richardhicks.com/2018/02/19/directaccess-ip-https-performance-issues/

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

9 Comments
by Richard M. Hicks on February 12, 2018  •  Permalink
Posted in Always On VPN, AOVPN, certificates, DirectAccess, Encryption, PKI, public key infrastructure, Remote Access, Security, TPM, Trusted Platform Module, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on February 12, 2018

https://directaccess.richardhicks.com/2018/02/12/directaccess-and-always-on-vpn-with-trusted-platform-module-tpm-certificates/

« Older Posts
%d bloggers like this: