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

a problem communicating with ipv6.he.net

Started by wamble, September 16, 2010, 01:07:56 AM

Previous topic - Next topic

wamble

I've been working my way through getting a tunnel set up and doing the certification stages, but I'm having trouble getting through to ipv6.he.net  in a browser, although I can get through to ipv6.google.com without problem. A request to ipv6.he.net just times out, although I can ping the site OK. Any suggestions on what I'm doing wrong would be gratefully accepted.

First, my configuration - the tunnel endpoint is a Ubuntu 10.04 box NAT'd behind a Billion 7404 with an ADSL connection. The Billion has the firewall and I've allowed protocol 41 through it and forwarded all that traffic to my box. No firewall errors are visible. Looking at wireshark dumps from a connection to google and one to to HE, it appears that ipv6.he.net just doesn't reply, whereas ipv6.google.com does.

iface eth0 inet static
        address 192.168.7.46
        netmask 255.255.255.0
        network 192.168.7.0
        broadcast 192.168.7.255
        gateway 192.168.7.254

iface eth0 inet6 static
        address 2001:470:1f05:1179::1
        netmask 64

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
       address 2001:470:1f04:1179::2
       netmask 64
       endpoint 72.52.104.74
       local 192.168.7.46
       gateway 2001:470:1f04:1179::1
       ttl 255


The interface addressing is setup as follows:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
    link/ether 00:1c:c0:4a:ca:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.46/24 brd 192.168.7.255 scope global eth0
    inet6 2001:470:1f05:1179::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::21c:c0ff:fe4a:ca67/64 scope link
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
    link/sit 0.0.0.0 brd 0.0.0.0
4: he-ipv6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN
    link/sit 192.168.7.46 peer 72.52.104.74
    inet6 2001:470:1f04:1179::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::c0a8:72e/128 scope link
       valid_lft forever preferred_lft forever


The routing tables are as follows:
root@# ip route
192.168.7.0/24 dev eth0  proto kernel  scope link  src 192.168.7.46
default via 192.168.7.254 dev eth0  metric 100
# ip -6 route
2001:470:1f04:1179::/64 via :: dev he-ipv6  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
2001:470:1f05:1179::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 via :: dev he-ipv6  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
default dev he-ipv6  metric 1024  mtu 1480 advmss 1420 hoplimit 0



cholzhauer

What does a traceroute6 to ipv6.he.net show?  It should work though if you're able to ping.

Can you get to any other IPv6 sites other than google?

wamble

A traceroute shows the following
traceroute to ipv6.he.net (2001:470:0:64::2) from 2001:470:1f04:1179::2, port 33434, from port 55143, 30 hops max, 60 byte packets
1  wamble-1.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:1179::1)  198.620 ms  202.444 ms  199.346 ms
2  gige-g3-20.core1.fmt2.ipv6.he.net (2001:470:0:45::1)  202.452 ms  199.826 ms  190.849 ms
3  gige-g4-18.core1.fmt1.ipv6.he.net (2001:470:0:2d::1)  206.722 ms  200.715 ms  201.043 ms
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


The same works without the stars to ipv6.internode.on.net or ipv6.google.com eg.
traceroute to ipv6.internode.on.net (2001:44b8:8020:f501:250:56ff:feb3:6633) from 2001:470:1f04:1179::2, port 33434, from port 53088, 30 hops max, 60 byte packets
1  wamble-1.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:1179::1)  198.980 ms  198.080 ms  199.468 ms
2  gige-g3-20.core1.fmt2.ipv6.he.net (2001:470:0:45::1)  205.071 ms  199.938 ms  199.192 ms
3  10gigabitethernet1-1.core1.sjc2.ipv6.he.net (2001:470:0:31::2)  200.417 ms  195.754 ms  189.681 ms
4  gi0-1.bdr1.sjc2.internode.on.net (2001:504:0:1::4739:1)  206.084 ms  202.734 ms  200.098 ms
5  pos7-0-0.bdr1.syd7.internode.on.net (2001:44b8:b070:1::1)  353.783 ms  439.850 ms  358.800 ms
6  pos7-0.bdr1.adl6.internode.on.net (2001:44b8:8060:7::1)  374.362 ms  372.365 ms  371.111 ms
7  gi1-13.cor3.adl2.internode.on.net (2001:44b8:8060:12::2)  375.371 ms  392.291 ms  386.387 ms
8  te2-1.rtr2.adl6.internode.on.net (2001:44b8:8060:8::2)  375.517 ms  374.304 ms  368.599 ms
9  2001:44b8:8020:f501:250:56ff:feb3:6633 (2001:44b8:8020:f501:250:56ff:feb3:6633)  376.998 ms  371.301 ms  367.668 ms


Mind you, tracert6 works to all three sites (internode, he, google) without an issue. I'm not familiar enough with the difference between tracert6 and traceroute6, and the man pages are a bit confusing; one uses ICMP and the other uses UDP, if I understand it - perhaps that's relevant.

I can also say that a web request to ipv6.internode.on.net just hangs as well. The curious thing is that I can telnet to port 80 on ipv6.he.net and ipv6.internode.on.net.
Trying 2001:470:0:64::2...
Connected to ipv6.he.net.
Escape character is '^]'.


That's as far as I get, though. Could it be routing of return packets being blocked somewhere? I suppose I should consider configuring a DMZ and moving the server there without a firewall in the way

cholzhauer

#3
Yeah, I would get rid of the firewall temporarily to make sure everything is working.

When I run a traceroute6 to ipv6.he.net, it stops at the same point yours does



[carl@mars ~]$ traceroute6 ipv6.he.net
traceroute6 to ipv6.he.net (2001:470:0:64::2) from 2001:470:c27d:e000:20c:29ff:fe26:51b7, 64 hops max, 12 byte packets
1  2001:470:c27d:d000:2e0:81ff:fe79:f4c4  0.987 ms  1.049 ms  1.020 ms
2  servicespring-1.tunnel.tserv9.chi1.ipv6.he.net  41.144 ms  40.771 ms  41.469 ms
3  gige-g3-4.core1.chi1.ipv6.he.net  49.000 ms  48.956 ms  51.076 ms
4  10gigabitethernet1-1.core1.mci1.he.net  49.249 ms  49.794 ms  53.486 ms
5  10gigabitethernet1-1.core1.den1.he.net  63.992 ms  62.231 ms  80.722 ms
6  10gigabitethernet1-4.core1.lax2.he.net  116.251 ms  91.631 ms  87.833 ms
7  10gigabitethernet7-3.core1.sjc2.he.net  96.335 ms  95.589 ms  94.944 ms
8  10gigabitethernet2-2.core1.fmt2.he.net  90.186 ms  107.988 ms  98.780 ms
9  gige-g4-18.core1.fmt1.ipv6.he.net  100.311 ms * *
10  * * *
11  * * *


Freebsd doesn't have tracert6, so I can't help you there.

What does this show?

http://www.whatismyipv6.net/

EDIT::

Looking at this closer...I don't know if this matters or not, but I'll throw it out there.

You're routing your routed /64 out your HE tunnel interface while at the same time routing your tunnel interface (1f04) out eth0.  On my IPv6 router, I'm doing the opposite.


default                           gif1                          US         gif1

2001:470:1f10:2aa::/64            link#6                        U          gif1
2001:470:1f10:2aa::2              link#6                        UHS         lo0
2001:470:c27d::/48                2001:470:c27d:d000:21d:a2ff:feaf:2ffd UGS        nfe0
2001:470:c27d:d000::              link#3                        UHS         lo0 =>


My router is outside my firewall, so I'm routing my entire /48 at my firewall.  2001:470:c27d:d000::/64 is the subnet that my ipv6 router is in, so that's just routed to the local interface.  My default route is pointed at my tunnel interface.

wamble

Quote from: cholzhauer on September 16, 2010, 06:53:28 AM
Yeah, I would get rid of the firewall temporarily to make sure everything is working.

I've done that, but there's no difference.

Quote from: cholzhauer on September 16, 2010, 06:53:28 AM
When I run a traceroute6 to ipv6.he.net, it stops at the same point yours does

good to know...

Quote from: cholzhauer on September 16, 2010, 06:53:28 AM
What does this show?

http://www.whatismyipv6.net/

I can't get there - same problem  as ipv6.he.net :'(


Quote from: cholzhauer on September 16, 2010, 06:53:28 AM
You're routing your routed /64 out your HE tunnel interface while at the same time routing your tunnel interface (1f04) out eth0.  On my IPv6 router, I'm doing the opposite.

I think you might have misread that. The route entries from my original post are:

# ip -6 route
2001:470:1f04:1179::/64 via :: dev he-ipv6  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
2001:470:1f05:1179::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
default dev he-ipv6  metric 1024  mtu 1480 advmss 1420 hoplimit 0


My tunnel endpoint is the 1f04 address  (2001:470:1f04:1179::2/64) and that /64 subnet is routed via the tunnel. 1f05 is the routed/64 (don't have a routed/48) and it's routed via eth0 for a second linux box that I was hoping to expand ipv6 connectivity to. Whether or not I need the first route, given the third, I don't know. However I don't think it hurts, and removing it doesn't change the situation.

Simplifying matters, I removed the 1f05 address from eth0 and the corresponding route from the routing table. I still have the same failure situation. In fact, I changed my setup to use the exact commands (with the NAT'd address change) as copied from the tunnel setup page into rc.local, just in case there was some problem using the interfaces configuration method - no change  >:(

wamble

Quote from: cholzhauer on September 16, 2010, 06:53:28 AM
What does this show?

http://www.whatismyipv6.net/


I was just browsing this forum and found the following URL mentioned in a post:

http://www.data.jp/ipv6/ipv6check.php

I tried that with lynx and, surprise, it worked. Here's the information I get in reply:

IPv6 check @ Hart                                                               
                                                                               
   Hart Computer, Inc. is located in Tokyo, Japan                               
   You are IPv6 connection                                                     
   Your IP address ---- "2001:470:1f04:1179::2"                                 
   Your Hostname ---- "wamble-1-pt.tunnel.tserv3.fmt2.ipv6.he.net"


I immediately tried ipv6.he.net and ip6.me and they both still hang   ???

wamble

I still have the issue, but managed to pass the certification level by "cheating" -  after dropping the HE tunnel and startup up a teredo tunnel, I could access the site from a valid IPv6 address.

I guess the problem is "solved".

pilax

I have the issue too but can't find a real solution for now !
http://www.tunnelbroker.net/forums/index.php?topic=1188.0

And the problem arise with all the sites *.he.net, tunnelbroker.net

I'll search that ^$*รน problem and keep you posted.

donbushway

This is what I get going to that website.

IPv6 check @ Hart
Hart Computer, Inc. is located in Tokyo, Japan

You are IPv6 connection

Your IP address ---- "2001:470:1f0f:4ef:704a:88df:7b6e:9afa"
Your Hostname ---- "2001:470:1f0f:4ef:704a:88df:7b6e:9afa"

It appears the tunnel address and routed are swapped at the interface as Cholzhauer suggested earlier.

wamble

Quote from: donbushway on September 19, 2010, 08:52:47 AM
This is what I get going to that website.

IPv6 check @ Hart
Hart Computer, Inc. is located in Tokyo, Japan

You are IPv6 connection

Your IP address ---- "2001:470:1f0f:4ef:704a:88df:7b6e:9afa"
Your Hostname ---- "2001:470:1f0f:4ef:704a:88df:7b6e:9afa"

It appears the tunnel address and routed are swapped at the interface as Cholzhauer suggested earlier.

See post 5 - I removed the routed 64 network configuration from my machine and the problem remains.

wamble

I've been playing with telnet to access the HE web server. Could someone tell me why the first session works, and the second fails?

ericr@golem:~$ telnet -6 ipv6.he.net 80
Trying 2001:470:0:64::2...
Connected to ipv6.he.net.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 20 Sep 2010 08:06:17 GMT
Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.4-2ubuntu5.10
Set-Cookie: referer=Direct+Access; expires=Wed, 20-Oct-2010 08:06:18 GMT
Connection: close
Content-Type: text/html


ericr@golem:~$ telnet -6 ipv6.he.net 80
Trying 2001:470:0:64::2...
Connected to ipv6.he.net.
Escape character is '^]'.
GET / HTTP/1.0



The second hangs and I have to ^C it.

pilax

Same issue here on a PPPOE gateway...

Here is the routing table (xl1 is LAN) :
Internet6:
Destination                        Gateway                        Flags   Refs      Use   Mtu  Prio Iface
::/104                             ::1                            UGRS       0        0     -     8 lo0
::/96                              ::1                            UGRS       0        0     -     8 lo0
default                            2001:470:1f0a:19a4::1          UGS        1      335     -     8 gif0
::1                                ::1                            UH        14        0 33200     4 lo0
::127.0.0.0/104                    ::1                            UGRS       0        0     -     8 lo0
::224.0.0.0/100                    ::1                            UGRS       0        0     -     8 lo0
::255.0.0.0/104                    ::1                            UGRS       0        0     -     8 lo0
::ffff:0.0.0.0/96                  ::1                            UGRS       0        0     -     8 lo0
2001:470:1f0a:19a4::/64            link#2                         UC         1        0     -     4 xl1
2001:470:1f0a:19a4::1              2001:470:1f0a:19a4::2          UH         1        0     -     4 gif0
2001:470:1f0a:19a4::2              link#8                         UHL        1        0     -     4 lo0
2001:470:1f0a:19a4::3              00:10:5a:a2:b5:80              UHL        0        0     -     4 lo0
2001:470:1f0a:19a4:3103:e920:2a2d:dd27 00:11:d8:3c:d1:26              UHLc       0        6     -     4 xl1
2002::/24                          ::1                            UGRS       0        0     -     8 lo0
2002:7f00::/24                     ::1                            UGRS       0        0     -     8 lo0
2002:e000::/20                     ::1                            UGRS       0        0     -     8 lo0
2002:ff00::/24                     ::1                            UGRS       0        0     -     8 lo0
fe80::/10                          ::1                            UGRS       0        0     -     8 lo0
fe80::%xl0/64                      link#1                         UC         0        0     -     4 xl0
fe80::20a:5eff:fe4c:98c9%xl0       00:0a:5e:4c:98:c9              UHL        0        0     -     4 lo0
fe80::%xl1/64                      link#2                         UC         0        0     -     4 xl1
fe80::210:5aff:fea2:b580%xl1       00:10:5a:a2:b5:80              UHL        0        0     -     4 lo0
fe80::%lo0/64                      fe80::1%lo0                    U          0        0     -     4 lo0
fe80::1%lo0                        link#4                         UHL        0        0     -     4 lo0
fe80::%pppoe0/64                   fe80::20a:5eff:fe4c:98c9%pppoe0 U          0        0     -     4 pppoe0
fe80::20a:5eff:fe4c:98c9%pppoe0    link#5                         HL         0        0     -     4 lo0
fe80::%gif0/64                     link#8                         UC         0        0     -     4 gif0
fe80::20a:5eff:fe4c:98c9%gif0      link#8                         UHL        0        0     -     4 lo0
fec0::/10                          ::1                            UGRS       0        0     -     8 lo0
ff01::/16                          ::1                            UGRS       0        0     -     8 lo0
ff01::%xl0/32                      link#1                         UC         0        0     -     4 xl0
ff01::%xl1/32                      link#2                         UC         0        0     -     4 xl1
ff01::%lo0/32                      ::1                            UC         0        0     -     4 lo0
ff01::%pppoe0/32                   fe80::20a:5eff:fe4c:98c9%pppoe0 UC         0        0     -     4 pppoe0
ff01::%gif0/32                     link#8                         UC         0        0     -     4 gif0
ff02::/16                          ::1                            UGRS       0        0     -     8 lo0
ff02::%xl0/32                      link#1                         UC         0        0     -     4 xl0
ff02::%xl1/32                      link#2                         UC         0        0     -     4 xl1
ff02::%lo0/32                      ::1                            UC         0        0     -     4 lo0
ff02::%pppoe0/32                   fe80::20a:5eff:fe4c:98c9%pppoe0 UC         0        0     -     4 pppoe0
ff02::%gif0/32                     link#8                         UC         0        0     -     4 gif0

wamble

Thanks to Alex Broque, this problem has been resolved. It was a MTU issue, not routing.

I had to change my eth0 and he-ipv6 interfaces to 1280 instead of 1480. I also found that I had to change the MTU on the hosts in the routed/64 (a minor pain on windows :) )

Thanks to all who suggested things and shared their experience and configuration, and I hope this solution helps others.

broquea

Shouldn't have had to touch eth0, just the tunnel interface.

pilax

I don't know who Alex Broque is but thank you very much !  ;)

By the way on my OpenBSD this option is enough in the pf.conf
match in all scrub (max-mss 1400)

I don't have to change the mtu on my client.

By the way I tried sixxs tunnel and the same issue arise !!!

Well champagne !  ;D