Avatar of GSW Dubs
GSW Dubs
Flag for United States of America asked on

IP-HTTPS Not working error on DirectAccess

I configured DirectAccess on Server 2012 R2 Standard. It was working for a long time and all of a sudden It stops working due to an IP-HTTPS issue. Here is what I am getting when I go to the Operation Status:
The IP-HTTPS listener is inactive and cannot accept connections from DirectAccess clients.
The Listener service has been stopped, or is not configured.
Ensure that the IP-HTTPS listener is listening on port 443 of the external network adapter.

I removed the configuration Setting and reconfigure it the same way I was, but that didn't fix it.
Windows Server 2012SSL / HTTPSRemote Access

Avatar of undefined
Last Comment
GSW Dubs

8/22/2022 - Mon

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
GSW Dubs

Thanks for your response. But I tried everything that you mentioned and also tried everything from this article:

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?
GSW Dubs

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..
Your help has saved me hundreds of hours of internet surfing.
GSW Dubs

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.

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

Microsoft IP-HTTPS Platform Adapter is the hardware that req the driver (inbuilt comes with OS)
... 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.
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
GSW Dubs

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?

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/
GSW Dubs

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.
Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy

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.

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
GSW Dubs

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
GSW Dubs

close the question!