locked
Why are DirectAccess clients always preferring the iphttpsinterface instead of teredo? RRS feed

  • Question

  • The DirectAccess documents seem to state that IP/HTTPS is a last resort protocol when Teredo, 6to4 and native IPv6 are unavailable. 

    Yet consistently I see the bulk of traffic occurring over the iphttpsinterface, here is an example:

    C:\Windows\system32>netsh int ipv6 show sub

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
    ------  ---------------  ---------  ---------  -------------
    4294967295                1          0     191182  Loopback Pseudo-Interface 1
      1500                5          0       1492  Wireless Network Connection
      1280                5          0       1728  isatap.{4AC9C67D-64C1-4962-9150-E3DE51A9C324}
      1280                1      52633      78935  Teredo Tunneling Pseudo-Interface
      1500                1       2394     232636  Local Area Connection
      1280                2          0       1152  isatap.{B99B7395-82DC-43D7-B58A-4FC393FA33DE}
      1280                1    2515683    1321092  iphttpsinterface
    Friday, February 5, 2010 1:53 AM

All replies

  • Hi,

    Marby because you laptops are on private IP ranges (connected behind NAT) and because UDP3544 is reachable on your DirectAccess Server.

    You can try to force Teredo by disabling IP-HTTPS with a NETDH command.

    BenoîtS
    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Friday, February 5, 2010 1:33 PM
  • Shouldn't Teredo be preferred over IPHTTPS though? I want Teredo to be used if it will give the clients better performance.

    It just seems to be the case that the clients are not using it.
    Friday, February 5, 2010 1:46 PM
  • So check if you can reach your DirectAccess Server on UDP 3544. If not, you client can't use it.

    If you can reach it but sill can't use it, this may be because the ISP you are using on the client side does not support Teredo.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Friday, February 5, 2010 3:54 PM
  • Is there some method of diagnosing this from the client? The Teredo connection comes up, says it's qualified, there's some traffic, and then no more. IPHTTPS seems to be the connection with the bulk of the traffic (copying files, remote desktop, etc.) My impression is that Teredo should come up, authenticate, and DirectAccess would then prevent the IPHTTPS interface from coming up if the Teredo one works. Is this correct? As it is, all my clients are setting up both Teredo and IPHTTPS, and then the latter gets the preferred route and ends up being used.
    Friday, February 5, 2010 4:31 PM
  • Hi Aaron,

    There is a thread on why this might happen, but I'll have to find that and come back and post it.

    In the meantime, you can use the netsh interface httpstunnel set state=disabled

    HTH,
    Tom
    MS ISDUA Anywhere Access Team
    Friday, February 5, 2010 4:48 PM
  • How do you perform this check?  In other words which tool?

    Don Murphy
    Monday, February 8, 2010 7:48 PM
  • If the question was directed to me, I merely monitored network usage manually using:

    netsh int ipv6 show sub

    Teredo traffic was negligible, IP-HTTPS traffic was roughly equal to the size of file transfers I had started.

    I think it may be because, for reliability and compartmentalizing roles, we switched to a router advertisement based IPv6 network. This necessitated adding routes to servers to get back out, but I think routing does not work for Teredo back out. I will update this sometime this week with my findings.

    Nevertheless, there is some traffic going through Teredo, just not very much.
    Monday, February 8, 2010 8:49 PM
  • BenoitS - How can you check if you can reach your DirectAccess Server on UDP 3544.   (Trying not to hijack thread ;)

    Thanks,

    Don Murphy
    Monday, February 8, 2010 9:39 PM
  • The problem appears to be that the DirectAccess server cannot reach clients over Teredo at all.

    From the DA server, I cannot ping the ipv6 address that a client is given over teredo.
    Wednesday, February 10, 2010 1:09 AM
  • Try disabling the firewall on the client and rerun a ping.  Does that work?
    Wednesday, February 10, 2010 4:57 AM
  • Hi,

    For this kind of check, i would use PortQry.exe witch was included in the Windows XP/2003 support tool. That's my first idea. But if your client is using IP-HTTPS, that is because others protocols can't be used.
    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Wednesday, February 10, 2010 7:41 PM
  • Why is it that the DirectAccess server would not be able to ping the client's 2001: IP address, the one on the Teredo interface?
    Thursday, February 11, 2010 3:41 PM
  • Hi

    Depend

    First check if you have enabled ICMPV6 echo request on your workstation and secondly check if you have activated Edge Transversal in the inbound ICMP request. It is specific to the Teredo protocol.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Thursday, February 11, 2010 4:37 PM
  • I modified our existing ICMPv4/v6 rules to both allow edge traversal.

    When pinging from client to internal address, I get "Request timed out."
    When pinging from DirectAccess server to client, I get "Destination net unreachable."
    Friday, February 12, 2010 5:28 AM
  • Hi Aaron

    Getting back to your original question is this happening because of the "Teredo enterprise mode" where by default if a Direct Access clients detects a domain controller onn your network it will not use Teredo?  There is a group policy setting that allows you to turn this behaviour off effectively.

    Don Murphy

    The DirectAccess documents seem to state that IP/HTTPS is a last resort protocol when Teredo, 6to4 and native IPv6 are unavailable. 

    Yet consistently I see the bulk of traffic occurring over the iphttpsinterface, here is an example:

    C:\Windows\system32>netsh int ipv6 show sub

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
    ------  ---------------  ---------  ---------  -------------
    4294967295                1          0     191182  Loopback Pseudo-Interface 1
      1500                5          0       1492  Wireless Network Connection
      1280                5          0       1728  isatap.{4AC9C67D-64C1-4962-9150-E3DE51A9C324}
      1280                1      52633      78935  Teredo Tunneling Pseudo-Interface
      1500                1       2394     232636  Local Area Connection
      1280                2          0       1152  isatap.{B99B7395-82DC-43D7-B58A-4FC393FA33DE}
      1280                1    2515683    1321092  iphttpsinterface

     

    Monday, February 15, 2010 4:35 AM
  • I’m having a similar issue.

    2 scenarios (2 laptops) one where all is fine, it always uses the teredo tunnel and the second laptop always falls back on the HTTPSTunnel.  Both laptops are connected to the internet via the same accespoint behind NAT.

    The first laptop is configured inside the corporate LAN, it is installed with Windows 7 enterprise, joined to the domain, the computer account is added to the directaccess AD security group and after all AD policies are synchronized to the laptop it is disconnected from the lan and connects to the internet accesspoint and automatically enables its Teredo tunnel and is able to ping servers over the directaccess teredo tunnel.

    The second laptop is also installed with windows 7 enterprise, but is never connected to the corporate lan.  Via this procedure the laptop is added to the domain and configured for DirectAccess

    http://social.technet.microsoft.com/Forums/en/windowsserver2008r2networking/thread/af6b5602-bab1-4765-b161-5283f40457f1

    So everything on the second laptop is configured with a few scripts. For the tunnels I used these commands

    netsh interface ipv6 set teredo client A.B.C.D (IP of DirectAccess server)

     

    netsh interface 6to4 set relay A.B.C.D (IP of DirectAccess server)

     

    netsh interface httpstunnel add interface client "https://urlofDAserver.com/IPHTTPS" default

     

    after all the steps as described by me in the other thread the second laptop is able to connect to the corporate network via DirectAccess but is always falls back to the HTTPSTunnel. This is not preferred by us because it has higher latency.

     

     

    A Route Print shows a route for ::/0 but it is connected to the interface IPHTTPSTunnel and the gateway is a ipv6 address instead of On-Link

     

    netsh interface teredo show state

    Teredo Parameters

    ---------------------------------------------

    Type                    : client

    Server Name             : 212.17x.xxx.xxx (Group Policy)

    Client Refresh Interval : 30 seconds

    Client Port             : unspecified

    State                   : qualified

    Client Type             : teredo host-specific relay

    Network                 : unmanaged

    NAT                     : restricted

    NAT Special Behaviour   : UPNP: No, PortPreserving: Yes

    Local Mapping           : 192.168.1.101:54017

    External NAT Mapping    : 212.83.xxx.xxx:54017

     

    I tried disabling the iphttpsinterface with: netsh interface httpstunnel set interface iphttpsinterface state=disabled

    To test if teredo by it self would work but the httpstunnel is always re-enabled by itself after I disconnected and connect the wireless connection.

    Ipconfig shows

    Wireless LAN adapter Wireless Network Connection:

     

       Connection-specific DNS Suffix  . :

       Link-local IPv6 Address . . . . . : fe80::442b:bf44:ef0e:6de9%12

       IPv4 Address. . . . . . . . . . . : 192.168.1.101

       Subnet Mask . . . . . . . . . . . : 255.255.255.0

       Default Gateway . . . . . . . . . : 192.168.1.1

     

    Ethernet adapter Local Area Connection:

     

       Media State . . . . . . . . . . . : Media disconnected

       Connection-specific DNS Suffix  . : domain.nl

     

    Tunnel adapter IPHTTPSInterface:

     

       Connection-specific DNS Suffix  . :

       IPv6 Address. . . . . . . . . . . : 2002:d4b2:5cc2:8100:5064:1e7b:bf1:9500

       Temporary IPv6 Address. . . . . . : 2002:d4b2:5cc2:8100:7406:ad9d:6a48:a660

       Link-local IPv6 Address . . . . . : fe80::5064:1e7b:bf1:9500%14

       Default Gateway . . . . . . . . . : fe80::49e1:d44:5c3e:a710%14

     

    Tunnel adapter Teredo Tunneling Pseudo-Interface:

     

       Connection-specific DNS Suffix  . :

       IPv6 Address. . . . . . . . . . . : 2001:0:d4b2:5cc2:1828:2cfe:2bac:245c

       Link-local IPv6 Address . . . . . : fe80::1828:2cfe:2bac:245c%13

       Default Gateway . . . . . . . . . :

     

    Tunnel adapter isatap.{BC2D1DD3-7FB6-40A6-A9BD-7E38B55B4053}:

     

       Media State . . . . . . . . . . . : Media disconnected

       Connection-specific DNS Suffix  . :

     

     

    netsh int ipv6 show sub

     

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface

    ------  ---------------  ---------  ---------  -------------

    4294967295                1          0      86624  Loopback Pseudo-Interface 1

      1500                1          0      21337  Wireless Network Connection

      1280                1     429067     162340  IPHTTPSInterface

      1280                1      11839       4336  Teredo Tunneling Pseudo-Interface

     

      1500                5          0        152  Local Area Connection

      1280                5          0          0  isatap.{BC2D1DD3-7FB6-40A6-A9BD-7

     

     

    My guess is that the Teredo tunnel is not working correctly and therefore the httpstunnel is used, but I have no idea what should be wrong with the teredo tunnel on the client or how to troubleshoot this any further.

     

    I hope someone over here has any clue on what may be the cause, any help is appreciated

    Friday, February 19, 2010 7:57 PM
  • Ditto, I'm still having no luck but all of our clients were configured via group policy on the internal network before testing directaccess.

    Mister Iks, could you post the ipconfig /all on your laptop that has Teredo working correctly? Also your netsh int teredo show state?
    Saturday, February 20, 2010 9:00 PM
  • Hi all,

    i had an similar issue with my DA clients. I guess it's a routing problem. unchecking the ipv6 checkbox on the wlan card solved the issue for me.

    there was a ipv6 route that prevented my clients from adding the ::/0 route on the teredo interface.

    Sunday, June 27, 2010 10:13 AM
  • Similar bizarre DA issue here.  The DA client laptop was on the LAN, connected via the Ethernet card, with a local IPv4 address.  I had the WLAN card disabled.  Yet the IPHTTPSInterface was active.  When connecting Outlook 2010 to Exchange 2010, it was prompting for basic authentication like the client was outside on the WAN; I was trying to sync the 500MB OST and it was taking forever, which is how I noticed something was fishy.

    I fixed it by enabling the WLAN card; I had it disabled because I wanted it to use the gibabit NIC to download the OST, and sometimes Windows 7 uses the wireless even when there is a wired connection available.  Anyway, as soon as I enabled the WLAN card, the client got an ISATAP address automatically, and the OST downloaded fast as expeced, and Outlook 2010 recognized it was on the LAN again.

    Also, later I noticed that when I rebooted the latptop with both the WLAN and NIC enabled, the same problem occured - IPHTTPSInterface was enabled and active.  This time, I just disabled the WLAN, and re-enabled it (toggled the switch).  Then it had ISATAP connectivity.

    Tuesday, June 29, 2010 6:04 PM