none
DirectAccess Failure after working for months RRS feed

  • Question

  • I have a single-NIC DA deployment and internal PKI built up, working great for months. All of a sudden, it stopped working. When I switch networks or reboot the DA conneciton goes connected, sometimes for a few minutes sometimes for seconds. The IPHTTPS tunnel is establishing fine, but the IPSEC Main is failing.

    An IPsec main mode negotiation failed.

    Local Endpoint:
    Local Principal Name: -
    Network Address: x:x:x::428e
    Keying Module Port: 500

    Remote Endpoint:
    Principal Name: -
    Network Address: x:x:x::1000::1
    Keying Module Port: 500

    Additional Information:
    Keying Module Name: AuthIP
    Authentication Method: Unknown authentication
    Role: Initiator
    Impersonation State: Not enabled
    Main Mode Filter ID: 97425

    Failure Information:
    Failure Point: Local computer
    Failure Reason: Negotiation timed out

    State: Sent first (SA) payload
    Initiator Cookie: 300f76a0e9ac9074
    Responder Cookie: 0000000000000000

    The DA Troubleshooter passes when it is connected, and fails when it is not. Certs are good, DNS seems good, not sure where to look. Some of the items in the tool that fail have always failed, even when the tunnel works perfectly.

    [12/4/2017 11:38:06 PM]: In worker thread, going to start the tests.
    [12/4/2017 11:38:06 PM]: Running Network Interfaces tests.
    [12/4/2017 11:38:06 PM]: Wi-Fi (Intel(R) Dual Band Wireless-AC 8265): 192.168.43.252/255.255.255.0;
    [12/4/2017 11:38:06 PM]: Default gateway found for Wi-Fi.
    [12/4/2017 11:38:06 PM]: iphttpsinterface (iphttpsinterface): fdb9:fc65:f09:1000:ddc3:f700:b8c:fc3a;: fdb9:fc65:f09:1000:50c4:6af6:5eff:428e;: fe80::ddc3:f700:b8c:fc3a%20;
    [12/4/2017 11:38:06 PM]: No default gateway found for iphttpsinterface.
    [12/4/2017 11:38:06 PM]: Wi-Fi has configured the default gateway 192.168.43.1.
    [12/4/2017 11:38:06 PM]: Default gateway 192.168.43.1 for Wi-Fi replies on ICMP Echo requests, RTT is 7 msec.
    [12/4/2017 11:38:06 PM]: Received a response from the public DNS server (8.8.8.8), RTT is 121 msec.
    [12/4/2017 11:38:06 PM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [12/4/2017 11:38:06 PM]: Running Inside/Outside location tests.
    [12/4/2017 11:38:06 PM]: NLS is https://DirectAccess-NLS.privdomain.local:62000/insideoutside.
    [12/4/2017 11:38:06 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
    [12/4/2017 11:38:06 PM]: NRPT contains 2 rules.
    [12/4/2017 11:38:06 PM]: Found (unique) DNS server: fdb9:fc65:f09:d188::252
    [12/4/2017 11:38:06 PM]: Send an ICMP message to check if the server is reachable.
    [12/4/2017 11:38:18 PM]: DNS Server fdb9:fc65:f09:d188::252 does not reply on ICMP Echo requests.
    [12/4/2017 11:38:18 PM]: Running IP connectivity tests.
    [12/4/2017 11:38:19 PM]: The 6to4 interface is disabled.
    [12/4/2017 11:38:20 PM]: Teredo inferface status is offline.
    [12/4/2017 11:38:20 PM]: The configured DirectAccess Teredo server is win10.ipv6.microsoft.com..
    [12/4/2017 11:38:20 PM]: The IPHTTPS interface is operational.
    [12/4/2017 11:38:20 PM]: The IPHTTPS interface status is IPHTTPS interface active.
    [12/4/2017 11:38:20 PM]: IPHTTPS is used as IPv6 transition technology.
    [12/4/2017 11:38:20 PM]: The configured IPHTTPS URL is https://directaccess.pubdomain.com:443.
    [12/4/2017 11:38:20 PM]: IPHTTPS has a single site configuration.
    [12/4/2017 11:38:20 PM]: IPHTTPS URL endpoint is: https://directaccess.pubdomain.com:443.
    [12/4/2017 11:38:20 PM]: Successfully connected to endpoint https://directaccess.pubdomain.com:443.
    [12/4/2017 11:38:20 PM]: No response received from privdomain.local.
    [12/4/2017 11:38:20 PM]: Running Windows Firewall tests.
    [12/4/2017 11:38:20 PM]: The current profile of the Windows Firewall is Public.
    [12/4/2017 11:38:21 PM]: The Windows Firewall is enabled in the current profile Public.
    [12/4/2017 11:38:21 PM]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
    [12/4/2017 11:38:21 PM]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
    [12/4/2017 11:38:21 PM]: Running certificate tests.
    [12/4/2017 11:38:21 PM]: Found 1 machine certificates on this client computer.
    [12/4/2017 11:38:21 PM]: Checking certificate CN=CARBONX2.privdomain.local with the serial number [25000000085E0787B4DAC1723Dx8].
    [12/4/2017 11:38:21 PM]: The certificate [25000000085E0787B4DAC1723Dx8] contains the EKU Client Authentication.
    [12/4/2017 11:38:21 PM]: The trust chain for the certificate [25000000085E0787B4DAC1723Dx8] was sucessfully verified.
    [12/4/2017 11:38:21 PM]: Running IPsec infrastructure tunnel tests.
    [12/4/2017 11:38:21 PM]: Failed to connect to domain sysvol share \\privdomain.local\sysvol\privdomain.local\Policies.
    [12/4/2017 11:38:21 PM]: Running IPsec intranet tunnel tests.
    [12/4/2017 11:38:32 PM]: Failed to connect to fdb9:fc65:f09:1000::1 with status TimedOut.
    [12/4/2017 11:38:44 PM]: Failed to connect to fdb9:fc65:f09:1000::2 with status TimedOut.
    [12/4/2017 11:38:44 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.privdomain.local.
    [12/4/2017 11:38:44 PM]: Failed to connect to HTTP probe at http://nls.privdomain.local/account/login/?next=/.
    [12/4/2017 11:38:44 PM]: Running selected post-checks script.
    [12/4/2017 11:38:44 PM]: No post-checks script specified or the file does not exist.
    [12/4/2017 11:38:44 PM]: Finished running post-checks script.
    [12/4/2017 11:38:44 PM]: Finished running all tests.


    "Sadly most places want the Porche fastness and reliablity, but only pay for a used 74 pinto, then they are "Shocked" that it wont run, and blame the IT guy"

    Tuesday, December 5, 2017 4:50 AM

All replies

  • Have you enabled IPsec audit on the server too? Do you see IPsec requests on your server?
    Last time I saw that, it was because an update of the server's antivirus was blocking the IPsec packets.

    Gérald

    Tuesday, December 5, 2017 9:52 PM
  • I agree on checking antivirus, particularly if your AV has any kind of "Network Threat Protection" or firewalling capability of its own. The Windows Firewall is essential to making sure DA works properly, and an AV-based firewall can easily get in the way of what DA tries to do.

    Another thing to check - do your clients have "Intel Online Connect" installed, by chance? This software breaks DirectAccess for an unknown reason. There haven't been enough cases of it yet for Intel to do anything about it, not that I've heard, but uninstalling that software fixes it immediately. The reason this comes to mind is because the places I've seen it are places where the laptop will connect successfully, for a few seconds or sometimes even a few minutes, but then stops working and goes back to a "Connecting" status until you either reboot or restart the IP Helper service. Then it works again for a minute, then breaks again...

    • Proposed as answer by Eric S. Grover Thursday, July 26, 2018 5:27 PM
    Thursday, December 7, 2017 1:20 PM