none
DirectAccess Connectivity Assistant "Resolved Name" RRS feed

  • Question

  • I've got DirectAccess working and have been using the pretty wonderful DCA for easy diagnostics of the connection.  I have it configured to perform three tests to validate that connectivity to the CorpNet is working; PING, FILE and HTTP tests.  I have noticed that the HTTP test often results in "RESOLVED NAME" instead of PASSED or FAILED, however the net result is the DCA indicates it is unable to connect to some corporate resources and the DCA shows a red X.  This leads to users thinking DirectAccess is not working when in fact it is.

    I have tried setting the HTTP test to use a different internal web server, specifying a partifular html file on the site, I even stood up a new IIS server with nothing but a single index.html file, but I still get this "RESOLVED NAME" instead of PASSED status.  I _can_ load the tested page in IE over DirectAccess just fine.  And the test eventually (after 2mins or so) passes and the DCA shows that DirectAccess is working, but that delay seems odd and I would like to correct it.

    Any suggestions on what I can do other than simply not do the HTTP test?


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Thursday, May 27, 2010 3:28 PM

Answers

  • netsh interface teredo set state disable

    and then

    netsh interface teredo set state client

    or

    netsh interface teredo set state enterpriseclient

    to enable again...


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    • Marked as answer by Erez Benari Tuesday, June 29, 2010 8:18 PM
    Wednesday, June 9, 2010 9:50 PM
    Moderator
  • Also, if you're using a device in front of the DA client that is capable of being a 6to4 router, check to see that that feature is disabled, otherwise you might see that the 6to4 adapter remains up, even though the client is a NAT client.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by Erez Benari Tuesday, June 29, 2010 8:18 PM
    Monday, June 21, 2010 3:25 PM
    Moderator

All replies

  • Hi Mr.S,

    I dont see the same behaviour and I am also using HTTP tests.

    I have seen DCA get confused (show a cross when DA is actually ok) when moving between corpnet and the Internet; this is solved by restarting the DCA service and then running a new instance of DCAtray.exe

    Ideas:

    Are you using FQDNs?

    Do you have any proxy configuration that may impact a HTTP request?

    Can you netmon and see DCA trying to connect, then look at responses from the web server?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Erez Benari Friday, May 28, 2010 6:10 PM
    • Unmarked as answer by MrShannon Friday, May 28, 2010 9:38 PM
    Friday, May 28, 2010 10:53 AM
    Moderator
  • I am testing against http://dca.domain.com/ where "domain.com" is the corporate dns domain and "dca" is an A record for a secondary ip address (10.54.0.88) that I have attached to my certificate server's nic and bound an IIS site on that host.

    There are are no HTTP proxies that IE would use.  There is a filter that is applied on the outbound web browsing but it should not be affecting anything for the corporate domain.

    When connected via LAN to the corpnet I was able to use NetMon to see the HTTP request and response to/from the IP address for DCA.domain.com.  When I disconnect from the LAN and connect via WLAN to the internet, DirectAccess kicks in and everything in NetMon shows IPv6.  Doing an NSLOOKUP for DCA gives me the IPv6 address but all I see for that address in NetMon are ICMPv6:Echo requests and replies.

    Looking at the IIS log, I can see when I try to load the DCA site in IE and the requests from the DCA client too.  What's interesting is the IIS log seems to indicate that the IP address that made the http request is it's own IP and not the IP of the actual client.

    Here's some log excerpts from IIS on the DCA site.  The first one you can see me loading the DCA site from IE and then the request automatically generated by the DCA Client.  it shows my LAN IP of 128.1.70.75 making the requests.

      Over LAN
      2010-05-28 20:39:53 10.54.0.88 GET /favicon.ico - 80 - 128.1.70.75 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.1;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+InfoPath.3;+MS-RTC+LM+8) 404 0 64 0
      2010-05-28 20:39:54 10.54.0.88 GET / - 80 - 128.1.70.75 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+InfoPath.3;+MS-RTC+LM+8) 304 0 0 218
      2010-05-28 20:40:25 10.54.0.88 GET / - 80 - 128.1.70.75 Client+DCA 200 0 0 218

    This time I am connected via DirectAccess.  I can still get to the dca site, but this time it's logging the requesting IP as 10.54.0.85, which is the IP address of the dca site itself.

      Over DirectAccess
      2010-05-28 21:20:12 10.54.0.88 GET / - 80 - 10.54.0.85 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+6.1;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+InfoPath.3;+MS-RTC+LM+8) 304 0 0 203
      2010-05-28 21:20:21 10.54.0.88 GET / - 80 - 10.54.0.85 Client+DCA 200 0 0 203

    Like I said earlier, after a few minutes the DCA does recognize that it can load the HTTP site and shows a good status, but I am not sure why it indicates it can resolve the site as opposed to actually loading the html file.


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Friday, May 28, 2010 9:37 PM
  • Hi MrS,

    Are these machines configured as management servers, so that they're accessible via the first tunnel?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, June 1, 2010 3:14 PM
    Moderator
  • No, dca.domain.com was not in my management server list, I just now added it, but it did not seem to help.

    I have also been using dca.domain.com as the target of my PING test, and that passes just fine.


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Tuesday, June 1, 2010 4:27 PM
  • Hi MrS,

    Interesting. Is dca.domain.com using ISATAP addressing?

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, June 2, 2010 2:22 PM
    Moderator
  • Well, remember my "dca" host is just a second IP address bound to a NIC in my certificate server.  Yes, both nic's have the same gateway defined, but should they?  The NIC configuration in my certificate server looks like this:

    Host NIC
    IP: 10.54.0.83 (certsrvr.domain.com)
    SN: 255.255.255.0
    GW: 10.54.0.1
    Register w/DNS? YES
    DNS1: 10.54.0.101
    DNS2: 10.54.0.102
    IPv6 Enabled? YES
    IIS Sites NIC
    IP1: 10.54.0.86 (nls.domain.com)
    IP2: 10.54.0.87 (crl.domain.com)
    IP3: 10.54.0.88 (dca.domain.com)
    SN: 255.255.255.0
    GW: 10.54.0.1
    Register w/DNS? NO
    DNS1: (none)
    DNS2: (none)
    IPv6 Enabled? YES

    Do you think that might have something to do with it?  I have noticed that machines that use DirectAccess over IPHTTPS using something other than an AirCard (I tested with a Sprint EVDO device) seem to be performing the resources tests faster, which is kind of unexpected.


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Wednesday, June 2, 2010 6:38 PM
  • I'm curious where .85 is coming from?

    It was in the log files, but I don't see it in the server config above.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, June 3, 2010 1:57 PM
    Moderator
  • .85 is the IP of the UAG server's internal interface.
    MrShannon | TechNuggets Blog | Concurrency Blogs
    Friday, June 4, 2010 4:17 PM
  • I just discovered that I cannot ping the second external IP of my UAG server.  I remember manually creating a TMG rule to allow pings from "external" and "internal" to "localhost", but apparently "external" does not consider that secon IP.  Should I really be needing to make this rule manually?
    MrShannon | TechNuggets Blog | Concurrency Blogs
    Monday, June 7, 2010 8:18 PM
  • I've corrected the external firewall (in front of UAG) to allow ping and UDP 3544 and now Teredo is working.  I didn't know it before but only 6TO4 and IPHTTPS worked before.  This guide was particularly helpful.

    http://technet.microsoft.com/en-us/library/ee844188(WS.10).aspx

    I still get the occasional "Resolved Name" message in the Advanced Troubleshooting of DCA, however the tests seem to be passing more than not.  I'll need to spend some more time on this one before considering it resolved.


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Wednesday, June 9, 2010 2:37 PM
  • Tut, tut...imagine not configuring your edge firewall to support teredo properly ;)

    You should notice a performance improvement too as teredo should be quicker that IP-HTTPS...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, June 9, 2010 3:31 PM
    Moderator
  • OMG yes.  Teredo is so much faster.  I want to do a real speed test to compare the connections.  Any idea how to temporarily disable Teredo from the client side, maybe using an NetSh command to set the interface offline?
    MrShannon | TechNuggets Blog | Concurrency Blogs
    Wednesday, June 9, 2010 4:04 PM
  • netsh interface teredo set state disable

    and then

    netsh interface teredo set state client

    or

    netsh interface teredo set state enterpriseclient

    to enable again...


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    • Marked as answer by Erez Benari Tuesday, June 29, 2010 8:18 PM
    Wednesday, June 9, 2010 9:50 PM
    Moderator
  • Also, if you're using a device in front of the DA client that is capable of being a 6to4 router, check to see that that feature is disabled, otherwise you might see that the 6to4 adapter remains up, even though the client is a NAT client.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    • Marked as answer by Erez Benari Tuesday, June 29, 2010 8:18 PM
    Monday, June 21, 2010 3:25 PM
    Moderator
  • Now that I have a better understanding of things I have written a walk-through guide on how to configure UAG DirectAccess.

    http://blog.concurrency.com/infrastructure/uag-directaccess-configuration-walkthrough/

    Tom, Jason, I would really love to get your feedback on how I am doing.  It's a 14 post series that I have the first 12 done and ready to post.  The first two are up now and the others will soon follow.


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Saturday, July 24, 2010 2:54 AM
  • Happy to have a look...my next article is still in the making ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Saturday, July 24, 2010 9:41 PM
    Moderator
  • Now that I have a better understanding of things I have written a walk-through guide on how to configure UAG DirectAccess.

    http://blog.concurrency.com/infrastructure/uag-directaccess-configuration-walkthrough/

    Tom, Jason, I would really love to get your feedback on how I am doing.  It's a 14 post series that I have the first 12 done and ready to post.  The first two are up now and the others will soon follow.


    MrShannon | TechNuggets Blog | Concurrency Blogs


    Hi Shannon,

    Check out the site and looks good!

    A couple of things to be aware of though -

    • UAG DirectAccess doesn't require any specific domain functional level
    • UAG DirectAccess doens't require Windows Server 2008+ DNS servers
    • If you want to have "prettier" names for your ISATAP interfaces, add a connection specific DNS suffix to the internal NIC

    Other than that - looking really good!

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, July 26, 2010 12:38 PM
    Moderator
  • Thank you Tom!

    I have updated both posts and added two more:

     

    Unified Access Gateway Installation

    Firewall and DNS Considerations

     

    Tom, I used one of your posts as a reference the the Firewall setup, so thank you again for that.


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Tuesday, July 27, 2010 4:20 PM
  • Hi Shannon,

    I'll check  out those entries and let you know.

    RE: the firewall setup - you bet! Feel free to borrow and improve!

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 29, 2010 12:44 AM
    Moderator