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

Top 5 DirectAccess Troubleshooting PowerShell Commands

Top 5 DirectAccess Troubleshooting PowerShell CommandsNative PowerShell commands in Windows 10 make DirectAccess troubleshooting much easier than older operating systems like Windows 7. For example, with one PowerShell command an administrator can quickly determine if a DirectAccess client has received the DirectAccess client settings policy. In addition, PowerShell can be used to view the status of the connection and retrieve additional information or error codes that can be helpful for determining the cause of a failed connection. Further, PowerShell can also be used to review configuration details and perform other troubleshooting and connectivity validation tasks.

Here are my top 5 PowerShell commands for troubleshooting DirectAccess on Windows 10.

1. Get-DAClientExperienceConfiguration

Ensuring that the DirectAccess Client Settings group policy has been applied to the client is one of the first steps in troubleshooting failed DirectAccess connections. While it is possible to use gpresult to do this, using the Get-DAClientExperienceConfiguration PowerShell command is much simpler. If DirectAccess client settings have been applied, the output of the command will include information such as the IPsec tunnel endpoint IPv6 addresses and the Network Connectivity Assistant (NCA) corporate resource URL. If DirectAccess client settings have not been applied, this information will be missing.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 1. DirectAccess Client Settings group policy successfully applied.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 2. DirectAccess Client Settings group policy not applied.

2. Get-NetIPHttpsState

Performance improvements first introduced in Windows 8 have made IP-HTTPS the IPv6 transition technology of choice when it comes to supporting DirectAccess client connectivity. Also, if the DirectAccess server is located behind an edge device performing Network Address Translation (NAT), IP-HTTPS is the only supported transition technology. Using the Get-NetIPHttpsState PowerShell command, the DirectAccess administrator can quickly determine if the IP-HTTPS connection was successful. If it was not, the command will return an error code and interface status that will indicate why the IP-HTTPS connection was unsuccessful.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 3. Get-NetIPHttpsState

3. Get-NetIPHttpsConfiguration

When troubleshooting IP-HTTPS connection failures, it is necessary to obtain additional information to continue the troubleshooting process. Using the Get-NetIPHttpsConfiguration PowerShell command, the DirectAccess administrator can obtain the public hostname for the DirectAccess server and ensure that the name resolves to the correct IP address in DNS and that it is reachable on TCP port 443.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 4. Get-NetIPHttpsConfiguration

4. Resolve-DnsName

Using the Resolve-DnsName PowerShell command is crucial when performing any name resolution tasks on the DirectAccess client. This is because Resolve-DnsName is aware of the Name Resolution Policy Table (NRPT) and will direct name resolution requests accordingly. Tools like nslookup are DNS server testing tools and are unaware of the NRPT. Typically they do not yield expected results when testing name resolution on a DirectAccess client.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 5. Name resolution results from Resolve-DnsName and nslookup.

5. Get-DnsClientNrptPolicy

Often the cause of DirectAccess client connectivity issues is a misconfigured NRPT. Using the Get-DnsClientNrptPolicy PowerShell command the DirectAccess administrator can validate that name resolution requests for host names in any internal namespaces are being sent to the DirectAccess DNS64 IPv6 address.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 6. Get-DnsClientNrptPolicy

Additional Resources

Top 5 DirectAccess Troubleshooting Tips

Troubleshooting Name Resolution Issues on DirectAccess Clients

Learn PowerShell in a Month of Lunches Book by Don Jones and Jeff Hicks

Implementing DirectAccess with Windows Server 2016 Book

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course

 

 

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)

Warning
Warning
Warning

Warning.