locked
Help troubleshooting DirectAccess issue RRS feed

 , 
 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi All,

    I was following the Windows 2012 R2 DirectAccess guide to build a lab for testing. I did a small changes in IP addressing but other then that it should be configured as per that MS guide. Here is the config:


    As you can see Edge2 has been added and configured as NLB cluster. All components are green in Remote Access manager on both servers and NLB config is all green and converged.

    NLS is on APP1 and works fine. Public name of DirectAccess server is edge1.contoso.com and this name is being resolved on external DNS running on INET1. to 131.107.0.2. Correct certificates deployed and configured.

    When Client1 (windows 8.1) is on Corpnet all works fine, I can reach internal resources, fileshares, webs etc.

    When Client1 is on Internet DirectAccess connection is in status "Connecting" forever. Transition technology used is IPHTTPS as I have disabled both 6to4 and Teredo.

    PS C:\Users\user1> netsh interface httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://edge1.contoso.com:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface active

    PS C:\Users\user1> get-daconnectionstatus
    Status    : Error
    Substatus : NameResolutionFailure


    I can ping IPv6 of DC1 and APP1 as well as IPv6 VIP of EDGE NLB. I cant however resolve or access anything via DNS name.

    PS C:\Users\user1> netsh namespace show effective

    DNS Effective Name Resolution Policy Table Settings

    Settings for .corp.contoso.com
    ----------------------------------------------------------------------
    DirectAccess (Certification Authority)  :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (DNS Servers)              : 2001:db8:1::2
    DirectAccess (Proxy Settings)           : Bypass proxy


    Settings for nls.corp.contoso.com
    ----------------------------------------------------------------------
    DirectAccess (Certification Authority)  :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings

    When I run DirectAccess Troubleshooting tool I got following - see next post.

    Wednesday, August 27, 2014 3:43 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    I've seen a similar problem caused by the fact that the outbound traffic is not originating from the expected IP address - ie the traffic is originating from one of the nodes rather than the cluster IP address. Your firewall may not be configured to allow this.

    Does DirectAccess work before you implement the NLB cluster? If not, your first step should be to get this working.

    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson


    Thursday, August 28, 2014 3:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Then I've had the same situation as you with a customer and the issue was caused by the firewall infrastructure (they had two firewalls and a series of one-to-one NATings). I had no visibility of the firewall configuration as this was handled externally. However I do know that this issue was caused by fact that the nodes were responding to requests rather than the Cluster VIP (as you'd expect). The firewalls were not configured to handle this and the DirectAccess requests failed. Everything worked as expected using a single server.

    I can't tell you the exact steps to resolve this but it involved Dynamic NAT configuration on the firewalls.

    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    • Proposed as answer by Susie LongModerator Friday, September 5, 2014 1:58 AM
    • Marked as answer by Tullkas Friday, September 5, 2014 6:27 AM
    Thursday, August 28, 2014 3:39 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    [8/27/2014 8:36:40 AM]: In worker thread, going to start the tests.
    [8/27/2014 8:36:40 AM]: Running Network Interfaces tests.
    [8/27/2014 8:36:40 AM]: Internet (Microsoft Hyper-V Network Adapter): fe80::79b3:a90:1c54:2c7c%3;: 131.107.0.103/255.255.255.0;
    [8/27/2014 8:36:40 AM]: Default gateway found for Internet.
    [8/27/2014 8:36:40 AM]: 6TO4 Adapter (Microsoft 6to4 Adapter): 2002:836b:67::836b:67;
    [8/27/2014 8:36:40 AM]: No default gateway found for 6TO4 Adapter.
    [8/27/2014 8:36:40 AM]: Internet has configured the default gateway 131.107.0.10.
    [8/27/2014 8:36:40 AM]: Default gateway 131.107.0.10 for Internet replies on ICMP Echo requests, RTT is 1 msec.
    [8/27/2014 8:36:52 AM]: The public DNS Server (8.8.8.8) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [8/27/2014 8:36:52 AM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [8/27/2014 8:36:52 AM]: Running Inside/Outside location tests.
    [8/27/2014 8:36:52 AM]: NLS is https://nls.corp.contoso.com/.
    [8/27/2014 8:36:52 AM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
    [8/27/2014 8:36:52 AM]: NRPT contains 2 rules.
    [8/27/2014 8:36:52 AM]: Found (unique) DNS server: 2001:db8:1::2
    [8/27/2014 8:36:52 AM]: Send an ICMP message to check if the server is reachable.
    [8/27/2014 8:36:52 AM]: DNS server 2001:db8:1::2 is online, RTT is 53 msec.
    [8/27/2014 8:36:52 AM]: Running IP connectivity tests.
    [8/27/2014 8:36:52 AM]: The 6to4 interface service state is default.
    [8/27/2014 8:36:53 AM]: Teredo inferface status is offline.
    [8/27/2014 8:36:53 AM]: The configured DirectAccess Teredo server is edge1.contoso.com (Group Policy).
    [8/27/2014 8:36:53 AM]: The IPHTTPS interface is operational.
    [8/27/2014 8:36:53 AM]: The IPHTTPS interface status is IPHTTPS interface active.
    [8/27/2014 8:36:53 AM]: IPHTTPS is used as IPv6 transition technology.
    [8/27/2014 8:36:53 AM]: The configured IPHTTPS URL is https://edge1.contoso.com:443.
    [8/27/2014 8:36:53 AM]: IPHTTPS has a single site configuration.
    [8/27/2014 8:36:53 AM]: IPHTTPS URL endpoint is: https://edge1.contoso.com:443.
    [8/27/2014 8:36:53 AM]: Successfully connected to endpoint https://edge1.contoso.com:443.
    [8/27/2014 8:36:53 AM]: No response received from corp.contoso.com.
    [8/27/2014 8:36:53 AM]: Running Windows Firewall tests.
    [8/27/2014 8:36:53 AM]: The current profile of the Windows Firewall is Public.
    [8/27/2014 8:36:53 AM]: The Windows Firewall is enabled in the current profile Public.
    [8/27/2014 8:36:53 AM]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
    [8/27/2014 8:36:53 AM]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
    [8/27/2014 8:36:53 AM]: Running certificate tests.
    [8/27/2014 8:36:53 AM]: Found 1 machine certificates on this client computer.
    [8/27/2014 8:36:53 AM]: Checking certificate [no subject] with the serial number [660000000E1171FD52F450635D00000000000E].
    [8/27/2014 8:36:53 AM]: The certificate [660000000E1171FD52F450635D00000000000E] contains the EKU Client Authentication.
    [8/27/2014 8:37:04 AM]: The trust chain for the certificate [660000000E1171FD52F450635D00000000000E] was sucessfully verified.
    [8/27/2014 8:37:04 AM]: Running IPsec infrastructure tunnel tests.
    [8/27/2014 8:37:04 AM]: Failed to connect to domain sysvol share \\corp.contoso.com\sysvol\corp.contoso.com\Policies.
    [8/27/2014 8:37:04 AM]: Running IPsec intranet tunnel tests.
    [8/27/2014 8:37:04 AM]: Successfully reached 2002:836b:3::836b:3, RTT is 24 msec.
    [8/27/2014 8:37:04 AM]: Successfully reached 2002:836b:2::836b:2, RTT is 10 msec.
    [8/27/2014 8:37:04 AM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.corp.contoso.com.
    [8/27/2014 8:37:04 AM]: Running selected post-checks script.
    [8/27/2014 8:37:04 AM]: No post-checks script specified or the file does not exist.
    [8/27/2014 8:37:04 AM]: Finished running post-checks script.
    [8/27/2014 8:37:04 AM]: Finished running all tests.


    Wednesday, August 27, 2014 3:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I've seen a similar problem caused by the fact that the outbound traffic is not originating from the expected IP address - ie the traffic is originating from one of the nodes rather than the cluster IP address. Your firewall may not be configured to allow this.

    Does DirectAccess work before you implement the NLB cluster? If not, your first step should be to get this working.

    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson


    Thursday, August 28, 2014 3:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi, thanks for reply. Yes DirectAccess & VPN worked well before 2nd node has been added and configured as NLB cluster.
    Thursday, August 28, 2014 3:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Then I've had the same situation as you with a customer and the issue was caused by the firewall infrastructure (they had two firewalls and a series of one-to-one NATings). I had no visibility of the firewall configuration as this was handled externally. However I do know that this issue was caused by fact that the nodes were responding to requests rather than the Cluster VIP (as you'd expect). The firewalls were not configured to handle this and the DirectAccess requests failed. Everything worked as expected using a single server.

    I can't tell you the exact steps to resolve this but it involved Dynamic NAT configuration on the firewalls.

    Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson

    • Proposed as answer by Susie LongModerator Friday, September 5, 2014 1:58 AM
    • Marked as answer by Tullkas Friday, September 5, 2014 6:27 AM
    Thursday, August 28, 2014 3:39 PM