Trying to debug routing issue with incoming packets

[jsgf]

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

[broquea]

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.

[jsgf]

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.