From the Command Prompt window, run the netsh interface httpstunnel show interfaces command.https://technet.microsoft.com/en-us/library/ee844126(v=ws.10).aspx
This command should display client in Role and the IP-HTTPS URL in URL.
If the netsh interface httpstunnel show interfaces command displays More data is available, your IP-HTTPS URL is longer than 256 characters. Run the reg delete HKLM\SOFTWARE\Policies\Mic
rosoft\Win dows\TCPIP \v6Transit ion\iphttp s\iphttpsi nterface /f command, install an IP-HTTPS certificate on the DirectAccess server that has a Subject field value less than 235 characters, configure the DirectAccess server with the DirectAccess Setup Wizard to use the new certificate, apply the DirectAccess server settings, and update the computer configuration Group Policy on your DirectAccess clients.
c:\>netsh int https add int client https://yourdirectaccessserver.yourdomain.com/httpspagehttps://waingrositblog.wordpress.com/2014/08/07/directaccess-interfaces-missing-again/
The client and URL modifiers should match another existing and working DirectAccess client, which you can view using:
netsh int https show int
Once that is done you can look in the device manager to see the interface, you can see the interface displayed under the netsh command, and you can see if it is active. Make sure your group policies have been applied using:
Make sure you see your policy(ies) defining DA behavior show as applied and try from outside the corporate network
The IPHTTPS interface status was always disabled (error code 0x0), but switched to 0x274c after ~5 minutes. Based on this error code, we decided to install NetMon 3.4 on the DA server to capture the network traffic. And here’s what we have seen:http://blog.gocloud-security.ch/?p=578
The DA server has reset (flag R) the TCP connection to the DA client after a timeout of ~10s, after the IPHTTPS handshake
There were many ICMP destination unreachable messages with the status ‘fragmentation needed’
So, after a call with the firewall provider (where we learnt that they have set a specific MTU size), we changed the MTU size of the DA server’s external Interface to 1450, and lo and behold, the IPHTTPS interface status was no longer disabled and the client able to connect!
So my conclusion: The IPHTTPS interface status is misleading when there is a misconfiguration of the MTU sizes between the DA server and a firewall.
Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled.http://directaccess.richardhicks.com/2014/01/13/troubleshooting-name-resolution-issues-on-directaccess-clients/
1. Enable all three firewall profiles in Windows Firewall with Advanced Security on the DirectAccess server.
2. Allow inbound ports 80, 443, and 62000 through Windows Firewall with Advanced Security on the DirectAccess server. These ports must be allowed from the internet.
3. When using the single network adapter installation of DirectAccess, this means your DA server is behind NAT. On your external router\firewall, ensure ports 80, 443, and 62000 are forwarded to the DirectAccess server (a.k.a. port forwarding).
I believe in (2), you already configured an actual DNS name, not an IP address. That DNS A record in your organization for the IP address you intend on using for DirectAccess connectivity if you are using and have that A record into the Remote Access Server setup configuration. Regardless that DNS name should be reachable from the internet. Try reboot the DirectAccess server and also check the check the operation status in the Remote Access Administration Console.
Last few points
4. If the IPHTTPS interface is still not active, run gpupdate /force on the DirectAccess server then reboot it again. The interface should be activated and try your clients to connect again.
5. Also good to run gpupdate /force on your clients, reboot them, and verify DirectAccess connectivity too.
MS has more details in troubleshooting if of interest @ https://technet.microsoft.com/en-us/library/ee844126(v=ws.10).aspx