none
DA Corporate Connectivity Checking, delays RRS feed

  • Question

  • Hi all,

    I'm seeing exactly what Dr. Shinder described in this write-up: http://blogs.technet.com/b/tomshinder/archive/2010/08/24/why-are-both-the-teredo-and-ip-https-interfaces-active.aspx.  So basically, I'm seeing connectivity over Teredo for my infrastructure tunnel, and connectivity over IP-HTTPS for my intranet tunnel.  So this would indicate some delay in the detection of the corporate network.  Obviously, I'd rather see both tunnels use Teredo and it seems that after some long time connected, it shifts to this (maybe this is due to the passive checking detailed here (http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx), I don't know.  I do know that I have a fast internet connection where I'm testing, though, so I'm pretty surprised to have a delay issue.

    My questions related to this are:

    1. What factors could contribute to such a delay (again, internet connection is fast) and can the default delay time before enabling IP-HTTPS be altered?
    2. I assume the corporate connectivity check factors are logical ANDs checked at essentially the same time?  Meaning Connectivity_State = (FQDN Resolved) && (NLS connectivity on HTTPS)
    3. Does Kerberos authentication for the user at the time of the formation of the intranet tunnel in any way influence the delay time as assessed for that tunnel?  Otherwise, why is it choosing to use IP-HTTPS for that one vs. Teredo for infrastructure in these cases?

    Thanks in advance,

    Ross



    Thursday, May 12, 2011 3:47 PM

All replies

  • Hey Ross, I don't believe what Tom is saying is that when this happens the infrastructure tunnel goes over Teredo but the intranet tunnel goes over IP-HTTPS, what I believe happens is that when Teredo and IP-HTTPS both activate themselves successfully, IP-HTTPS is the mechanism that takes over transporting the traffic, so Teredo basically goes unused. That doesn't make much difference to your situation, but I wanted to clear that up.

    I would first focus on making sure that Teredo is actually connecting successfully and can transmit traffic successfully. Have you had any successful connections using only Teredo? Make sure you show as "qualified" in a netsh interface teredo show state

    As far as eliminating delays, I guess make sure you test from multiple internet connections to see if the behavior happens all the time or only from some connections. Also, I know you've been around here for a while so you have probably already seen this, but make sure your NIC configurations are running best practice. Jason Jones has the best article out on that:

    http://social.technet.microsoft.com/wiki/contents/articles/recommended-network-adapter-configuration-for-forefront-uag-servers.aspx

    Thursday, May 12, 2011 6:34 PM
  • Interesting, reading it again, you're probably right and he meant all traffic by "intranet" where I was taking it as meaning just traffic for the intranet tunnel and not the infrastructure tunnel.  And yeah, my NICs are set up that way and Teredo showed as qualified.

    What I was seeing yesterday was that both transition interfaces seemed to be enabled.  A network capture revealed that all traffic seemed to be going over HTTPS for the brief time slices where I watched it.  So I went on the DA monitoring website and it showed that my infrastructure tunnel was using Teredo and my intranet tunnel was using IP-HTTPS.  This happened two or three times yesterday evening.

    Looking back, the only thing I can think of that happened anywhere near this time was I had moved my client's teredo type to enterprise client a  while before this due to it seeing the net it was on as a managed network.  There were reboots and some time between that and the issue, but it's the only thing that happened anywhere near that time of any interest.

    So here's the weird thing: now I can't reproduce the problem.  Everything is constantly using Teredo today.  So problem solved I hope :)



    Thursday, May 12, 2011 11:16 PM