none
Windows 10 Clients not connecting

    Question

  • I am trying to implement a Direct Access server for testing purposes and with the use of several instructional blogs, I have the server configured and showing all green, but my client can detect when it is on or off the network but fails to completely connect when it is off network.

    My DA server is a 2012 R2 VM with 2 NICs, one in the DMZ and the other on my server vLAN.  Both NICs are configured with static IP, netmask, gateway and DNS, IPv6 is enabled, and the firewalls are "on."  Installation was very much "out of the box" follow the wizard, where the main issue I had to troubleshoot was that the DNS server was the local DA server and not my internal DNS servers.

    With my client I am getting a number of the same DNS related messages both on and off network.  Here are the troubleshooting logs:

    On Network-

    [6/18/2018 11:21:29 AM]: In worker thread, going to start the tests.
    [6/18/2018 11:21:29 AM]: Running Network Interfaces tests.
    [6/18/2018 11:21:29 AM]: Ethernet (Intel(R) 82579LM Gigabit Network Connection): fe80::29cd:5605:43dc:787f%7;: [PC_IP]/255.255.255.0;
    [6/18/2018 11:21:29 AM]: Default gateway found for Ethernet.
    [6/18/2018 11:21:29 AM]: Ethernet has configured the default gateway 192.168.20.1.
    [6/18/2018 11:21:29 AM]: Default gateway 192.168.20.1 for Ethernet replies on ICMP Echo requests, RTT is 25 msec.
    [6/18/2018 11:21:29 AM]: Received a response from the public DNS server (8.8.8.8), RTT is 18 msec.
    [6/18/2018 11:21:40 AM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [6/18/2018 11:21:40 AM]: Running Inside/Outside location tests.
    [6/18/2018 11:21:40 AM]: NLS is https://[NLS DNS Name]/.
    [6/18/2018 11:21:41 AM]: NLS is reachable via HTTPS, the client computer is connected to the corporate network (internal).
    [6/18/2018 11:21:41 AM]: NRPT contains 3 rules.
    [6/18/2018 11:21:41 AM]: Found (unique) DNS server: fd74:b930:60d8:3333::1
    [6/18/2018 11:21:41 AM]: Send an ICMP message to check if the server is reachable.
    [6/18/2018 11:21:53 AM]: DNS Server fd74:b930:60d8:3333::1 does not reply on ICMP Echo requests.
    [6/18/2018 11:21:53 AM]: Running IP connectivity tests.
    [6/18/2018 11:21:54 AM]: The 6to4 interface service state is default.
    [6/18/2018 11:21:55 AM]: Teredo inferface status is offline.
    [6/18/2018 11:21:55 AM]: The configured DirectAccess Teredo server is win1710.ipv6.microsoft.com..
    [6/18/2018 11:21:56 AM]: The IPHTTPS interface is operational.
    [6/18/2018 11:21:56 AM]: The IPHTTPS interface status is IPHTTPS interface not installed..
    [6/18/2018 11:21:56 AM]: Teredo is used as IPv6 transition technology.
    [6/18/2018 11:21:56 AM]: The configured IPHTTPS URL is https://da.[Domain]:443.
    [6/18/2018 11:21:56 AM]: IPHTTPS has a single site configuration.
    [6/18/2018 11:21:56 AM]: IPHTTPS URL endpoint is: https://da.[Domain]:443.
    [6/18/2018 11:21:56 AM]: Failed to connect to endpoint https://da.[Domain]:443.
    [6/18/2018 11:22:07 AM]: No response received from ad.[Domain].
    [6/18/2018 11:22:07 AM]: Running Windows Firewall tests.
    [6/18/2018 11:22:07 AM]: Warning - the current profile of the Windows Firewall is Domain.
    [6/18/2018 11:22:07 AM]: The Windows Firewall is enabled in the current profile Domain.
    [6/18/2018 11:22:08 AM]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
    [6/18/2018 11:22:08 AM]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
    [6/18/2018 11:22:08 AM]: Running certificate tests.
    [6/18/2018 11:22:08 AM]: Found 2 machine certificates on this client computer.
    [6/18/2018 11:22:08 AM]: Checking certificate [no subject] with the serial number [190000004E031D1E276A02FFAA00010000004E].
    [6/18/2018 11:22:08 AM]: The certificate [190000004E031D1E276A02FFAA00010000004E] contains the EKU Client Authentication.
    [6/18/2018 11:22:08 AM]: The trust chain for the certificate [190000004E031D1E276A02FFAA00010000004E] was sucessfully verified.
    [6/18/2018 11:22:08 AM]: Checking certificate CN=[PCName].ad.[Domain] with the serial number [190000004D1E070D2E777F401C00010000004D].
    [6/18/2018 11:22:08 AM]: The certificate [190000004D1E070D2E777F401C00010000004D] contains the EKU Client Authentication.
    [6/18/2018 11:22:08 AM]: The trust chain for the certificate [190000004D1E070D2E777F401C00010000004D] was sucessfully verified.
    [6/18/2018 11:22:08 AM]: Running IPsec infrastructure tunnel tests.
    [6/18/2018 11:22:08 AM]: Successfully connected to domain sysvol share, found 31 policies.
    [6/18/2018 11:22:08 AM]: Running IPsec intranet tunnel tests.
    [6/18/2018 11:22:19 AM]: Failed to connect to fd74:b930:60d8:1000::1 with status TimedOut.
    [6/18/2018 11:22:31 AM]: Failed to connect to fd74:b930:60d8:1000::2 with status TimedOut.
    [6/18/2018 11:22:31 AM]: Successfully reached HTTP probe at http://directaccess-WebProbeHost.ad.[Domain].
    [6/18/2018 11:22:31 AM]: Running selected post-checks script.
    [6/18/2018 11:22:31 AM]: No post-checks script specified or the file does not exist.
    [6/18/2018 11:22:31 AM]: Finished running post-checks script.
    [6/18/2018 11:22:31 AM]: Finished running all tests.

    Off Network

    [6/18/2018 11:19:41 AM]: In worker thread, going to start the tests.
    [6/18/2018 11:19:41 AM]: Running Network Interfaces tests.
    [6/18/2018 11:19:41 AM]: Wi-Fi (Intel(R) Centrino(R) Advanced-N 6205): fe80::88be:56fb:5811:e833%2;: [PC_IP]/255.255.255.0;
    [6/18/2018 11:19:41 AM]: Default gateway found for Wi-Fi.
    [6/18/2018 11:19:41 AM]: Teredo Tunneling Pseudo-Interface (Teredo Tunneling Pseudo-Interface): 2001:0:9d38:953c:189e:9518:94a3:8539;: fe80::189e:9518:94a3:8539%5;
    [6/18/2018 11:19:41 AM]: Default gateway found for Teredo Tunneling Pseudo-Interface.
    [6/18/2018 11:19:41 AM]: Wi-Fi has configured the default gateway 192.168.1.1.
    [6/18/2018 11:19:41 AM]: Default gateway 192.168.1.1 for Wi-Fi replies on ICMP Echo requests, RTT is 14 msec.
    [6/18/2018 11:19:41 AM]: Teredo Tunneling Pseudo-Interface has configured the default gateway ::.
    [6/18/2018 11:19:41 AM]: Warning - default gateway :: for Teredo Tunneling Pseudo-Interface does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [6/18/2018 11:19:41 AM]: Received a response from the public DNS server (8.8.8.8), RTT is 201 msec.
    [6/18/2018 11:19:53 AM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [6/18/2018 11:19:53 AM]: Running Inside/Outside location tests.
    [6/18/2018 11:19:53 AM]: NLS is https://[NLS DNS Name]/.
    [6/18/2018 11:20:14 AM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
    [6/18/2018 11:20:14 AM]: NRPT contains 3 rules.
    [6/18/2018 11:20:14 AM]: Found (unique) DNS server: fd74:b930:60d8:3333::1
    [6/18/2018 11:20:14 AM]: Send an ICMP message to check if the server is reachable.
    [6/18/2018 11:20:26 AM]: DNS Server fd74:b930:60d8:3333::1 does not reply on ICMP Echo requests.
    [6/18/2018 11:20:26 AM]: Running IP connectivity tests.
    [6/18/2018 11:20:27 AM]: The 6to4 interface service state is default.
    [6/18/2018 11:20:27 AM]: Teredo inferface status is online.
    [6/18/2018 11:20:27 AM]: The configured DirectAccess Teredo server is win1710.ipv6.microsoft.com..
    [6/18/2018 11:20:28 AM]: The IPHTTPS interface is not operational, last error code is 0x2af9.
    [6/18/2018 11:20:28 AM]: The IPHTTPS interface status is failed to connect to the IPHTTPS server. Waiting to reconnect.
    [6/18/2018 11:20:28 AM]: Teredo is used as IPv6 transition technology.
    [6/18/2018 11:20:28 AM]: The configured IPHTTPS URL is https://da.[Domain]:443.
    [6/18/2018 11:20:28 AM]: IPHTTPS has a single site configuration.
    [6/18/2018 11:20:28 AM]: IPHTTPS URL endpoint is: https://da.[Domain]:443.
    [6/18/2018 11:20:28 AM]: Failed to connect to endpoint https://da.[Domain]:443.
    [6/18/2018 11:20:28 AM]: No response received from ad.[Domain].
    [6/18/2018 11:20:28 AM]: Running Windows Firewall tests.
    [6/18/2018 11:20:28 AM]: The current profile of the Windows Firewall is Public.
    [6/18/2018 11:20:28 AM]: The Windows Firewall is enabled in the current profile Public.
    [6/18/2018 11:20:28 AM]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
    [6/18/2018 11:20:28 AM]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
    [6/18/2018 11:20:28 AM]: Running certificate tests.
    [6/18/2018 11:20:28 AM]: Found 2 machine certificates on this client computer.
    [6/18/2018 11:20:28 AM]: Checking certificate [no subject] with the serial number [190000004E031D1E276A02FFAA00010000004E].
    [6/18/2018 11:20:28 AM]: The certificate [190000004E031D1E276A02FFAA00010000004E] contains the EKU Client Authentication.
    [6/18/2018 11:20:28 AM]: The trust chain for the certificate [190000004E031D1E276A02FFAA00010000004E] was sucessfully verified.
    [6/18/2018 11:20:28 AM]: Checking certificate CN=[PCName].ad.[Domain] with the serial number [190000004D1E070D2E777F401C00010000004D].
    [6/18/2018 11:20:28 AM]: The certificate [190000004D1E070D2E777F401C00010000004D] contains the EKU Client Authentication.
    [6/18/2018 11:20:28 AM]: The trust chain for the certificate [190000004D1E070D2E777F401C00010000004D] was sucessfully verified.
    [6/18/2018 11:20:28 AM]: Running IPsec infrastructure tunnel tests.
    [6/18/2018 11:20:28 AM]: Failed to connect to domain sysvol share \\ad.[Domain]\sysvol\ad.[Domain]\Policies.
    [6/18/2018 11:20:28 AM]: Running IPsec intranet tunnel tests.
    [6/18/2018 11:20:39 AM]: Failed to connect to fd74:b930:60d8:1000::1 with status TimedOut.
    [6/18/2018 11:20:51 AM]: Failed to connect to fd74:b930:60d8:1000::2 with status TimedOut.
    [6/18/2018 11:20:51 AM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.ad.[Domain].
    [6/18/2018 11:20:51 AM]: Running selected post-checks script.
    [6/18/2018 11:20:51 AM]: No post-checks script specified or the file does not exist.
    [6/18/2018 11:20:51 AM]: Finished running post-checks script.
    [6/18/2018 11:20:51 AM]: Finished running all tests.

    It appears that my main issue(s) are that I'm having DNS connection issues, which doesn't surprise me.  This is the first thing in my environment that requires IPv6 to operate, so I don't really have a configured infrastructure for it.  Another thing that I'm not quite clear on is whether I need to install DNS services on the DA server itself, which currently, I don't.  In my current iteration of troubleshooting these are where I'm focusing my research but I'm not finding much.  Does anyone have some advice or see something that I don't, I am new to reading these logs after all and am probably missing something. Thanks

    lundi 18 juin 2018 16:27

Toutes les réponses

  • DA server should not be the DNS server. For WAN nic, you need public domain registered in the internet which then solve to your adress. So, clients ourside will locate you DA server based on your's ISP public DNS. For testing purposes, start with IP-https protocol, disable others.

    Because you´re studying this, will you establish the communication via public Internet or are you tend to create 2 different network segmends in your HyperV/VMware?

    Stop study DA, go with VPN Always-ON. DA will be dead in a few years...


    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    lundi 18 juin 2018 21:38
  • Yannara, I'll have to respectfully disagree with you about DA being dead in a few years. :) It is still being rolled out to new customers on a regular basis, and all indications are that it is still fully inside Server 2019. So at a minimum we are still talking about 10 years (support-wise). While Always On VPN has new functionality being added to it and will certainly be a great technology, the recommendation to roll out client-side settings via SCCM or Intune is a hard sell for many SMB customers.

    https://www.ivonetworks.com/2018/06/directaccess-and-always-on-vpn-is-da-being-deprecated/

    That being said - Mark, if you're still working on your DA test I think you'll have to go back to "square one" (networking) and start again from there in order to make sure things are right. You mentioned that you had dual NICs, which is good (single NIC DA comes with some potential issues), but you mentioned that you had IP/subnet/gateway/etc on both NICs and that is incorrect. The most important rule of networking any multi-homed system (dual NICs), especially in the Windows Server world, is that only one NIC gets a Default Gateway. That NIC must be the External NIC in this case. Since you can only have a Default Gateway on the External NIC, it means building out the internal routing table statically. Getting this part right is critical to making DA work properly in the end.

    It's also important to note that you don't need anything at all to be IPv6 inside your network - DirectAccess works around that and 99% of all the implementations I've ever done have been inside completely IPv4 networks.

    I try never to self-promote on these forums, but posts such as yours were the primary reason that this book was created in the first place - it's kind of a quick-start guide on making sure DA is configured with best practices in mind (specifically the networking best practices), if you're ever interested: https://www.amazon.com/Microsoft-DirectAccess-Best-Practices-Troubleshooting-ebook/dp/B00FWIP0SM/ref=sr_1_5?ie=UTF8&qid=1532973076&sr=8-5&keywords=jordan+krause

    lundi 30 juillet 2018 17:55
  • Yannara, I'll have to respectfully disagree with you about DA being dead in a few years. :) It is still being rolled out to new customers on a regular basis, and all indications are that it is still fully inside Server 2019. So at a minimum we are still talking about 10 years (support-wise). While Always On VPN has new functionality being added to it and will certainly be a great technology, the recommendation to roll out client-side settings via SCCM or Intune is a hard sell for many SMB customers.

    https://www.ivonetworks.com/2018/06/directaccess-and-always-on-vpn-is-da-being-deprecated/


    You are correct that DA will remain in srv 2019, which means DA has still pretty long life time. But, practise has showned that still in srv 2012 R2, DA is not so easy and not se reliable as it should be. Because of the very hard AD+GPO depency, DA is only recommened as work-at-home-solution, and the realibility is far from 100%. This means, if something goes wrong (network changes, server re-build, AD/GPO changes), end users are forced to come back to the office, and that factor pretty much eleminates DA usage when we are talking about Branch Offices.

    Saying that, VPN ALO is so_much_better, that today there no sense to build new infrasturctures based on DA (unless you are stuck with Win7 and that is your another big issue :D). 

    I would be happy to hear your oppisite comments on this view, if you have one. Cheers!


    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.


    • Modifié yannara lundi 30 juillet 2018 18:53
    lundi 30 juillet 2018 18:53
  • Sorry for the delay Yannara, I don't always receive notifications when replies have been plugged into these forums.

    I actually find DirectAccess to be extremely reliable. Especially compared with other remote access technologies I have spent years working with. In general I receive far fewer support calls for DirectAccess than for VPNs, SSLVPNs, or RDS-type solutions.

    Usually my customers see the AD+GPO "dependency" to be a benefit. It's generally easier to roll settings around via Group Policy than SCCM/Intune, especially for a company that doesn't have SCCM or Intune. That is what I am bumping into often these days when looking at AOVPN - being built around MDM is often a roadblock. Everyone has Group Policy, not everyone has MDM...

    There are a few kinks still being worked out with AOVPN too, like the ability to co-exist device and user tunnels. I hope all of these things are ironed out soon (and I also really hope GPO-based AOVPN setting rollout is something that gets added!), because it would enable me to install it in many places right now.

    jeudi 23 août 2018 15:12
  • If you can run powershell inside Group Policies Preferences as task scheduler, you might be able to deploy VPN profile with GPO as well.

    MCSE Mobility 2018. Expert on SCCM, Windows 10 and MBAM.

    vendredi 24 août 2018 05:24
  • Having both gateways on your 2 NICs is not good and you should have got a warning message. Only keep it on the external. for the internal NIC since there is not gateway you will need to create static routes to your internal network subnets.

    DNS should be on another server.

    Ensure the Network Location server (NLS) is working and validated from the DA GUI Wizard. The external certificate for your da.company.com is recommended to be public SSL.

    Make sure the da.comapny.com is resolving to public IP on your firewall / edge network with needed NAT rule (If any)

    mardi 4 septembre 2018 08:59
    Modérateur