locked
Direct Access Configuration Issues RRS feed

  • Question

  • Hi All

    We are piloting DA and I just got the servers and DNS entries in place as well as internet facing access to the CRL. I have a laptop that I can get the HTTPS tunnel setup (we are planning on using this for production none of the other technologies). I have the "DirectAccess Client Troubleshooting Tool" from Microsoft and have been using it to try to identify issues. In the "Interface Test" everything is green. Under "Network Location Test" the DNS server address that it is trying to connect to is the IPV6 address of the DA server internally. I can't get it to display anything but the IPv6 address during setup under "Remote Access Server" the interface shows the same IPv6 address. I don't think that's how it's supposed to work, but I can't seem to stop it from doing that either. 

    In EVERY example I can find of setting this up as a "behind an edge device with single adapter" the screenshots show the IPv4 address of the server, not the IPv6 address. I think this is the problem, but turning off the IPv6 on the adapter prevents me from completing any part of the setup wizards.

    Anyone else run into this? How did you fix it?


    Allen George - MCSE: Server Infrastructure

    Thursday, October 29, 2015 11:29 PM

Answers

  • Hi Gerald,

    Thanks for replying again. I wanted to let you know that about 5 hours after I posted above, I was able to get everything working. The problem in my case required enabling logging of dropped packets on the Windows Firewall on the DirectAccess server. I found that it was dropping request on UDP port 500. I added an exclusion rule to allow incoming traffic on that port, and now name resolution is working correctly. I was using a Windows 7 client as we haven't deployed Windows 8/8.1 or 10 to end users (with only a few exceptions) due to issues with applications that won't use new enough authentication technologies and issues with user complaints around the start menu. We are looking to roll 10 out starting soon though.

    I was successful in testing from my machine and from two other laptops. Two running 10 and the original Windows 7 test machine.

    Thanks again!


    Allen George - MCSE: Server Infrastructure

    • Marked as answer by Allen_George Monday, November 2, 2015 3:53 PM
    Monday, November 2, 2015 3:53 PM

All replies

  • Hi,

    When configuring DirectAccess for the first time, you'll see the IPv4 address of your network adapter.
    This is because the IPv6 configuration is not already created.

    After that, when configuring the Step 2, you'll see the IPv6 address created for your infrastructure on your Network adapter.

    This IPv6 address is also used as the DNS64 address for your client.

    Gerald


    Friday, October 30, 2015 11:40 AM
  • Hi Gerald,

    When I started working on this again this morning - I resolved an issue with the cert that was being used for IPsec. Even though it was green before, it wasn't working. I now have a good tunnel using HTTPS, and can ping the DA server using IPv6. However, I get the message "No response received from internaldomainname.com." in the DirectAccess Client Troubleshooting Tool. I also can't ping my internal domain name. If I run a DNS lookup against the Direct Access server (don't know if this should even work) like nslookup internaldomainname.com IPv6addressofDAServer it doesn't work either. I'm not sure what to check next.


    Allen George - MCSE: Server Infrastructure

    Friday, October 30, 2015 5:49 PM
  • Seems that the DNS64 is not working correctly. Could you post a Diagnostic log from your client?

    Troubleshooting tool is sometimes useful but incomplete.

    Windows 8.x and Windows 10 have built-in diagnostics that provide more detailed information.

    Gerald

    Saturday, October 31, 2015 2:49 PM
  • Hi Gerald,

    Thanks for replying again. I wanted to let you know that about 5 hours after I posted above, I was able to get everything working. The problem in my case required enabling logging of dropped packets on the Windows Firewall on the DirectAccess server. I found that it was dropping request on UDP port 500. I added an exclusion rule to allow incoming traffic on that port, and now name resolution is working correctly. I was using a Windows 7 client as we haven't deployed Windows 8/8.1 or 10 to end users (with only a few exceptions) due to issues with applications that won't use new enough authentication technologies and issues with user complaints around the start menu. We are looking to roll 10 out starting soon though.

    I was successful in testing from my machine and from two other laptops. Two running 10 and the original Windows 7 test machine.

    Thanks again!


    Allen George - MCSE: Server Infrastructure

    • Marked as answer by Allen_George Monday, November 2, 2015 3:53 PM
    Monday, November 2, 2015 3:53 PM
  • Let me guess... You're using McAfee VSE 8.8 ? :-D

    If yes, this problem should be solved by installing Patch 5 (Patch 6 for Windows 10).

    Monday, November 2, 2015 4:02 PM
  • Mebbe.... I'll look into that patch. Thanks again!

    Allen George - MCSE: Server Infrastructure


    Tuesday, November 3, 2015 3:39 PM