We had an interesting issue with Microsoft Direct Access on Windows 10 latest build 1909.
netsh interface httpstunnel show interface shows the Interface is Active
IPHTTPS interface active
Last Error Code 0x0
The issue appears to be with Name Resolution Policy Table (NRPT). When Windows Firewall was enabled on the client, you were able to ping IPv6 addresses on the Direct Access server through the tunnel but all name resolution failed.
For example, you can ping the tunnel endpoints discoverable using the Get-DAClientExperianceConfiguration cmdlet on the client. You can also ping IPv6 addresses of hostnames previously resolved when the Windows Firewall was in a disabled state. For example, whilst Windows Firewall was in a disabled state, ping domain.local (your AD forest name), copy the IPv6 address, re-enable Windows Firewall and you will notice you can resolve it by the IPv6 address, not by hostname using NRPT.
Resolution
The issue was caused by Windows Firewall set to a disabled state on the server.
What we found was when the Windows Firewall is disabled on the server, Windows Firewall must be disabled on the client.
If DA Server Firewall is disabled, but DA client Firewall is enabled - Direct Access breaks.
If DA Server Firewall is enabled, but DA client Firewall is disabled - Direct Access breaks
You must have Windows Firewall disabled on both the DA Server and DA Client, or enabled on both the DA Server and DA Client.
We also identified another issue on the DA server with regards to Windows Firewall being disabled. In our environment, disabling Windows Firewall on the DA Server breaks Direct Access reporting in the "Remote Access Management" console.
As a result, it is strongly recommended to keep Windows Firewall enabled on both the DA Server and DA clients.
- When Windows Firewall is disabled, Direct Access works on the client.
- Enabling Windows Firewall on the client breaks Direct Access resulting in no connection.
Symptoms of Issue
Here is the symptoms we were receiving:
Get-DAConnectionStatus returned "CouldNotContactDirectAccessServer"
netsh interface httpstunnel show interface shows the Interface is Active
IPHTTPS interface active
Last Error Code 0x0
The issue appears to be with Name Resolution Policy Table (NRPT). When Windows Firewall was enabled on the client, you were able to ping IPv6 addresses on the Direct Access server through the tunnel but all name resolution failed.
For example, you can ping the tunnel endpoints discoverable using the Get-DAClientExperianceConfiguration cmdlet on the client. You can also ping IPv6 addresses of hostnames previously resolved when the Windows Firewall was in a disabled state. For example, whilst Windows Firewall was in a disabled state, ping domain.local (your AD forest name), copy the IPv6 address, re-enable Windows Firewall and you will notice you can resolve it by the IPv6 address, not by hostname using NRPT.
Resolution
The issue was caused by Windows Firewall set to a disabled state on the server.
What we found was when the Windows Firewall is disabled on the server, Windows Firewall must be disabled on the client.
If DA Server Firewall is disabled, but DA client Firewall is enabled - Direct Access breaks.
If DA Server Firewall is enabled, but DA client Firewall is disabled - Direct Access breaks
You must have Windows Firewall disabled on both the DA Server and DA Client, or enabled on both the DA Server and DA Client.
We also identified another issue on the DA server with regards to Windows Firewall being disabled. In our environment, disabling Windows Firewall on the DA Server breaks Direct Access reporting in the "Remote Access Management" console.
As a result, it is strongly recommended to keep Windows Firewall enabled on both the DA Server and DA clients.
No comments:
Post a Comment