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

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

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

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

DirectAccess NRPT Configuration with Split DNS

DirectAccess NRPT Configuration with Split DNSThe Name Resolution Policy Table (NRPT) in Windows provides policy-based name resolution request routing for DNS queries. DirectAccess uses the NRPT to ensure that only requests for resources in the internal namespace, as defined by the DirectAccess administrator, are sent over the DirectAccess connection. DNS queries for all other namespaces are sent to the DNS servers defined on the client’s network interface.

Note: This behavior changes when force tunneling is enabled. In this case, all DNS queries are sent over the DirectAccess connection with the exception of the NLS and the DirectAccess server’s public hostname(s). If force tunneling is enabled, the configuration guidance described below is not required.

Split DNS

NRPT configuration is straightforward when the internal and external namespaces are unique. However, when split DNS is used, meaning when the internal and external namespaces are the same, DirectAccess configuration is more challenging. Typically, there may be many resources that should not go over the DirectAccess connection, such as public-facing web servers, email and unified communications servers, federation servers, etc. Without additional configuration, requests for all of these services would go over the DirectAccess connection. That may or may not be desirable, depending on the requirements of the implementation.

DirectAccess Server

One crucial public resource is the DirectAccess server itself. When using split DNS, the DirectAccess implementation’s public hostname will, by default, be included in the internal namespace. In this scenario, the DirectAccess client will fail to establish a connection to the DirectAccess server.

Troubleshooting

When troubleshooting failed connectivity, the output of ipconfig will show the IP-HTTPS tunnel interface media state as “Media disconnected”.

DirectAccess NRPT Configuration with Split DNS

The output of Get-NetIPHttpsState will also return an error code 0x2AF9 with an interface status “Failed to connect to the IPHTTPS server; waiting to reconnect”.

DirectAccess NRPT Configuration with Split DNS

To further troubleshoot this issue, examine the output of Get-NetIPHttpsConfiguration. Test name resolution of the FQDN listed in the ServerURL field. If the issue is related to NRPT configuration, the client will fail to resolve this name to an IP address. Testing from a non-DirectAccess client should resolve correctly, however.

DirectAccess NRPT Configuration with Split DNS

NRPT Configuration

If split DNS is employed, it is necessary to include the DirectAccess server’s public hostname in the NRPT as an exemption. This will cause the DNS query for the public hostname to use public DNS servers, allowing the DirectAccess client to establish a connection successfully.

To resolve this issue, open the Remote Access Management console on the DirectAccess server, highlight DirectAccess and VPN under Configuration, and then click Edit on Step 3. Select DNS, and then double-click on an empty row in the table.

DirectAccess NRPT Configuration with Split DNS

Enter the public hostname for the DirectAccess deployment in the DNS suffix field (the public hostname can be found by clicking Edit on Step 2). Do NOT specify a DNS server. Click Apply, click Next twice, and then click Finish.

DirectAccess NRPT Configuration with Split DNS

Note: For multisite deployments, be sure to include the public hostname for each entry point in the enterprise. Also, if multisite is configured to use GSLB, include the GSLB hostname as well.

PowerShell

Alternatively, you can run the following PowerShell commands to automatically configure the NRPT for split DNS. For multisite deployments, be sure to run these commands on at least one DirectAccess server in each site.

$hostname = Get-RemoteAccess | Select-Object -ExpandProperty ConnectToAddress
Add-DAClientDnsConfiguration -DnsSuffix $hostname -PassThru

If multisite is configured to use GSLB, run the following PowerShell commands on one DirectAccess server in the enterprise.

$gslbfqdn = Get-DAMultiSite | Select-Object -ExpandProperty GslbFqdn
Add-DAClientDnsConfiguration -DnsSuffix $gslbfqdn -PassThru

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

DirectAccess DNS Not Working Properly

DirectAccess DNS Records Explained

Troubleshooting Name Resolution Issue on DirectAccess Clients

DirectAccess Manage Out with ISATAP and NLB Clustering

DirectAccess Manage Out with ISATAP and NLB ClusteringDirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.

ISATAP Supportability

According to Microsoft’s support guidelines for DirectAccess, using ISATAP for manage out is only supported for single server deployments. ISATAP is not supported when deployed in a multisite or load-balanced environment.

Not supported” is not the same as “doesn’t work” though. For example, ISATAP can easily be deployed in single site DirectAccess deployments where load balancing is provided using Network Load Balancing (NLB).

ISATAP Configuration

To do this, you must first create DNS A resource records for the internal IPv4 address for each DirectAccess server as well as the internal virtual IP address (VIP) assigned to the cluster.

DirectAccess Manage Out with ISATAP and NLB Clustering

Note: Do NOT use the name ISATAP. This name is included in the DNS query block list on most DNS servers and will not resolve unless it is removed. Removing it is not recommended either, as it will result in ALL IPv6-enabled hosts on the network configuring an ISATAP tunnel adapter.

Once the DNS records have been added, you can configure a single computer for manage out by opening an elevated PowerShell command window and running the following command:

Set-NetIsatapConfiguration -State Enabled -Router [ISATAP FQDN] -PassThru

DirectAccess Manage Out with ISATAP and NLB Clustering

Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.

DirectAccess Manage Out with ISATAP and NLB Clustering

Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.

DirectAccess Manage Out with ISATAP and NLB Clustering

Finally, verify network connectivity from the manage out host to the remote DirectAccess client.

Note: There is a known issue with some versions of Windows 10 and Windows Server 2016 that may prevent manage out using ISATAP from working correctly. There’s a simple workaround, however. More details can be found here.

Group Policy Deployment

If you have more than a few systems on which to enable ISATAP manage out, using Active Directory Group Policy Objects (GPOs) to distribute these settings is a much better idea. You can find guidance for creating GPOs for ISATAP manage out here.

DirectAccess Client Firewall Configuration

Simply enabling ISATAP on a server or workstation isn’t all that’s required to perform remote management on DirectAccess clients. The Windows firewall running on the DirectAccess client computer must also be configured to securely allow remote administration traffic from the internal network. Guidance for configuring the Windows firewall on DirectAccess clients for ISATAP manage out can be found here.

ISATAP Manage Out for Multisite and ELB

The configuration guidance in this post will not work if DirectAccess multisite is enabled or external load balancers (ELB) are used. However, ISATAP can still be used. For more information about enabling ISATAP manage out with external load balancers and/or multisite deployments, fill out the form below and I’ll provide you with more details.

Summary

Once ISATAP is enabled for manage out, administrators on the internal network can remotely manage DirectAccess clients wherever they happen to be. Native Windows remote administration tools such as Remote Desktop, Windows Remote Assistance, and the Computer Management MMC can be used to manage remote DirectAccess clients. In addition, enterprise administration tools such as PowerShell remoting and System Center Configuration Manger (SCCM) Remote Control can also be used. Further, third-party remote administration tools such as VNC, TeamViewer, LogMeIn, GoToMyPC, Bomgar, and many others will also work with DirectAccess ISATAP manage out.

Additional Information

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

Contact Me

Interested in learning more about ISATAP manage out for multisite and external load balancer deployments? Fill out the form below and I’ll get in touch with you.

SSL Certificate Considerations for DirectAccess IP-HTTPS

SSL Certificate Considerations for DirectAccess IP-HTTPSDirectAccess uses IPv6 exclusively for communication between the client and server. IPv6 transition technologies are used to support DirectAccess communication over the IPv4 public Internet. One of those IPv6 transition technologies, IP-HTTPS, uses HTTP for encapsulation and SSL/TLS for authentication of the DirectAccess server.

SSL Certificates

When configuring DirectAccess, an SSL certificate must be provided for IP-HTTPS. There are three different types of SSL certificates that can be used.

Public SSL Certificate – Using an SSL certificate signed by a public certification authority (CA) is the recommended best practice for configuring DirectAccess IP-HTTPS. This provides the highest level of assurance for DirectAccess clients connecting via IP-HTTPS.

Private SSL Certificate – Using an SSL certificate issued by the organization’s internal CA is an acceptable alternative to using a public SSL certificate in most cases. This can reduce the cost associated with obtaining the certificate, especially for multisite deployments.

Self-Signed Certificate – Using a self-signed certificate is not recommended and should be avoided in most deployment scenarios. A self-signed certificate provides no real assurance for DirectAccess clients. Crucially, using a self-signed certificate will disable support for null SSL and TLS cipher suites. This reduces the overall scalability and performance of the remote access solution.

SSL Certificate Considerations for DirectAccess IP-HTTPS

Figure 1. Null cipher suites not supported when using a self-signed SSL certificate for IP-HTTPS.

Certificate Requirements

The SSL certificate must include the Server Authentication (1.3.6.1.5.5.7.3.1) Enhanced Key Usage (EKU) Object Identifier (OID). It should use an RSA key of 2048 bits and be signed with SHA256. Using stronger keys provides no additional protection and should not be used. In addition, SSL certificates using ECDSA keys is not recommended, as they do not support null cipher suites.

Summary

In most cases, using a public SSL certificate is ideal. However, issuing a certificate from a private CA is also acceptable. Using self-signed certificates can be used for non-production testing and in very small production deployments, but should generally be avoided.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

DirectAccess Force Tunneling and Proxy Server Configuration

By default, DirectAccess is configured to use split tunneling. In this scenario, a remote DirectAccess client is connected to the internal corporate network and the public Internet at the same time. Some security administrators perceive split tunneling as a security risk, and the use of split tunneling may be prohibited by corporate security policy. In addition, enforcing web browsing policies on remote DirectAccess clients might be desired to reduce the risk of exposure from browsing unapproved web sites. In either case, force tunneling can be configured to meet these requirements.

When force tunneling is enabled, DirectAccess administrators can also define an on-premises proxy server for DirectAccess clients to use. The following is guidance for enabling force tunneling and configuring DirectAccess clients to use a proxy server to access the Internet.

Enabling Force Tunneling

To enable force tunneling, open the Remote Access Management console and perform the following steps.

  1. Expand Configuration and select DirectAccess and VPN.
  2. Click Edit on Step 1 Remote Clients.
  3. Click Select Groups in the navigation tree.
  4. Select the option to Use force tunneling.

DirectAccess Force Tunneling and Proxy Server ConfigurationFigure 1. Enable DirectAccess force tunneling in the Remote Access Management console.

Alternatively, force tunneling can quickly be enabled by opening an elevated PowerShell command window and running the following command.

Set-DAClient -ForceTunnel Enabled -PassThru

DirectAccess Force Tunneling and Proxy Server ConfigurationFigure 2. Enable DirectAccess force tunneling using PowerShell.

Configure a Proxy Server

Once force tunneling has been enabled, run the following PowerShell script to configure an on-premises proxy server for DirectAccess clients to use. Be sure to substitute the fully-qualified domain name (FQDN) and port for your proxy server in the $proxy variable below.

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]

$proxy = “proxy.corp.example.net:8080”

$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq “.” | Select-Object -ExpandProperty “Name”)

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

If multisite is enabled and Windows 7 clients are supported, run the following PowerShell script on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]

$proxy = “proxy.corp.example.net:8080”

$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq “.” | Select-Object -ExpandProperty “Name”)

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

Remove Proxy Server

Run the following PowerShell script to remove the proxy server, if necessary.

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]

Set-DnsClientNrptRule -DAEnable $true -DAProxyType “UseDefault” -Name $rule -GpoName $gpo

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]

Set-DnsClientNrptRule -DAEnable $true -DAProxyType “UseDefault” -Name $downlevelrule -GpoName $downlevelgpo

Disable Force Tunneling

To disable force tunneling completely, run the following PowerShell command.

Set-DAClient -ForceTunnel Disabled -PassThru

Force Tunneling Caveats

When force tunneling is enabled, the user experience is typically poor when accessing the Internet. Web browsing performance is significantly reduced because of the added protocol overhead imposed by DirectAccess IPv6 transition technologies and IPsec encryption. This problem is further compounded when users access resources that are already encrypted, such as secure web sites. Increased packet fragmentation, along with the additional network latency caused by suboptimal network paths and increased network load on the server and Internet connection all contribute to degraded network performance for DirectAccess clients.

Force Tunneling Alternatives

Instead of enabling force tunneling, consider alternative solutions to address the security concerns associated with split tunneling. For example, implement technologies that enforce web browsing policies on the client. Many secure web gateways and next-generation firewalls (NGFW) have remote filtering capabilities that allow administrators to enforce web browsing policies on remote client machines. In addition, there are some excellent cloud-based solutions such as Zscaler and OpenDNS that can protect DirectAccess clients without the drawbacks associated with force tunneling.

Additional Information

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

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

The seamless and transparent nature of DirectAccess makes it wonderfully easy to use. In most cases, it requires no user interaction at all to access internal corporate resources while away from the office. This enables users to be more productive. At the same time, it offers important connectivity benefits for IT administrators and systems management engineers as well.

Always Managed

DirectAccess Manage Out and System Center Configuration Manager (SCCM)DirectAccess clients are automatically connected to the corporate network any time they have a working Internet connection. Having consistent corporate network connectivity means they receive Active Directory group policy updates on a regular basis, just as on-premises systems do. Importantly, they check in with internal management systems such as System Center Configuration Manager (SCCM) and Windows Server Update Services (WSUS) servers, enabling them to receive updates in a timely manner. Thus, DirectAccess clients are better managed, allowing administrators to more effectively maintain the configuration state and security posture for all their managed systems, including those that are predominantly field-based. This is especially crucial considering the prevalence WannaCry, Cryptolocker, and a variety of other types of ransomware.

DirectAccess Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)When manage out is configured with DirectAccess, hosts on the internal network can initiate connections outbound to remote connected DirectAccess clients. SCCM Remote Control and Remote Desktop Connection (RDC) are commonly used to remotely connect to systems for troubleshooting and support. With DirectAccess manage out enabled, these and other popular administrative tools such as VNC, Windows Remote Assistance, and PowerShell remoting can also be used to manage remote DirectAccess clients in the field. In addition, enabling manage out allows for the proactive installation of agents and other software on remote clients, such as the SCCM and System Center Operation Manager (SCOM) agents, third-party management agents, antivirus and antimalware software, and more. A user does not have to be logged on to their machine for manage out to work.

IPv6

DirectAccess manage out requires that connections initiated by machines on the internal network to remote-connected DirectAccess clients must be made using IPv6. This is because DirectAccess clients use IPv6 exclusively to connect to the DirectAccess server. To enable connectivity over the public IPv4 Internet, clients use IPv6 transition technologies (6to4, Teredo, IP-HTTPS), and IPv6 translation components on the server (DNS64 and NAT64) enable clients to communicate with internal IPv4 resources. However, DNS64 and NAT64 only translate IPv6 to IPv4 inbound. They do not work in reverse.

Native or Transition?

It is recommended that IPv6 be deployed on the internal network to enable DirectAccess manage out. This is not a trivial task, and many organizations can’t justify the deployment for just this one specific use case. As an alternative, IPv6 can be configured with an IPv6 transition technology, specifically the Intrasite Automatic Tunnel Addressing Protocol (ISATAP). ISATAP functions as an IPv6 overlay network, allowing internal hosts to obtain IPv6 addresses and routing information from an ISATAP router to support manage out for DirectAccess clients.

ISATAP

When DirectAccess is installed, the server is automatically configured as an ISATAP router. Guidance for configuring ISATAP clients can be found here. Using ISATAP can be an effective approach to enabling DirectAccess manage out for SCCM when native IPv6 is not available, but it is not without its drawbacks.

• Using the DirectAccess server for ISATAP is only supported with single server DirectAccess deployments.
• Using the DirectAccess server for ISATAP does work when using Network Load Balancing (NLB) with some additional configuration, but it is not supported.
• Using the DirectAccess server for ISATAP does not work when an external load balancer is used, or if multisite is enabled.

ISATAP with Load Balancing and Multisite

It is technically possible to enable DirectAccess manage out for SCCM using ISATAP in load-balanced and multisite DirectAccess deployments, however. It involves deploying a separate ISATAP router and some custom configuration, but once in place it works perfectly. I offer this service to my customers as part of a consulting engagement. If you’re interested in restoring DirectAccess manage out functionality to support SCCM remote control, RDC, or VNC in load-balanced or multisite DirectAccess deployments, fill out the form below and I’ll provide you with more information.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments
DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016
DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out
Video: Windows 10 DirectAccess in action (includes manage out demonstration)

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

Planning and Implementing DirectAccess with Windows Server 2016I’m pleased to announce my newest video training course, Managing and Supporting DirectAccess with Windows Server 2016, is now available on Pluralsight! This new course is a follow-up to my previous course, Planning and Implementing DirectAccess with Windows Server 2016. This latest course builds upon the first one and covers advanced configuration such as enabling load balancing, configuring geographic redundancy, and enforcing strong user authentication using one-time passwords (OTP) and smart cards.

In addition, monitoring and reporting is covered, as well as implementing manage out for DirectAccess clients in supported scenarios. The course also includes a full hour of in-depth DirectAccess configuration and connectivity troubleshooting that will be valuable for all DirectAccess administrators.

The course includes the following training modules:

Configuring High Availability
Enabling Strong User Authentication
DirectAccess Monitoring and Reporting
Implementing Outbound Management for DirectAccess Clients
DirectAccess Troubleshooting

Throughout the course, I share valuable knowledge and insight gained from more than 5 years of experience deploying DirectAccess for some of the largest organizations in the world. Pluralsight offers a free trial subscription if you don’t already have one, so watch my latest DirectAccess video training course today!

Additional Resources

Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Managing and Supporting DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 book

%d bloggers like this: