I have a VPS hosted by Linode, which I believe is co-located with HE in Fremont.
I have it set up with a tunnel for IPV6 (since Linode don't support native ipv6 yet).
The trouble is that incoming packets are not being routed to my machine; they're being dropped by the hast hop before my system:
client$ traceroute6 claw.goop.org
traceroute to claw.goop.org (2001:470:1f04:bb::2), 30 hops max, 80 byte packets
1 2001:470:a816::1 (2001:470:a816::1) 141.313 ms 142.705 ms 142.913 ms
2 tunnel1506.tserv2.fmt.ipv6.he.net (2001:470:1f01:ffff::afc) 143.150 ms 144.866 ms 145.883 ms
3 v702.core1.fmt1.he.net (2001:470:0:1f::1) 143.951 ms 144.191 ms 144.334 ms
4 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 144.823 ms 145.050 ms 145.300 ms
5 gige-gbge0.tserv3.fmt2.ipv6.he.net (2001:470:0:45::2) 145.631 ms 145.955 ms 146.010 ms
6 gige-gbge0.tserv3.fmt2.ipv6.he.net (2001:470:0:45::2) 75.143 ms !H 54.378 ms !H 77.948 ms !H
However, as soon as I send a single packet out from my server, it all works fine:
claw$ ping6 -c1 ipv6.google.com
PING ipv6.google.com(pz-in-x67.1e100.net) 56 data bytes
64 bytes from pz-in-x67.1e100.net: icmp_seq=1 ttl=54 time=24.8 ms
--- ipv6.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 24ms
rtt min/avg/max/mdev = 24.824/24.824/24.824/0.000 ms
client$ traceroute6 claw.goop.org
traceroute to claw.goop.org (2001:470:1f04:bb::2), 30 hops max, 80 byte packets
1 2001:470:a816::1 (2001:470:a816::1) 40.718 ms 45.471 ms 45.615 ms
2 tunnel1506.tserv2.fmt.ipv6.he.net (2001:470:1f01:ffff::afc) 45.894 ms 50.972 ms 51.190 ms
3 v702.core1.fmt1.he.net (2001:470:0:1f::1) 50.169 ms 50.708 ms 50.343 ms
4 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 54.553 ms 54.685 ms 60.000 ms
5 gige-gbge0.tserv3.fmt2.ipv6.he.net (2001:470:0:45::2) 60.013 ms 68.676 ms 63.879 ms
6 jsgf-2-pt.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:bb::2) 73.767 ms !X 33.030 ms !X 33.303 ms !X
The server's routing table is:
unreachable ::/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
2001:470:1f04:bb::/64 via :: dev sit1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
2001:470:1f05:bb::/64 via :: dev sit1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
unreachable 2002:a00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable 2002:7f00::/24 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable 2002:a9fe::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable 2002:ac10::/28 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable 2002:c0a8::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable 2002:e000::/19 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 0
fe80::/64 via :: dev sit1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
default dev sit1 metric 1 mtu 1480 advmss 1420 hoplimit 0
and the interface is has a number of addresses:
ip addr list dev sit1
4: sit1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN
link/sit 0.0.0.0 peer 72.52.104.74
inet6 2001:470:1f05:bb::8/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::7/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::3/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::6/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::5/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::4/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::2/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f05:bb::1/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:470:1f04:bb::2/64 scope global
valid_lft forever preferred_lft forever
However, in the non-working state, tcpdump shows no packets turning up anyway, so I think the problem is on the HE side?
Any clues?
Thanks,
J
iptables/ip6tables?
Sounds like something on your side drops connection state until you source something outbound. That isn't an issue on the tunnel-server side.
Sigh, thanks for making me double check. I wasn't explicitly allowing protocol 41 in, but contrack was allowing it once there'd been an outgoing packet. So things worked fine until contrack dropped the entry.