• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

whatismyipv6 says I don't have ipv6

Started by PracticalShutIn, July 12, 2013, 01:55:23 PM

Previous topic - Next topic

PracticalShutIn



I tried to set this up a couple of years ago but gave up because I got stuck at this same point.

I created a regular tunnel, generated the code, pasted it into a .bat file, ran it.

I go to whatismyipv6.net and it shows my ipv4 address.  I have tried ipv6.google.com and the page doesn't display.  I tried kame.net, the turtle doesn't dance.

It doesn't seem like there was much room for error, but somehow it doesn't work for me.

I'm using Windows 7 x64.  I have tried with my computer in the router's DMZ, firewall disabled, adblock disabled.

Am I missing something?

cholzhauer

Please list the commands you used to create the tunnel.

PracticalShutIn

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 75.119.250.239 184.105.253.14
netsh interface ipv6 add address IP6Tunnel 2001:470:1f10:a4a::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f10:a4a::1

cholzhauer

You mentioned that you put your computer in the dmz of your router.  That tells me that you're behind a nat, which means that you need to replace your pubic ip with the private address of your computer.

Remove the ip6tunnel interface and rerun the commands using your nat ip address instead

PracticalShutIn


Ok I did
netsh interface ipv6 delete interface "IP6Tunnel"

no errors

Then I redid the bat file with my 192.168 address instead of the 75.119 address.  No errors.

Then I tried the 3 ipv6 sites and the first thing I noticed is that browsing is really slow.  But the 3 ipv6 sites do exactly the same as they did before.

kasperd

Are you sure you got the IPv4 addresses right? When I did a traceroute to 75.119.250.239 I do not get a response from that IP. The last functional hop on the route is 208.111.182.138. It looks the same for both ICMP echo requests and protocol 41 packets.

HE won't even let you configure a client IPv4, which is not reachable for ICMP echo requests. Not that there is any reason for this restriction, but that means you couldn't configure a tunnel on that client IPv4 address.

Also when I look at the IP address 2001:470:1f10:a4a::1 from your post, I find the tunnel server IP address 209.51.181.2, which is not what you have in your config.

PracticalShutIn

I have a dynamic IP and have since gotten a new one.  After getting the new IP, I updated the ipv4 address at tunnelbroker.  Then did netsh interface delete, then reran the bat file.

As for the " 209.51.181.2"... i have no clue what that is, as my new IP is 206.248.181.119.

kcochran

Quote from: kasperd on July 12, 2013, 11:42:56 PM
Also when I look at the IP address 2001:470:1f10:a4a::1 from your post, I find the tunnel server IP address 209.51.181.2, which is not what you have in your config.

That's fine actually.  Chicago and Dallas gained region-specific IPs a while ago.  New tunnels get the new IP, old tunnels still have the old, with an option of shifting to the new.

snarked

What's interesting is that whatismyipv6 also said I didn't have an IPv6 address either and listed my home DSL's IPv4.  Meanwhile, my collocated server clearly tells me (both on the page and the logs) that I came in via IPv6, so I know that my IPv6 works.

What I suspect is that both you and me are lacking an IPv6 path to the whatis... server OR that the DNS is resolving to an IPv4 address before an IPv6 address is encountered because that is what is in the answer packet first (even though it should take the AAAA record first).

Personally, I don't care about that site, but maybe these two things are happening to you and that explains why you're having trouble.
Therefore, check your DNS answers and your traceroute path and see if something is screwy there.

kasperd

Quote from: PracticalShutIn on July 13, 2013, 06:45:18 AMmy new IP is 206.248.181.119.
That IP does respond to ICMP echo request. But it appears to drop everything else. With that DMZ setting in place, your router should be sending time to live exceeded ICMP errors when a traceroute from the outside hits anything, which the DMZ setting applies to.

I tried traceroute with protocol 41 as well as TCP and UDP. In all cases there was silence from 206.248.181.119. Have you managed to get the DMZ setting to work for any other traffic?

Quote from: kcochran on July 13, 2013, 07:27:54 AMThat's fine actually.  Chicago and Dallas gained region-specific IPs a while ago.  New tunnels get the new IP, old tunnels still have the old, with an option of shifting to the new.
I am I understanding correctly, that 209.51.181.2 and 184.105.253.14 are both assigned to the same tunnel server? What is affected by switching to the new IP? Does it only influence the source IP of packets the server sends through the tunnel, or is something else affected as well?

kcochran

IP ranges are announced with priority in certain regions.  Dallas and Chicago pre-dated a Central-specific range, so had IPs which in certain cases would now come in via the West or East coast, instead of going directly Central.  To all intents, you could consider it a second tunnel server in that location, using the same IP pools, but with possibly better v4 routing in certain situations.

PracticalShutIn


The technical level is getting over my head now..

I don't know what a DNS answer is, and can't tell what is screwy when looking at a traceroute path.
C:\Users\Me>tracert 184.105.253.14
Tracing route to 184.105.253.14 over a maximum of 30 hops
  1     2 ms    <1 ms    <1 ms  192.168.0.254
  2   166 ms    16 ms    10 ms  lo-100.lns02.tor.packetflow.ca [206.248.154.122]
  3    14 ms     9 ms    10 ms  2150.ae3.bdr03.tor.packetflow.ca [69.196.136.163]
  4    18 ms     9 ms    14 ms  gw-he.torontointernetxchange.net [206.108.34.112]
  5    21 ms    23 ms    25 ms  10gigabitethernet12-1.core1.chi1.he.net [184.105.213.150]
  6    20 ms    20 ms    20 ms  184.105.253.14
Trace complete.


"Have you managed to get the DMZ setting to work for any other traffic?"
I don't quite understand the question.  I keep this computer in the DMZ at all times, and use a software firewall so I can see what is getting blocked.  Is there anything else that needs to be allowed besides ICMP?  There are a lot of ICMP v4 and v6 settings in my firewall that can be allowed/disallowed for inbound & outbound.

The only things shown in my firewall block log are a couple of TCP incoming packets blocked because of the "attack detection component"; a general Block IGMP rule; and a general "block NetBIOS traffic" rule for outgoing UDP.

kasperd

Quote from: PracticalShutIn on July 14, 2013, 08:52:54 AMI keep this computer in the DMZ at all times
What exactly do you mean by that?

Something was changed in your setup since I last checked this thread, because at that time 206.248.181.119 was responding to ICMP echo requests. But it is not responding anymore. I tried mtr towards that IP as well as the closest router from your output, and I got this.

Quote from: mtr 206.248.154.12210. 213.248.71.154                    0.0%   165   19.2  27.8  18.2 109.7  10.9
11. 69.28.172.130                     0.0%   165   27.5  30.0  20.0 123.9  13.1
12. 69.28.172.125                     0.0%   165   36.7  45.5  35.8 121.8  10.3
13. 69.28.172.5                       0.0%   165  124.7 131.5 117.4 378.3  27.8
14. 69.28.172.74                      0.0%   165  131.5 141.1 127.9 283.5  17.7
15. 208.111.182.138                   0.0%   165  162.3 156.9 147.4 270.7  13.6
16. 206.248.154.122                   0.0%   165  260.4 162.9 138.7 523.1  50.6
Quote from: mtr 206.248.181.11910. 213.248.71.154                    0.0%   152   31.6  29.1  17.6 123.6  15.1
11. 69.28.172.130                     0.7%   152   20.5  30.3  19.6 120.5  12.1
12. 69.28.172.125                     0.0%   152   39.7  45.9  36.0 119.5  11.3
13. 69.28.172.5                       0.0%   152  121.5 127.1 116.9 284.9  17.1
14. 69.28.172.74                      0.0%   152  134.2 136.9 127.6 274.5  13.4
15. 208.111.134.238                   0.0%   152  139.6 146.9 139.5 297.9  14.3
16. 69.196.136.47                     0.0%   152  141.0 157.6 138.3 378.3  40.5
17. ???

Previously the last hop before 206.248.181.119 was not responding, which is also inconsistent with what I am seeing now. Unfortunately I didn't save the previous output, so I can't compare. If you can tell what you changed since I looked previously, it may provide some hint.

PracticalShutIn

Quote from: kasperd on July 14, 2013, 11:04:23 AM
Quote from: PracticalShutIn on July 14, 2013, 08:52:54 AMI keep this computer in the DMZ at all times
What exactly do you mean by that?
"By using the Virtual DMZ port, a computer or device on the network is exposed to the Internet without protection from the firewall function of the Home Networking modem."  IIRC, it lets that computer bypass the router's firewall.

I can't figure out what has changed since your last post.. I haven't changed anything in the router, firewall, disconnected or rebooted the PC.  Isn't it a good thing that there's 0% packet loss for both mtrs?

cholzhauer

Keep in mind that the DMZ implementation on some routers is broken and does not expose it to protocol 41 traffic; there are numerous posts on here involving that.

You may want to grab something like wireshark and examine your traffic to see if you have protocol 41 packets hitting your computer.