Direct Access Windows 8 Client IPHTTPS active but no connectivity RRS feed

  • Question

  • This is a bit strange - I've set up a simple Server 2012R2 Direct Access server with single NIC behind a NAT, self signed cert though.

    When I try and connect I just get "Connecting" forever - but when I check the IP-HTTPS interface is active and has an address but it's strange, it doesn't look like a public IPv6 address it starts with fd9f:3106 - alongside this there is also a Teredo Tunnel active with a normal looking IPv6 address which I can't quite understand as it should be IP-HTTPS only with a single interface DA server behind NAT.

    On running the Direct Access troubleshooter it says I'm connected to the Microsoft public teredo server... WHY??

    It also says it successfully connected to the endpoint and the DNS tests worked

    Then we come to the certs it says No Usable Machine Cert found - I've looked and the self signed certs have been put into Trusted Root Authority store by the policy - but no go - all the Infrastructure Tunnel test fails with Failed to connect to sysvol and User Tunnel fails to connect to HTTP probe.

    I'm guessing at least part of the problem is the self signed cert but some more experienced advice would be very much appreciated.



    Thursday, January 29, 2015 6:00 AM


  • Hi everyone,

    I finally found out what the problem is and you won't believe it! The simplest thing in the world!

    Some doofus had turned off the Windows Firewall! That's all it was!

    Thanks to everyone who took the time to try and help!


    Friday, February 27, 2015 12:51 AM

All replies

  • From the Planning Guide on Technet:

      • If the DirectAccess client has been assigned a public IPv4 address, it will use the 6to4 transition technology to connect to the intranet. If it is assigned a private IPv4 address, it will use Teredo.
      • If the DirectAccess client cannot connect to the DirectAccess server with 6to4 or Teredo, it will use IP-HTTPS.
      • To use Teredo, you must configure two consecutive IP addresses on the external facing network adapter.
      • You cannot use Teredo if the DirectAccess server has only one network adapter.

    This explains why you use IP-HTTPS

    The IPv6 generated address seems fine for a "Behind a NAT" configuration because the DirectAccess Server create the range iself. Got the explanation once but I can't find it right now :D

    Edit: Found the article (http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html )

    The Self-Signed certificate is only used to validate the IP-HTTPS Tunnel. Not the Infrastructure and Intranet IPsec tunnels.
    You must use a PKI infrastructure to validate your client but this is only required if you want to use Windows 7 as a DirectAccess client.


    Friday, January 30, 2015 10:28 PM
  • Hi Gerald,

    Thanks I appreciate that but you have not in fact answered all my questions, you've explained the IP-HTTPS address so that now makes sense, but not why I seem to have a Teredo tunnel to a public Microsoft Server - I don't want to use Teredo at all. If the cert is only used to validate the IP-HTTPS tunnel why do i get a "No valid machine cert found" error message, and no Infrastructure or User tunnel access? 

    Only running Windows 8 by the way - no Windows 7 and was wanting to use the Kerberos Proxy option which I enabled

    Sunday, February 1, 2015 7:46 PM
  • Hi,

    Teredo is available on DirectAccess server-side if you have two public IPv4 addresses. In your case, with a single NIC, Teredo is not available on DirectAccess-server side.

    But on client-side, default behavior is try to negociate an interface for teredo. Just disable Teredo interface with a netsh interface teredo set state disable. You can do the same for 6to4 because in your scenario, only IPHTTPS will be available at DirectAccess-server side.

    Best regards. 

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Sunday, February 1, 2015 9:50 PM
  • Hello,

    Previous post from Benoit is correct, your Teredo is active because your client is able to contact a Teredo server.
    If you don't want to use Teredo and 6to4 interfaces, just disable them using netsh.
    They're not required for your DirectAccess infrastructure.

    If you're only using Windows 8.x clients, certificates are not mandatory for the Infrastructure Tunnel.
    Can you check in the DirectAccess console setup --> Step 2 (Remote Access Server) --> Authentication if you checked the 'Use computer certificates" ?

    If you checked this part, you need to have a PKI infrastructure deploying Computer Certificate on both the DirectAccess server and your clients. Also, this checkbox is active and greyed if you checked "Enable Windows 7 clients" at the bottom.
    Just disable the "Use computer certificates" and your clients should authenticate using Kerberos only.


    Monday, February 2, 2015 10:44 AM
  • Gerald

    Thank you both and yes I understand it is correct as far as it goes but has not resolved my problem - it has explained something I did not quite comprehend as I expected only an IPHTTPS connection and for that I'm grateful.

    You're suggestion has not resolved the problem either I'm afraid as I have not got "Use computer certificates" checked - I know an internal  PKI infrastructure was needed for this and we don't have one. I only have "Active Directory credentials" selected under Authentication.

    Under Step 4 I have "Do not extend authentication to application servers" as my understanding was that I needed to authenticate to the DA server and it would use Kerberos proxy to authenticate to the other servers as needed so extending it was not needed unless there were security requirements for that - is that correct?

    Monday, February 2, 2015 7:55 PM
  • Hi,

    By defaut, DirectAccess IPsec tunnels are only created between the clients and the DirectAccess server.

    Step 4 is only used if you want additional security between your client and specific servers by creating an IPsec tunnel between them and the client.
    I've never used it because my client already use a lot of extra devices for limiting network access.

    If you're using only Windows 8 clients and didn't checked the "Use computer certificates", you shouldn't have that problem.

    Where did you find the message "No valid machine cert found" ?
    Have you enabled the IPsec audit mode on your client for extra debugging?


    Monday, February 2, 2015 8:46 PM
  • Hi Gerald,

    Good OK thanks that confirms my understanding of Step 4.

    The no machine cert found error came from the Direct Access Troubleshooting tool found here: http://www.microsoft.com/en-us/download/details.aspx?id=41938

    After the no machine cert error was an Infrastructure tunnel error about cannot connect to sysvol share and a user tunnel error about not finding the HTTP probe - I assumed the tunnel errors were because of the certificate error and the self-signed certificate - the deployment instructions mention that you need to publish a CRL to the internet even with a self signed cert but I have not done that as I've never needed to before with a self signed cert and can't find much info about it.

    In all so far I've found this "simplified" deployment more difficult than the Windows Server 2008R2 one I did 5 years ago!

    Tuesday, February 3, 2015 12:53 AM
  • What is the output of netsh Interface iphttps show Interface ?

    Are you using both Win7 and Win8 Clients? Did you install some hotfixes? This link is recommended Reading:

    Tuesday, February 3, 2015 8:09 AM
  • Hi,

    If you don't use PKI, there's no need to publish a CRL because you don't have one.

    Just tested the DirectAccess Troubleshooter on my lab reconfigured for Windows 8.x only without certificates.
    It also reports an error on the certificate because I don't have one but my connection is working.

    [03-02-15 12:06:40]: The public DNS Server ( does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [03-02-15 12:06:41]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [03-02-15 12:06:41]: Running Inside/Outside location tests.
    [03-02-15 12:06:41]: NLS is https://nls.corp.contoso.com/.
    [03-02-15 12:06:41]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
    [03-02-15 12:06:41]: NRPT contains 2 rules.
    [03-02-15 12:06:41]:   Found (unique) DNS server: 2001:db8:2::1
    [03-02-15 12:06:41]:   Send an ICMP message to check if the server is reachable.
    [03-02-15 12:06:41]: DNS server 2001:db8:2::1 is online, RTT is 385 msec.
    [03-02-15 12:06:41]: Running IP connectivity tests.
    [03-02-15 12:06:41]: The 6to4 interface service state is default.
    [03-02-15 12:06:41]: Teredo inferface status is offline.
    [03-02-15 12:06:41]:  The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
    [03-02-15 12:06:42]: The IPHTTPS interface is operational.
    [03-02-15 12:06:42]:  The IPHTTPS interface status is IPHTTPS interface active.
    [03-02-15 12:06:42]: IPHTTPS is used as IPv6 transition technology.
    [03-02-15 12:06:42]:  The configured IPHTTPS URL is https://direct.contoso.com:443.
    [03-02-15 12:06:42]: IPHTTPS has a single site configuration.
    [03-02-15 12:06:42]: IPHTTPS URL endpoint is: https://direct.contoso.com:443.
    [03-02-15 12:06:42]:  Successfully connected to endpoint https://direct.contoso.com:443.
    [03-02-15 12:06:42]: Received response from corp.contoso.com, RTT is 53 msec.
    [03-02-15 12:06:42]: Running Windows Firewall tests.
    [03-02-15 12:06:42]: The current profile of the Windows Firewall is Public.
    [03-02-15 12:06:42]: The Windows Firewall is enabled in the current profile Public.
    [03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
    [03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
    [03-02-15 12:06:42]: Running certificate tests.
    [03-02-15 12:06:42]: No usable machine certificate found.
    [03-02-15 12:06:42]: Found 0 machine certificates on this client computer.
    [03-02-15 12:06:42]: Running IPsec infrastructure tunnel tests.
    [03-02-15 12:06:43]: Successfully connected to domain sysvol share, found 11 policies.
    [03-02-15 12:06:43]: Running IPsec intranet tunnel tests.
    [03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::1, RTT is 333 msec.
    [03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::2, RTT is 26 msec.
    [03-02-15 12:06:44]: Successfully reached HTTP probe at http://directaccess-WebProbeHost.corp.contoso.com.
    [03-02-15 12:06:44]: Running selected post-checks script.
    [03-02-15 12:06:44]: No post-checks script specified or the file does not exist.
    [03-02-15 12:06:44]: Finished running post-checks script.
    [03-02-15 12:06:44]: Finished running all tests.

    This tool is probably configured to test for certificates even if you don't need one in your configuration so this error is normal.

    Your problem is your IPsec tunnels not working. I'll suggest you to enable IPsec audit mode on your client and check the error messages in the Security log in your event viewer. Last thing i just remembered, are you using an anti-virus on your client and/or server? I've got problem with one killing all IPsec packets


    Tuesday, February 3, 2015 11:30 AM
  • I assume you meant this command:

    C:\Windows\system32>netsh interface httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    Role                       : client
    URL                        : https://directaccess.workbase.org.nz:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface active

    The IPHTTPS tunnel is active with an IPv6 address but no Infrastructure or User Tunnel active

    Thanks for pointing out those hotfixes - it's possible one or two of those might help if they do i'll let you know

    Wednesday, February 4, 2015 5:03 AM
  • OK Thanks Gerald, you're right, there's no main mode or quick mode security associations showing in Windows Firewall.

    I'll have to enable the audit on the local laptop though as I don't have ready access to the LAN to update the group policy. I'll let you know if what it comes back with.

    I really appreciate your help a great deal it's already helped make sense of this a lot - now if I can just figure out why IPSEC is failing to work.. I have this connection going through a Cisco ASA - I would have thought that wouldn't matter since it's all 443 traffic, but I have a horrible feeling it's trying to be clever and screwing things up for me - wouldn't be the first time..

    Wednesday, February 4, 2015 5:18 AM
  • OK we have a Main Mode failure though i'm not sure why - No Policy Configured?? But I can see it in the Windows Firewall!:

    An IPsec main mode negotiation failed.

    Local Endpoint:

       Local Principal Name: -

       Network Address: fd9f:3106:7e9b:1000:3:fab8:c7c8:c18f

       Keying Module Port: 500

    Remote Endpoint:

       Principal Name: -

       Network Address: fd9f:3106:7e9b:1000::1

       Keying Module Port: 500

    Additional Information:

       Keying Module Name: IKEv1

       Authentication Method: Unknown authentication

       Role: Initiator

       Impersonation State: Not enabled

       Main Mode Filter ID: 0

    Failure Information:

       Failure Point: Local computer

       Failure Reason: No policy configured

       State: No state

       Initiator Cookie: bb8f28c45417eef3

       Responder Cookie: 0000000000000000

    Wednesday, February 4, 2015 5:40 AM
  • Hi

    To have a complete view enable IPSEC audit on the DirectAccess Gateway. Sometimes we have more informations on This side rather than on client-side.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx

    Wednesday, February 4, 2015 9:04 AM
  • Hi,

    The first tunnel for your configuration is based on HTTPS. This is the DirectAccess entry point.
    When your client has the connectivity, you receive from the server an IPv6 address.

    Then, IPsec tunnels are created between the Public/Private profiles of the Windows Firewall (both server and client)
    IPsec is using UDP 500.

    If your HTTPS Tunnel is up, your client's firewall can contact the server's firewall but...
    Last time I've seen this problem, it was because the DirectAccess server was using McAfee VSE 8.8 (Patch 3 or 4)

    When VSE 8.8 is installed on a Windows Server (or Workstation), something seems to force the Windows Firewall to drop all UPD500 packets and the only way to see it is to enable the Windows Firewall logs. I reported this problem to McAfee last year and they published a new KB that acts as a workaround for me. (https://kc.mcafee.com/corporate/index?page=content&id=KB79622)

    You can try to create an additional rule on your server's firewall allowing incoming UPD500 connections to be sure that something is not messing with the server's configuration.


    Wednesday, February 4, 2015 9:21 AM
  • Hi BenoitS,

    I've done as you suggested and I'm getting exactly the same Main Mode errors on the Direct Access Server - just the Local and Remote Endpoints are switched.

    Interestingly I found this post by someone who's apparently had a lot of experience troubleshooting DA:

    After a few years of working with it, I've found the following 2 things to be the most common reasons for machine-specific infrastructure tunnel problems with DirectAccess.

    1: Certificate problems. The first credential used for the infrastructure tunnel is a certificate. You'll get Policy Not Configured if the certificate is invalid. This could be an caused by an expired certificate, a subject name mismatch, incorrect certificate usage (Server auth/Client auth via the built-in Computer template), or your published revocation list for the root or issuing CA may be out of date.

    Again we come back to what I originally suspected - we are trying to use a self-signed cert - there is no CRL published for it. My suspicion is that the same cert used for the IPHTTPS tunnel is used for the IPSEC tunnels as well and its for the IPSEC tunnels you need the CRL. This page: https://technet.microsoft.com/en-us/library/jj134204.aspx#ConfigCAs on installed DA has the following:

    Self-signed certificate          

    If you use a self-signed certificate, the following are required, if they do not already exist:

    • A website certificate that is used for IP-HTTPS authentication. The certificate subject should be an externally resolvable FQDN that is reachable from the Internet.
    • A CRL distribution point that is reachable from a publicly resolvable FQDN.

    I think I'm going to have to at least try a public SSL Cert and see what happens.

    Tuesday, February 10, 2015 11:02 PM
  • Hello,

    You can try with a public certificate but it will only be used on the IP-HTTPS tunnel and this part of your setup is working because your HTTPS Interface is up and you have received an IPv6 address from your DirectAccess server.

    Can you check your configuration in your server if you didn't active the "Use computer certificates" by mistake?
    If this is not activated, your IPsec Infrastructure Tunnel will not try to authenticate the Main Mode using certificates but with Kerberos.

    Can you post IPsec Main Mode errors from both client and server?

    Also I think you spotted a mistake in the DirectAccess TechNet page.
    A Self-signed certificate generated by the DirectAccess wizard doesn't contains the "CRL Distribution Points" field and only a Certificate Authority will create a CRL which contains revoked certificates.
    Self-Signed certificate can't be revoked.


    Thursday, February 12, 2015 10:28 AM
  • Hi everyone,

    I finally found out what the problem is and you won't believe it! The simplest thing in the world!

    Some doofus had turned off the Windows Firewall! That's all it was!

    Thanks to everyone who took the time to try and help!


    Friday, February 27, 2015 12:51 AM
  • Hello Everyone,

    I have a Direct access configured on Windows server 2012 behind a NAT.

    I get this IPv6 address fdcb:6d2a:35fa:3333::1  and it seems to be local private adresses.

    I wanted to know how

    the direct access client connect to the internal network with this private IPv6 address because  direct access client detect that it is out of the LAN, connection to IPHTTPS tunnel is ok, but still in connecting state.


    Wednesday, July 5, 2017 3:34 PM
  • Most of the time, A DirectAccess client stuck in "Connecting" even if the connection is working is caused by a probe error...
    The probe is the test your client use to validate the connection to your internal network.

    By default, this is  the DirectAccess-WebProbeHost record created by the setup in your DNS.
    If you use this record as the probe and it's deleted from the DNS, your clients will be stuck in a "Connecting" mode.

    Direct Access status Always "Connecting" on Windows 8


    Wednesday, July 5, 2017 6:38 PM