none
Having issues with Windows 10 Enterprise clients connecting to DirectAccess

    Question

  • Hi All,

    I'm trying to re-set up DirectAccess for our internal users as the old environment just stopped working one day. The DA servers is Windows2012R2 with a single NIC behind an Edge router. Our internal domain name is not reachable from the outside, but we do have a public domain name that points to the internal server. On the DA server, all dashboard diagnostics show green so I'm fairly confident that the issue is with the client machine.

    On the client, I've confirmed that it has the proper security group and GPO. It passes the WMI filtering as well. When I connect to a network that's not on the domain, the DirectAccess service tries to connect but never fully establishes a connection. I'm posting the output of the DirectAccess Client Troubleshooting Tool and have changed the internal and external domain names for security. Any help would be greatly appreciated.

    [4/13/2016 2:47:07 PM]: User canceled the tests.
    [4/13/2016 2:47:08 PM]: In worker thread, going to start the tests.
    [4/13/2016 2:47:08 PM]: Running Network Interfaces tests.
    [4/13/2016 2:47:08 PM]: VMware Network Adapter VMnet1 (VMware Virtual Ethernet Adapter for VMnet1): fe80::3426:769:fbee:6e74%27;: 192.168.52.1/255.255.255.0;
    [4/13/2016 2:47:08 PM]: No default gateway found for VMware Network Adapter VMnet1.
    [4/13/2016 2:47:08 PM]: VMware Network Adapter VMnet8 (VMware Virtual Ethernet Adapter for VMnet8): fe80::cd01:47d0:a9f8:834a%6;: 192.168.135.1/255.255.255.0;
    [4/13/2016 2:47:08 PM]: No default gateway found for VMware Network Adapter VMnet8.
    [4/13/2016 2:47:08 PM]: Wi-Fi (Marvell AVASTAR Wireless-AC Network Controller): 2602:304:b319:d780:1d81:5c4e:f26f:5077;: 2602:304:b319:d780:edec:6b68:55eb:5192;: fe80::1d81:5c4e:f26f:5077%21;: 192.168.1.240/255.255.255.0;
    [4/13/2016 2:47:08 PM]: Multiple default gateways found for Wi-Fi!
    [4/13/2016 2:47:08 PM]: Teredo Tunneling Pseudo-Interface (Teredo Tunneling Pseudo-Interface): 2001:0:9d38:90d7:1036:f29:b4ce:6287;: fe80::1036:f29:b4ce:6287%17;
    [4/13/2016 2:47:08 PM]: No default gateway found for Teredo Tunneling Pseudo-Interface.
    [4/13/2016 2:47:08 PM]: Warning - this client computer has multiple default gateways defined!
    [4/13/2016 2:47:08 PM]: Wi-Fi has configured the default gateway fe80::3e36:e4ff:fe66:7ca0%21.
    [4/13/2016 2:47:08 PM]: Default gateway fe80::3e36:e4ff:fe66:7ca0%21 for Wi-Fi replies on ICMP Echo requests, RTT is 3 msec.
    [4/13/2016 2:47:08 PM]: Wi-Fi has configured the default gateway 192.168.1.254.
    [4/13/2016 2:47:08 PM]: Default gateway 192.168.1.254 for Wi-Fi replies on ICMP Echo requests, RTT is 1 msec.
    [4/13/2016 2:47:08 PM]: Received a response from the public DNS server (8.8.8.8), RTT is 67 msec.
    [4/13/2016 2:47:08 PM]: Received a reply from the public DNS server (2001:4860:4860::8888), RTT is 66 msec.
    [4/13/2016 2:47:08 PM]: Running Inside/Outside location tests.
    [4/13/2016 2:47:08 PM]: NLS is https://DirectAccess-NLS.<internal name>.com:62000/insideoutside.
    [4/13/2016 2:47:08 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
    [4/13/2016 2:47:08 PM]: NRPT contains 2 rules.
    [4/13/2016 2:47:08 PM]:      Found (unique) DNS server: fded:4b9:e759:3333::1
    [4/13/2016 2:47:08 PM]:      Send an ICMP message to check if the server is reachable.
    [4/13/2016 2:47:14 PM]: DNS Server fded:4b9:e759:3333::1 does not reply on ICMP Echo requests.
    [4/13/2016 2:47:20 PM]: DNS Server fded:4b9:e759:3333::1 does not reply on ICMP Echo requests.
    [4/13/2016 2:47:20 PM]: Running IP connectivity tests.
    [4/13/2016 2:47:20 PM]: The 6to4 interface service state is default.
    [4/13/2016 2:47:20 PM]: Teredo inferface status is online.
    [4/13/2016 2:47:20 PM]:     The configured DirectAccess Teredo server is win10.ipv6.microsoft.com..
    [4/13/2016 2:47:20 PM]: The IPHTTPS interface is operational.
    [4/13/2016 2:47:20 PM]:     The IPHTTPS interface status is IPHTTPS interface active.
    [4/13/2016 2:47:20 PM]: IPHTTPS is used as IPv6 transition technology.
    [4/13/2016 2:47:20 PM]:     The configured IPHTTPS URL is https://directaccess.<external name>.com:443.
    [4/13/2016 2:47:20 PM]: IPHTTPS has a single site configuration.
    [4/13/2016 2:47:20 PM]: IPHTTPS URL endpoint is: https://directaccess.<external name>.com:443.
    [4/13/2016 2:47:20 PM]:     Successfully connected to endpoint https://directaccess.<external name>.com:443.
    [4/13/2016 2:47:20 PM]: No response received from <internal name>.com.
    [4/13/2016 2:47:20 PM]: Running Windows Firewall tests.
    [4/13/2016 2:47:20 PM]: The current profile of the Windows Firewall is Public.
    [4/13/2016 2:47:20 PM]: The Windows Firewall is enabled in the current profile Public.
    [4/13/2016 2:47:20 PM]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
    [4/13/2016 2:47:20 PM]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
    [4/13/2016 2:47:20 PM]: Running certificate tests.
    [4/13/2016 2:47:20 PM]: No usable machine certificate found.
    [4/13/2016 2:47:20 PM]: Found 0 machine certificates on this client computer.
    [4/13/2016 2:47:20 PM]: Running IPsec infrastructure tunnel tests.
    [4/13/2016 2:47:20 PM]: Failed to connect to domain sysvol share \\<internal name>.com\sysvol\<internal name>.com\Policies.
    [4/13/2016 2:47:20 PM]: Running IPsec intranet tunnel tests.
    [4/13/2016 2:47:20 PM]: Successfully reached fded:4b9:e759:1000::1, RTT is 11 msec.
    [4/13/2016 2:47:20 PM]: Successfully reached fded:4b9:e759:1000::2, RTT is 10 msec.
    [4/13/2016 2:47:20 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.<internal name>.com.
    [4/13/2016 2:47:20 PM]: Successfully reached HTTP probe at http://directaccess.<external name>.com/.
    [4/13/2016 2:47:20 PM]: Running selected post-checks script.
    [4/13/2016 2:47:20 PM]: No post-checks script specified or the file does not exist.
    [4/13/2016 2:47:20 PM]: Finished running post-checks script.
    [4/13/2016 2:47:20 PM]: Finished running all tests.
    jeudi 14 avril 2016 14:38

Réponses

  • You can't disable the firewall... It's required for the IPsec tunnels.

    These tunnels are created between the client and the server's firewall so at least, it must be up on the Public profile.
    As you have a single NIC setup, i think that it must be up on the Domain profile also.

    That's why you can't connect.


    jeudi 28 avril 2016 16:36

Toutes les réponses

  • I already saw DirectAccess clients having troubles when they also have an official IPv6 address.
    Did you tried with IPv6 protocol disabled on your Wireless card?

    Also, one of your probe is not responding, does the record exist in your internal DNS?

    [4/13/2016 2:47:20 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.<internal name>.com.

    Gerald


    vendredi 15 avril 2016 13:41
  • I've disabled my ipv6 on my wireless card but that doesn't seem to have made a difference. That address is in dns as well.
    dimanche 17 avril 2016 16:16
  • The IP-HTTPS interface is working because you receive an IPv6 address.

    [4/13/2016 2:47:20 PM]: Failed to connect to domain sysvol share \\<internal name>.com\sysvol\<internal name>.com\Policies.

    Seems that IPsec tunnels are not connected so you should have a look there.
    Try to enable IPsec audit on both client and server to see if you have any errors.

    dimanche 17 avril 2016 21:15
  • Here's what I'm seeing in my security logs. In the System logs I see a bunch of DNS errors, probably related to not being able to connect to the network.

    An IPsec main mode negotiation failed.
    
    Local Endpoint:
    	Local Principal Name:	-
    	Network Address:	fded:4b9:e759:1000:d1ad:6876:e69:3172
    	Keying Module Port:	500
    
    Remote Endpoint:
    	Principal Name:		-
    	Network Address:	fded:4b9:e759: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:		c84d13c4e351d4e1
    	Responder Cookie:	0000000000000000

    An IPsec main mode negotiation failed.
    
    Local Endpoint:
    	Local Principal Name:	-
    	Network Address:	fded:4b9:e759:1000:d1ad:6876:e69:3172
    	Keying Module Port:	500
    
    Remote Endpoint:
    	Principal Name:		-
    	Network Address:	fded:4b9:e759: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:	570777
    
    Failure Information:
    	Failure Point:		Local computer
    	Failure Reason:		Negotiation timed out
    
    	State:			Sent first (SA) payload
    	Initiator Cookie:		28a32f6f7e939fda
    	Responder Cookie:	0000000000000000


    mardi 19 avril 2016 18:50
  • So, it seems that your client can contact the DirectAccess server using HTTPS (IP-HTTPS interface) but not UDP 500 (IPsec).

    First, check that Windows Firewall is up and running on both client and server.

    Last time I saw that, it was caused by McAfee installed on the server but it could also be another another antivirus.
    If you are using McAfee Viruscan 8.8, I think they have solved the problem with Patch 5 or 6.

    Another thing you can do to be sure that UDP500 is reachable is to create an Inbound rule in the server's firewall allowing UDP 500.

     

    Gerald


    mercredi 20 avril 2016 07:20
  • Hi Gerald,

    I have the firewall completely disabled on the direct access server and even opened up the ports on the external firewall. I'm still seeing the same issue.

    jeudi 28 avril 2016 14:03
  • You can't disable the firewall... It's required for the IPsec tunnels.

    These tunnels are created between the client and the server's firewall so at least, it must be up on the Public profile.
    As you have a single NIC setup, i think that it must be up on the Domain profile also.

    That's why you can't connect.


    jeudi 28 avril 2016 16:36
  • Thank you Gérald Mathieu! That took care of it.
    jeudi 28 avril 2016 18:02
  • Thank you! Enabling domain firewall fixed it for me.
    lundi 19 mars 2018 11:11
  • I was testing my DA config one day and disabled all the server's firewalls for test purposes. I had no idea the relevant firewalls had to be enabled for DA to work! It seems counter-intuitive to me. I had assumed that if the firewalls are OFF then all traffic would pass through OK.

    Anyhow, it fixed my clients' 'Connecting' issue by turning them on again, and having the correct rules in place.

    mardi 15 mai 2018 13:28