Confused about Teredo addresses
anon...@discussions.microsoft.com
Teredo (after disabling it and rebooting) I ran netstat -
a, and recorded the UDP ports. I then enabled Teredo,
setting the client port to 34567. I ran netstat -a again
and recorded the ports. The new ports were 1086, 3544,
33196, and 34567. Port 3544 is the Teredo listening
port. Port 34567 is the client port that I assigned. I
don't know what ports 1086 and 33196 are, but that is not
my immediate problem.
I assumed that 34567 was a local port on my side of the
NAT and that it was mapped to an external port number,
different from 34567. This external port number would be
obscured, I thought, and incorporated into my Teredo
address. However, the obscured port number incorporated
into the Teredo address is 34567. This does not seem
correct to me. I am obviously missing something. I would
appreciate some aid.
Remi Denis-Courmont
> My Windows XP machine is behind a NAT. Before enabling
> Teredo (after disabling it and rebooting) I ran netstat -
> a, and recorded the UDP ports. I then enabled Teredo,
> setting the client port to 34567. I ran netstat -a again
> and recorded the ports. The new ports were 1086, 3544,
> 33196, and 34567. Port 3544 is the Teredo listening
> port. Port 34567 is the client port that I assigned.
Port 3544 is used by the Teredo tunnel for potential communications between
multiples Teredo clients on the same LAN and behind the same NAT device,
which is probably why it is still open.
> I assumed that 34567 was a local port on my side of the
> NAT and that it was mapped to an external port number,
> different from 34567. This external port number would be
> obscured, I thought, and incorporated into my Teredo
> address. However, the obscured port number incorporated
> into the Teredo address is 34567. This does not seem
> correct to me. I am obviously missing something. I would
> appreciate some aid.
It is not unlikely that your NAT tried to keep external and internal port
numbers as far as possible, so that the embedded obscured port number ended
being the same as your internal client port.
--
Rémi Denis-Courmont
http://www.simphalempin.com/home/
anon...@discussions.microsoft.com
>>>which when unobscured is 34567. That is, the internal
>>>port number is being obscured and used in the Teredo
>>>address. That seems like a bug to me.>.
>
anon...@discussions.microsoft.com
Windows XP machines behind the NAT. I enabled Teredo on
the second machine with the client port also set to 34567.
1.When I do "show neighbors" in netsh, neither machine
shows the other. Each only shows itself.
2.In both cases the physical address shown is
80.11.117.176:34567 80.11.117.176 is the correct
external IP address. 34567 is the internal client port
number.
3.Both Teredo address have the same obscured port number,
that is, 78f8 which is the obscured version of 34567. And
each has the obscured version of 80.11.117.176 The
Teredo addresses differ only in the IP address of the
Teredo server.
It appears that the Microsoft Teredo is not working
correctly. I obviously need enlightenment. Help.
>.
>
Remi Denis-Courmont
> There is really something strange going on. I have two
> Windows XP machines behind the NAT. I enabled Teredo on
> the second machine with the client port also set to 34567.
> 1.When I do "show neighbors" in netsh, neither machine
> shows the other. Each only shows itself.
This is based on IPv4 multicast. I've never checked if it worked though. You
might try ethereal to find out if your switch is correctly transmitting
local Teredo discovery packets.
> 2.In both cases the physical address shown is
> 80.11.117.176:34567 80.11.117.176 is the correct
> external IP address. 34567 is the internal client port
> number.
I'd suggest using Ethereal there too. You'll probably notice that in both
case the server believe your client are using 80.11.117.176:34567 as an
external address.
> 3.Both Teredo address have the same obscured port number,
> that is, 78f8 which is the obscured version of 34567.
I believe this is your NAT device that tries to keep external-internal ports
mapping identical.
> And each has the obscured version of 80.11.117.176
It should be so.
> The Teredo addresses differ only in the IP address of the
> Teredo server.
That is why it is possible to have both clients on the same external port
number: your NAT is probably "restricted". Try to enforce a particular
Teredo server IP, for example 64.4.25.80 on both clients, and see what
happens (set teredo client 64.4.25.80).
By the way, why do you insist on your client using the same internal
statically specified port number?
> It appears that the Microsoft Teredo is not working
> correctly. I obviously need enlightenment. Help.
It used to work fine for me. At the moment, I'm afraid there is no global
Teredo relay running, so the service is pretty unusable, except for
client-to-client communication, anyway.
anon...@discussions.microsoft.com
I assignned the same internal client port, 34567, to both
computers to see if my router, a Linksys BEFSR41v3, was
by chance making the external port the same as the
internal one. It seemed unlikely, but I wanted to check.
If it did, the external IP address, port number pair
would be the same for both computers, and there would be
an ambiguous situation. Each machine qualified in Teredo
which seems to rule out the router making the external
port the same as the internal port. But I admit that I am
still confused.
Thanks again.
>.
>
anon...@discussions.microsoft.com
it was carried out just as described in the "Teredo
Overview". I monitored the packets going through the
Ethernet adapter on the computer that was qualifying.
This computer is connected to a Linksys BEFSR41v3 router
which is connected to an ADSL modem. To remove one
variable I disabled UPnP on the router and the Windows XP
computer.
I could see the first local packet with the local IP
address and local port going out to the Teredo Server,
and so forth. Eventually the Teredo Server sent back a
router advertisement with the Origin Indicator. The
latter is supposed to contain the external IP and
external port. It did contain the external IP, but
instead of the external port it had the internal port.
Well, I say it had the "internal port", but I have not
completely ruled out the possibility that my router is
assigning the external port number equal to the internal
port number. However, an earlier experiment described in
an earlier message in this thread makes me doubt it. So
far I have not been able to find a way to inspect the NAT
assignments inside the router, in particular, the ports.
Any suggestions?
So I am still confused.
PS. Teredo said that the computer was behind a restricted
NAT, which was clear from the Ethereal display.
>.
>
Remi Denis-Courmont
> I could see the first local packet with the local IP
> address and local port going out to the Teredo Server,
> and so forth. Eventually the Teredo Server sent back a
> router advertisement with the Origin Indicator. The
> latter is supposed to contain the external IP and
> external port. It did contain the external IP, but
> instead of the external port it had the internal port.
> Well, I say it had the "internal port", but I have not
> completely ruled out the possibility that my router is
> assigning the external port number equal to the internal
> port number. However, an earlier experiment described in
> an earlier message in this thread makes me doubt it. So
> far I have not been able to find a way to inspect the NAT
> assignments inside the router, in particular, the ports.
In all tests I carried out so far, whether behind a cone, a restricted or a
symmetric NAT, the server responded correctly. Anyway, there is no way that
the server could guess what the internal port is.
DO try to force the use of the same server IP on two computers behind the
same NAT with the same client port, and it should either break, or at least
one of them will get an external port that differs from the internal one.
anon...@discussions.microsoft.com
One computer was qualified with the server address
64.4.25.80 and with an external port number 1037
(obscured fbf2). I disabled Teredo in the other
computer, set the server name to 64.4.25.80 and the
client port to 1037. I then started the qualification
process with "set teredo client". I monitored with
Ethereal.
Four Router Solicitations were sent to 64.4.25.80. There
was no return Router Advertisement. Four Router
Solicitations were sent to 64.4.25.81. There was no
return Router Advertisement. At this point I assume that
Teredo gave up. I could see with "show teredo" in netsh
that Teredo was stuck in the state Probe(restricted).
I then set everything to default and executed "set teredo
client" again. Teredo qualified with the server address
64.4.25.84 and the obscured port fb64.
All that certainly strongly suggests that my router is
assigning the external port number equal to the internal
port number. Assuming that it does there is still a
question.
I know from an earlier experiment that if I leave the
server name set to default but force the two computers to
have the same client port, both computers qualify. They
send their first Router Solicitation to different server
addresses. This is before the computer has any
interaction with the server. The second one to
qualify "knows" somehow that it has to use a different
server address. However, there is 'rationality' and there
is 'faith', and at this point I guess I will just have
faith in Teredo.
Thanks for your help. Perhaps our conversation will be
of some value to other lost lambs.
>.
>
Remi Denis-Courmont
> I know from an earlier experiment that if I leave the
> server name set to default but force the two computers to
> have the same client port, both computers qualify. They
> send their first Router Solicitation to different server
> addresses. This is before the computer has any
> interaction with the server. The second one to
> qualify "knows" somehow that it has to use a different
> server address. However, there is 'rationality' and there
> is 'faith', and at this point I guess I will just have
> faith in Teredo.
Microsoft runs Teredo servers on 4 different IPs at the moment:
teredo.ipv6.microsoft.com. 1395 IN A 64.4.25.80
teredo.ipv6.microsoft.com. 1395 IN A 64.4.25.82
teredo.ipv6.microsoft.com. 1395 IN A 64.4.25.84
teredo.ipv6.microsoft.com. 1395 IN A 64.4.25.86
When performing a DNS query, responses might show in a different order, as
DNS implements sort of a round-robin (I believe). So, there is only about
25% odds that the second computer will use the same IP as the first one and
fail to qualify.
--
Rémi
anon...@discussions.microsoft.com
facts.
I was still uncomfortable with the idea that my router
was setting the external and internal ports equal to one
another. So I downloaded and installed Intel Device Spy.
This tool allows me to query my UPnP router's port
mapping. It showed that the router was NOT making the
port numbers equal. So it seems that my Teredo addresses
are incorrect because they use the internal port numbers
instead of the external port numbers.
So how can my Teredo work? I think that it wouldn't if
it were really tested. But it looks like nobody is using
it because there are no relays. The things that are
currently going on---qualification, maintaining the
mapping, and whatever---are not broken by this mistake.
I wonder about ping and ping6.
On the other hand, I may just still be hopelessly
confused.
>.
>
Remi Denis-Courmont
> So how can my Teredo work? I think that it wouldn't if
> it were really tested. But it looks like nobody is using
> it because there are no relays.
It used to work... until the only world-reachable Teredo relay at
203.254.33.13 (in South Korea) stopped about 2 months ago.
anon...@discussions.microsoft.com
One: Were people doing more than pinging?
Two: Were they using the Microsoft Teredo client or were
they using some other, say Unix-based, Teredo client? If
this is a bug, it is most likely confined to Microsoft.
Three: Were they using the Microsoft Servers. I suspect
that the answer is yes. Anyway I don't think that the
server is the source of the problem.
Thanks again for talking to me.
>.
>
Remi Denis-Courmont
> Three questions:
>
> One: Were people doing more than pinging?
Yes. This one browse http://www.kame.net/ through Teredo:
http://people.via.ecp.fr/~rem/samples/miredo-restricted-nat.pcap
(libpcap packet capture, open with Ethereal, tcpdump, etc.)
> Two: Were they using the Microsoft Teredo client or were
> they using some other, say Unix-based, Teredo client? If
> this is a bug, it is most likely confined to Microsoft.
NO Unix-based Teredo _clients_ were released so far. The packet capture was
done using Windows XP Pro SP1 and MSIE 6.
> Three: Were they using the Microsoft Servers. I suspect
> that the answer is yes. Anyway I don't think that the
> server is the source of the problem.
No, not in that packet capture.
anon...@discussions.microsoft.com
me try again.
During the qualification process the Teredo Server sends
two router advertisements to the client. Each contains
an origin indicator, and these two origin indicators will
be the same (assuming that the client is not behind a
symmetric NAT). Each origin indicator contains obscured
versions of the client's external IP address and external
port. The client uses this information in the creation of
its address. This is how the client finds out what is
going on on the external side of its NAT. Anyway the
client constructs the Teredo address.
When I monitor the qualification process on each of my
two computers with Ethereal I see the Teredo server
sending back router advertisements with incorrect origin
indicators: obscured external IP address and obscured
internal port number. Note that this is before the
client's Teredo program has touched the incoming packets.
That is weird: how can the Teredo Server know the
internal port number? And here I must admit that I have
come full circle in our discussion: I am repeating myself.
I was wondering if you could repeat my experiment. That
is, assuming that you have Ethereal or some other packet
sniffer could you monitor your Teredo qualification
process? I am also assuming that you are behind a NAT.
Finally and back to the original third question, what I
was trying to say was that I could not see that the
Teredo Server was the source of my client qualification
problem, and I still cannot see it.
Once again thanks for your help.
>.
>
Remi Denis-Courmont
> I was wondering if you could repeat my experiment. That
> is, assuming that you have Ethereal or some other packet
> sniffer could you monitor your Teredo qualification
> process? I am also assuming that you are behind a NAT.
http://people.via.ecp.fr/~rem/miredo/dump/
hotmail-restricted-nat.pcap should be what you are looking for.
Note that because capture were taken from the NAT box rather than the
client, packets appear twice: once inside the LAN, once outside the NAT.
As one can seen, Microsoft Teredo's servers work fine and return the
external UDP port.
Gisle Vanem
> http://people.via.ecp.fr/~rem/miredo/dump/
> hotmail-restricted-nat.pcap should be what you are looking for.
> Note that because capture were taken from the NAT box rather than the
> client, packets appear twice: once inside the LAN, once outside the NAT.
Hi Rémi,
How come all the captures have Linux SLL (serial-line cooked) pcap
headers? You obviously used a unix box to capture them, but don't understand
what PPP has to do with your diagram. Reading the dumps with tcpdump is rather
confusing:
> tcpdump -ter 6wind-cone-nat.pcap
reading from file 6wind-cone-nat.pcap, link-type LINUX_SLL (Linux cooked)
< 00:06:25:9a:d5:3a ip 121: 192.168.1.64.3100 > 195.220.208.2.3544: UDP, length 77
> ip 121: ALille-210-1-13-139.w217-128.abo.wanadoo.fr.3100 > 195.220.208.2.3544: UDP, length 77
So frame 1 (outgoing) has a link-layer header, but frame 2 has not?!
I'm not a linux expert, so I wonder how is that possible? Tethereal
shows a bit more details:
> tethereal -Vr 6wind-cone-nat.pcap
Frame 1
...
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: 00:06:25:9a:d5:3a (LinksysG_9a:d5:3a)
...
Frame 2
...
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 512
Link-layer address length: 0
Source: <MISSING>
HW-type 512 is PPP according to Linux' if_arp.h.
--gv
anon...@discussions.microsoft.com
thing. I even checked the obscured external port number
and it is correct. I gotta think about this. Weirdness
abounds!
I don't know if Teredo clients are pingable, but if they
are my address today (Saturday) is
3ffe:831f:4004:1954:0:f8d7:aff4:27c2
>.
>
Remi Denis-Courmont
> "Remi Denis-Courmont" wrote:
>
>> http://people.via.ecp.fr/~rem/miredo/dump/
>> hotmail-restricted-nat.pcap should be what you are looking for.
>> Note that because capture were taken from the NAT box rather than the
>> client, packets appear twice: once inside the LAN, once outside the NAT.
>
> Hi Rémi,
>
> How come all the captures have Linux SLL (serial-line cooked) pcap
> headers? You obviously used a unix box to capture them, but don't
> understand what PPP has to do with your diagram.
Captures were actually taken on a Linux NAT box. The internal interface is
Ethernet. My Internet connectivity is PPP+IPCP, as for most ADSL
connectivity in France (instead of Ethernet+DHCP).
(...)
> So frame 1 (outgoing) has a link-layer header, but frame 2 has not?!
Frame 1 has Ethernet as layer 2, frame 2 has PPP as layer 2, and PPP uses no
link-layer address, as it is a Point-to-point link-layer.
> I'm not a linux expert, so I wonder how is that possible?
tcpdump -i any [+ appriopriate filters]
will capture packets on all interfaces, resulting in captures with possibly
changing link-layer type.
Gisle Vanem
> tcpdump -i any [+ appriopriate filters]
> will capture packets on all interfaces, resulting in captures with possibly
> changing link-layer type.
I see. Any way to tell a *live* tcpdump capture from which interface the
packet came from? The offline pcap format doesn't seem to save this
info.
--gv
Remi Denis-Courmont
> I see. Any way to tell a *live* tcpdump capture from which interface the
> packet came from? The offline pcap format doesn't seem to save this
> info.
I am not sure if I understand your question. To specify which interface to
capture packet from, there is "-i <iface>", or "-i any" to use sort of a
wildcard interface as I did. I suppose it is not possible to specify from
which interface a packet is received in libpcap packets captures format.
Remi Denis-Courmont
> Thanks. That is beautiful. It is doing exactly the right
> thing. I even checked the obscured external port number
> and it is correct. I gotta think about this. Weirdness
> abounds!
>
> I don't know if Teredo clients are pingable, but if they
> are my address today (Saturday) is
>
> 3ffe:831f:4004:1954:0:f8d7:aff4:27c2
Unless somebody brought up a new global Teredo relay, people will need their
own relay or have to be a Teredo client too.
By the way, unless you setup the IPv6 firewall correctly, Windows XP won't
accept ICMPv6 echo requests.
(cf. current thread "Re: getaddrinfo vs gethostbyname")
anon...@discussions.microsoft.com
and that explains my problem. Teredo is innocent.
I set up things so that I could simultaneously monitor
the packets on the local side of the router and on the
external (uplink) side with Ethereal. (I inserted an old-
fashioned (non-switching) hub between the router and the
modem, and I used my laptop to monitor the traffic
between the router and modem.)
I monitored Teredo qualification, and I could see clearly
that the NAT was changing the IP address but letting the
port number pass through unchanged.
The confusing thing was that the router and the Intel
Device Spy both showed that the NAT in the router was
working correctly; that is, changing both the IP address
and the port number. So the port mapping table in the
router is correct, but it is not being used by the router
to make the actual connections.
I have tried to explain this to Linksys a couple of
times, but they keep suggesting "port triggering".
>.
>
Remi Denis-Courmont
> The NAT in my Linksys BEFSR41v3 is not working correctly,
> and that explains my problem. Teredo is innocent.
Might have to do with the version number, but it still sounds bizarre, as
Microsoft reported it to support Teredo:
http://www.microsoft.com/windowsxp/p2p/natcompat.mspx
Maybe reset the router to factory defaults (Linksys routers tends to break
when one upgrade their firmware, until resetting their configuration).
(...)
> The confusing thing was that the router and the Intel
> Device Spy both showed that the NAT in the router was
> working correctly; that is, changing both the IP address
> and the port number. So the port mapping table in the
> router is correct, but it is not being used by the router
> to make the actual connections.
>
> I have tried to explain this to Linksys a couple of
> times, but they keep suggesting "port triggering".
I haven't got very nice experience with their online support either.