{"id":1166,"date":"2014-04-27T22:25:38","date_gmt":"2014-04-27T18:25:38","guid":{"rendered":"http:\/\/prgmr.io\/?p=1166"},"modified":"2014-04-27T22:25:38","modified_gmt":"2014-04-27T18:25:38","slug":"notes-on-teredo-part-3","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/windows\/notes-on-teredo-part-3\/","title":{"rendered":"Notes on Teredo (part 3)"},"content":{"rendered":"

In the previous two parts I talked about Teredo in general<\/a> and also about NAT &\u00a0 Teredo<\/a>. In this post I hope to talk more about how Teredo works.<\/p>\n

Teredo Clients<\/h2>\n

Microsoft has made available Teredo servers on the Internet. These are reachable at win8.ipv6.microsoft.com<\/code> and teredo.ipv6.microsoft.com<\/code> and Windows clients have this address already set as their Teredo server. <\/p>\n

If the Teredo server address is not reachable, the client is in an offline state:<\/p>\n

C:\\>netsh interface teredo show state\nTeredo Parameters\n---------------------------------------------\nType                    : client\nServer Name             : teredo.ipv6.microsoft.com.\nClient Refresh Interval : 30 seconds\nClient Port             : unspecified\nState                   : offline\nError                   : failed to resolve server name<\/pre>\n
If the Teredo server address is reachable, the client is in a dormant state. As the name indicates this is a state in which the Teredo client is not active, but when required it can contact the server and auto-configure an IPv6 address and send\/ receive packets. <\/p>\n
C:\\>netsh interface teredo show state\nTeredo Parameters\n---------------------------------------------\nType                    : client\nServer Name             : teredo.ipv6.microsoft.com.\nClient Refresh Interval : 30 seconds\nClient Port             : unspecified\nState                   : dormant<\/pre>\n
Send some IPv6 traffic and the state automatically changes to qualified. (Note how the first ping reply took a lot more time than the rest as the Teredo interface was being configured. Sometimes the first reply can timeout too). <\/p>\n
C:\\>ping -6 gw01.rakhesh.com\n\nPinging gw01.rakhesh.com [2dcc:7c4e:3651:52::254] with 32 bytes of data:\nReply from 2dcc:7c4e:3651:52::254: time=2146ms\nReply from 2dcc:7c4e:3651:52::254: time=1ms\nReply from 2dcc:7c4e:3651:52::254: time=3ms\nReply from 2dcc:7c4e:3651:52::254: time=2ms\n\nPing statistics for 2dcc:7c4e:3651:52::254:\n    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),\nApproximate round trip times in milli-seconds:\n    Minimum = 1ms, Maximum = 2146ms, Average = 538ms\n\nC:\\>netsh interface teredo show state\nTeredo Parameters\n---------------------------------------------\nType                    : client\nServer Name             : teredo.ipv6.microsoft.com.\nClient Refresh Interval : 30 seconds\nClient Port             : unspecified\nState                   : qualified\nClient Type             : teredo client\nNetwork                 : unmanaged\nNAT                     : restricted\nNAT Special Behaviour   : UPNP: No, PortPreserving: Yes\nLocal Mapping           : 192.168.20.200:52643\nExternal NAT Mapping    : 17.23.51.201:52643<\/pre>\n
Now the Teredo state also shows the type of NAT the client is behind and also the local and external mappings. <\/p>\n
Another thing to note in the output above is the “Network” which is currently set to “unmanaged”. Since Teredo allows a client to be reached across a firewall\/ NAT and this is something an organisation might not want for its managed machines, the Teredo client tries to accommodate that and before initializing itself it checks whether the computer is on a managed network. If the computer is domain joined and on a network where it’s domain controllers are reachable – i.e. within an organisation – the Teredo client detects that it’s on a managed network and disables itself. <\/p>\n
C:\\>netsh interface teredo show state\nTeredo Parameters\n---------------------------------------------\nType                    : client\nServer Name             : win8.ipv6.microsoft.com.\nClient Refresh Interval : 30 seconds\nClient Port             : unspecified\nState                   : offline\nError                   : client is in a managed network<\/pre>\n
This setting can be changed to set the Teredo client as qualified even in a managed network. This can be done via GPOs, PowerShell, or netsh<\/code>. The netsh<\/code> command for this is: <\/p>\n
C:\\>netsh interface teredo set state enterpriseclient<\/pre>\n
This command must be run as an administrator. When a Teredo client is in a managed network and qualified, it is known as an Enterprise Client. Hence the name.  <\/p>\n
It is also possible to configure clients with a manually specified Teredo server. This can be done via PowerShell …<\/p>\n
PS> Set-NetTeredoConfiguration -ServerName 17.23.52.250<\/pre>\n
… or netsh<\/code> …<\/p>\n
C:\\>netsh interface teredo set state servername=17.23.52.250<\/pre>\n
Teredo Servers<\/h2>\n
Setting up your own Windows Teredo Server is easy. Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012, and later can function as a Teredo server. <\/p>\n
Here’s how I enable one of these as a Teredo server: <\/p>\n
PS> Set-NetTeredoConfiguration -Type Server<\/pre>\n
And that’s it really! The computer is now working as a Teredo server. <\/p>\n
C:\\>netsh interface teredo show state\nTeredo Parameters\n---------------------------------------------\nType                    : server\nVirtual Server Ip       : 0.0.0.0\nClient Refresh Interval : 30 seconds\nState                   : online\n\nServer Packets Received : 0\nSuccess                 : 0 (Bubble 0, Echo 0, RS1 0 RS2 0)\nFailure                 : 0 (Hdr 0, Src 0, Dest 0, Auth 0)\n\nRelay Packets Received  : 0\nSuccess                 : 0 (Bubble 0, Data 0)\nFailure                 : 0 (Hdr 0, Src 0, Dest 0)\n\nRelay Packets Sent      : 9\nSuccess                 : 0 (Bubble 0, Data 0)\nFailure                 : 9 (Hdr 0, Src 9, Dest 0)\n\nPackets Received in the last 30 seconds:\nBubble 0, Echo 0, RS1 0, RS2 0\n6to4 source address 0, native IPv6 source address 0\n6to4 destination address 0, native IPv6 destination address 0\n\n\nEstimated Bandwidth consumed in the last 30 seconds (in BPS):\nBubble 0, Echo 0, Primary 0, Secondary 0\n6to4 source address 0, native IPv6 source address 0\n6to4 destination address 0, native IPv6 destination address 0\n<\/pre>\n
Running the above command again shows updated stats. <\/p>\n
One thing to keep in mind that even a computer functioning as a Teredo server must be setup with a Teredo server. If the pre-configured Teredo server (e.g. win8.ipv6.microsoft.com<\/code>) is unreachable, the Teredo interlace will be disabled and the computer will not work as a Teredo server. The Teredo state will show as offline even though this computer itself is a server. <\/p>\n
C:\\> netsh interface teredo show state\nTeredo Parameters\n---------------------------------------------\nType                    : server\nVirtual Server Ip       : 0.0.0.0\nClient Refresh Interval : 30 seconds\nState                   : offline\nError                   : general system failure\nError Code              : 11002\n<\/pre>\n
To fix this, set this computer as its own Teredo server. <\/p>\n
C:\\>netsh interface teredo set state servername=17.23.52.250<\/pre>\n
Teredo Relays<\/h3>\n
Previously<\/a> I wrote about how a Teredo relay sends packets to a Teredo client. How do clients know which Teredo relay to use though? So far we haven’t set a Teredo relay anywhere in our client and server configuration, so where does it enter the picture?<\/p>\n
While Teredo servers are specific to a client – i.e. the client is assigned a Teredo server and each client uses only one Teredo server – Teredo relays are specific to the remote end and a particular client will use different relays for different destinations. Here’s how the process works:<\/p>\n
    \n
  1. When a Teredo client needs to contact a remote IPv6 host, it first sends an ICMPv6 packet to the remote host. <\/li>\n
  2. Since it doesn’t know how to contact this host, and this is an initial setup connection, the client sends this packet to the Teredo server as an UDP message in IPv4. <\/li>\n
  3. The Teredo server receives this message, decapsulates the IPv6 packet, and sends it on the IPv6 network. Note: this IPv6 packet has the destination address set as the IPv6 address of the remote host, and source address set as the Teredo IPv6 address of the Teredo client. <\/li>\n
  4. Now for the fun part! The IPv6 packet reaches the destination host, the host creates a reply IPv6 packet with itself as the source and the Teredo client IPv6 address as the destination. This packet is sent on the IPv6 network. On the IPv6 network are many Teredo relays, all of them advertising the 2001:0:\/32<\/code> prefix. The packet will reach the relay nearest to the destination host<\/em> who will then send it to the Teredo client<\/a>. Once the Teredo client receives the ICMPv6 reply, it knows which relay was used and thus knows the IPv4 address of the relay closest to the destination. <\/li>\n
  5. The Teredo client then sends the actual IPv6 packet as a UDP message in an IPv4 packet to this Teredo relay. And since a hole punching is done for this relay address, further packets to and from this relay can travel through. <\/li>\n<\/ol>\n
    Similarly when an IPv6 host has a packet for a Teredo client, the packet makes its way to the relay closest to that host. The relay then checks whether it already has a communication set up with the client, in which case it sends the packet over via IPv4. If there’s no on-going communication, or it’s been a while, the relay goes through the hole punching process again<\/a> and sends the packet. <\/p>\n
    Similar to the Teredo server, Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012, and later can function as a Teredo relay. Setting up one of these as a Teredo relay is quite straight-forward. All one has to do is:<\/p>\n
      \n
    1. Ensure the Teredo interface is ready – i.e. the relay can reach a Teredo server and the interface is not offline.<\/li>\n
    2. Enable forwarding on the Teredo interface. Enable forwarding on the interface(s) to the IPv6 network. <\/li>\n
    3. Publish a route for the 2001::.32<\/code> prefix.<\/li>\n
    4. Enable IPv6 router advertisements on the IPv6 network so other routers pick up the published route.<\/li>\n<\/ol>\n
      And that’s it! Here are the commands: <\/p>\n
      C:\\>netsh interface teredo set state servername=17.23.52.250\nOk.\n\nC:\\>netsh interface ipv6 set interface INET-52.23.1 forwarding=enabled\nOk.\n\nC:\\>netsh interface ipv6 set interface \"Teredo Tunneling Pseudo-Interface\" forwarding=enabled\nOk.\n\nnetsh interface ipv6 set route 2001::\/32 \"Teredo Tunneling Pseudo-Interface\" publish=yes\nOk.\n\nnetsh interface ipv6 set interface INET-52.23.1 advertise=enabled\nOk.<\/pre>\n
      That’s all for now!<\/p>\n","protected":false},"excerpt":{"rendered":"
      In the previous two parts I talked about Teredo in general and also about NAT &\u00a0 Teredo. In this post I hope to talk more about how Teredo works. Teredo Clients Microsoft has made available Teredo servers on the Internet. These are reachable at win8.ipv6.microsoft.com and teredo.ipv6.microsoft.com and Windows clients have this address already set … Continue reading Notes on Teredo (part 3)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[196,85],"tags":[197,203],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/1166"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=1166"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/1166\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=1166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=1166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=1166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}