After installing and configuring DirectAccess in Windows Server 2019 you may encounter an error message indicating that IP-HTTPS is not working properly. Looking at the Operations Status overview in the Dashboard of the Remote Access Management console shows that the IP-HTTPS interface is in error.
IP-HTTPS Route Error
Viewing the detailed Operations Status shows the following error message.
Error: The IP-HTTPS route does not have published property enabled.
Missing Route
Looking at the routing table on the DirectAccess server reveals that a route to the client IPv6 prefix is indeed missing.
Resolution
To resolve this error message, add the client IPv6 route to the DirectAccess server’s routing table and publish it. This is accomplished by running the following PowerShell commands on the DirectAccess server.
Next, restart the Remote Access Management service (RaMgmtSvc) using the following PowerShell command.
Restart-Service RaMgmtSvc -PassThru
Once complete, refresh the management console and the IP-HTTPS error message should be resolved and the operations status should state that it is now working properly.
PowerShell is an essential tool for Windows administrators for configuration, task automation, monitoring, reporting, and problem resolution. When troubleshooting DirectAccess connectivity using the IP-HTTPS IPv6 transition technology, the Get-NetIPHttpsConfiguration and Get-NetIPHttpsState PowerShell commands are important for assessing the configuration and current state of the IP-HTTPS connection. When DirectAccess connectivity fails, these are some of the first commands an administrator will use to identify and resolve the issue.
Get-NetIPHttpsState
Get-NetIPHttpsState is especially helpful when IP-HTTPS connectivity fails because it returns an error code and interface status information that can provide clues as to why the connection was not completed successfully.
No Output in 1803
Beginning with Windows 10 1803, the DirectAccess administrator will notice that Get-NetIPHttpsState returns no data. The output of Get-NetIPHttpsState is blank.
Changes in 1803
As it turns out, this is a bug first introduced in Windows 10 1803 that is the result of a fundamental change in the way in which the IP-HTTPS interface is implemented in Windows. As of this writing, the bug has not been addressed in Windows 10 1803 or 1809.
Workaround
The good news is that there’s an easy workaround for this. Instead of using Get-NetIPHttpsState, the administrator can retrieve essential information about the IP-HTTPS interface using the following netsh command.
DirectAccess 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
$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”)
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”)
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.
PowerShell is an essential tool for Windows administrators for configuration, task automation, monitoring, reporting, and problem resolution. When troubleshooting DirectAccess connectivity using the IP-HTTPS IPv6 transition technology, the 
DirectAccess 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.
