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
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?
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
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.
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 >:(
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 ???
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".
I have the issue too but can't find a real solution for now !
http://www.tunnelbroker.net/forums/index.php?topic=1188.0 (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.
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.
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.
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.
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
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.
Shouldn't have had to touch eth0, just the tunnel interface.
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
Quote from: broquea on September 21, 2010, 08:01:21 AM
Shouldn't have had to touch eth0, just the tunnel interface.
Ok, I'll double check this tonight.
Quote from: wamble on September 21, 2010, 03:59:28 PM
Quote from: broquea on September 21, 2010, 08:01:21 AM
Shouldn't have had to touch eth0, just the tunnel interface.
Ok, I'll double check this tonight.
I just realised that I hadn't indicated what I found... Alex is right - only the tunnel interface needs the MTU changed. I'm not sure what was going on when I first tried this, but I reset eth0 and all is fine.
Is there a firewall blocking icmp (fragmentation needed, which is needed by pmtu) on he.net?
No. However, remember that ICMPv6 uses a different protocol code than IPv4 ICMP.