IP-HTTPS Not working error on DirectAccess

one of the most common problem is to do with deploying DirectAccess 2012 behind a NAT using the single network adapter method. If you issue the "netsh interface httpstunnel show interface" in the DirectAccess 2012 and also showed “invalid IPHTTPS URL specified” then it is got do with server then. Quick check on

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

Thanks for your response. But I tried everything that you mentioned and also tried everything from this article:
http://www.joedissmeyer.com/2013/06/directaccess-2012-ip-https-issue-ip.html

That still didn't fix the issue.
I am now thinking about performing a clean installation of the server and start fresh.
What do you think?
Thanks

Also, I have the Microsoft IP-HTTPS Platform Adapter listed in my Device Manager. Is there a way to get the adapter named iphttpsinterface instead? Plus when I do an ipconfig /all, I don't see the iphttpsinterface adapter there..

What's the difference between Microsoft IP-HTTPS Platform Adapter and iphttpsinterface ?

Probably to verify the client interface again and likewise can be done on server too for verification

From the Command Prompt window, run the netsh interface httpstunnel show interfaces command.
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\Microsoft\Windows\TCPIP\v6Transition\iphttps\iphttpsinterface /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.

https://technet.microsoft.com/en-us/library/ee844126(v=ws.10).aspx

Otherwise another is this

c:\>netsh int https add int client https://yourdirectaccessserver.yourdomain.com/httpspage

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:

gpresult -r

Make sure you see your policy(ies) defining DA behavior show as applied and try from outside the corporate network

https://waingrositblog.wordpress.com/2014/08/07/directaccess-interfaces-missing-again/

Microsoft IP-HTTPS Platform Adapter is the hardware that req the driver (inbuilt comes with OS)
http://www.driverscape.com/download/microsoft-ip-https-platform-adapter
... and iphttpsinterface is the same but just that it is the virtual name mapped to the default MS adaptor creating the IPHTTPS tunnel

I was even thinking of enabling and disabling the interface to see if it work, I do get such symptoms at time e.g. netsh interface httpstunnel set state=disabled and netsh interface httpstunnel set state=enabled

Regardless, external factor like FW changes may affect if the client and server are alright (after those verification etc). E.g. the FW MTU may affect the comms with DA

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:

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.

http://blog.gocloud-security.ch/?p=578

I tried all the suggestions above and nothing worked. I end it up performing a clean installation of the server and configure the DA from scratch. It now works, I can connect to it from outside. I now have a small issue with it. I can ping and access shared folders on other servers but not the actual server where the DA is installed. It looks to me like it's a DNS issue but I check my DNS setting for that server and everything looks fine. Can someone help me with this?
Thanks!

May want to check from client the nslookup for that DA server and also check the property of the folder in DA server that is supposed to share (whether the login user is inclusive in those group and allow to browse/access). can compare to those working server with the shared folder to see if there are any diff too. good to also run the client tool just to make sure it is working overall - http://directaccess.richardhicks.com/2014/02/24/microsoft-directaccess-client-troubleshooting-tool/

Thank you for sending me the tool. I ran it and I got green every where.
I forgot to mention that, from outside (after connected to DA), I can successfully ping the ipv6 address of the DA server, but not the fqdn. So that what makes me thing that It might be a DNS issue.

there may be some NRPT setting to further check too

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/

In short if the internal interface of the DA is configured as per the intranet domain and able to reach the DNS server, and NRPT is enabled, outside client can still resolve this DNS via the DNS64 (int is IPv4) even with the enabled NRPT policy if there is exemption...check out the link a/m.

MS suggested troubleshooting step for internal DNS check - https://technet.microsoft.com/en-us/library/ee844142(v=ws.10).aspx
General Methodology for Troubleshooting DirectAccess Connections - https://technet.microsoft.com/en-us/library/ee624058(v=ws.10).aspx

close the question!