Take the 2-minute tour ×

I've got a Vista64 machine behind a NAT router connected to the IPv4 Internet.

Teredo is enabled on my machine and I've got a IPv6 address with 2001:0: prefix. I can ping several servers in the IPv6 Internet (like force.ipv6only.se or ipv6.google.com), and tracert reveals that my IPv6 traffic is routed through a teredo relay. However, I cannot connect to or ping my machine from a machine in the IPv6 Internet. A tracert in this direction stops at the teredo relay.

What steps are necessary to connect to a Teredo-enabled server behind NAT?

share|improve this question
add comment

3 Answers

Most likely a firewall issue. Ping is enabled if File and Printer Sharing is allowed. Vista's firewall, by default, only allows File and Printer Sharing on your local subnet. Thus, a machine from elsewhere on the IPv6 Internet is on a different subnet, and won't be able to access the File and Printer Sharing services, including Ping.

I haven't spent much time with Vista's firewall recently (I'm mainly a Linux user these days), so I can't give you exact steps to unblock this, but try temporarily turning off the firewall to see if it makes a difference.

share|improve this answer
add comment

If you are behind a NAT it is very likely that when the Teredo server tries to open a connection to you, but your NAT isn't forwarding the right port(s) on to you.

I'd find out which ports are required, or if possible forward all ports to your machine to test that it is indeed a port forwarding issue.

Check go6's wiki on Teredo and see if the section on "Teredo IPv6 addressing" gives you any insight to what else you might need to look into. You should be able to look at your assigned IPv6 address and then determine the ports you need forwarding.

share|improve this answer
My NAT reports two NAT sessions for my machine (type UDP): one with the Toredo server, and one with the Toredo relay. Following your advice, I've configured the router to forward all traffic to my machine, but no change... –  dtb Jun 1 '09 at 22:21
"If a Teredo relay (or another Teredo client) has to send an IPv6 packet to a Teredo client, it will first send a Teredo bubble packet to the client's Teredo server, whose IP address can be inferred from the Teredo IPv6 address of the Teredo client. The server can then forward the bubble to the client, so the Teredo client software knows that hole punching must be done toward the Teredo relay." It doesn't look like any port forwarding should be necessary to get this working... –  dtb Jun 1 '09 at 23:20
If your packet traces are dying at the Teredo server, then it's possible that whoever manages that server is explictly blocking new incomming connections without a prior outbound connection. Are you able to try other Toredo servers? –  jasonrm Jun 1 '09 at 23:28
Right, it might be possible that the relay is blocking incoming connections. I tried teredo.remlab.net. instead of teredo.ipv6.microsoft.com. but that doesn't seem to have any influence on which teredo relay is used. –  dtb Jun 1 '09 at 23:35
add comment

Check if the machine with native IPv6 is not behind a stateful firewall which blocks icmpv6.

I had a similar problem, where a machine in a network with 6to4 was not able to connect to a machine using teredo in another network. Explicitly allowing icmpv6 in the IPv6 firewall in the 6to4 gateway (instead of just using ip6table's -m state --state ESTABLISHED,RELATED) was enough to cure the issue. This happens because teredo sends a IPv6 ping to the "native" (6to4 in this case) host, in a way iptables does not identifies as "RELATED", and will not work if that ping packet is dropped or rejected.

Blocking ICMP in general tends to only cause headaches, but I (mistakenly as it turned out) believed netfilter's state tracker would be enough to allow all needed ICMP packets.

share|improve this answer
add comment

Your Answer


