Tunnel timing out?

[willmc]

I have two standard HE tunnels, one for my home network in New York (handled by a FreeBSD 7 system) and one for a Slicehost VM in Dallas (running Ubuntu 8.04).  It seems that my tunnels cease to allow inbound traffic after a period of inactivity, and I wanted to check and see if this is normal behavior.

For example, right now from home I can ping6 ipv6.google.com no problem, replies coming back nice and quick.  However, if I ping6 the endpoint of my tunnel in Dallas, I don't get a reply.  If I try to telnet -6 to any of the listening ports there, no connection opens.  However, if I ssh into that Dallas system via IPv4 and ping ipv6.google.com, I get replies.  And immediately thereafter, everything that would time out just a moment before (pings, connections) start working.  But if I let things idle for a while (I'm not yet sure how long it takes), the problem comes back.

I'd been hoping to set up my Slicehost VM to be able to provide services (HTTP, SMTP, etc.) over IPv6 in addition to IPv4, but it seems like this timeout issue makes it difficult to do that reliably.  Is this normal, or am I doing something wrong?

[brad]

For example, right now from home I can ping6 ipv6.google.com no problem, replies coming back nice and quick.  However, if I ping6 the endpoint of my tunnel in Dallas, I don't get a reply.  If I try to telnet -6 to any of the listening ports there, no connection opens.  However, if I ssh into that Dallas system via IPv4 and ping ipv6.google.com, I get replies.  And immediately thereafter, everything that would time out just a moment before (pings, connections) start working.  But if I let things idle for a while (I'm not yet sure how long it takes), the problem comes back.

This reminds me that I have had an issue that sort of sounds similar with both of my tunnels. I cannot ping the addresses assigned to the tunnels from the tunnels assigned /64 but I can to the routed /64 on the one and the routed /48 for the other. The packet filters on the systems do not appear to be blocking anything relevant.

The only thing I can see that might give a clue is I'm seeing neighbor solicitations with no replies.

This is from tcpdump from one of the tunnels.

2001:470:1c:8a::2 > 2001:470:1c:8a::1: icmp6: neighbor sol: who has 2001:470:1c:8a::1 (len 24, hlim 255)
2001:470:1c:8a::2 > 2001:470:1c:8a::1: icmp6: neighbor sol: who has 2001:470:1c:8a::1 (len 24, hlim 255)
2001:470:1c:8a::2 > 2001:470:1c:8a::1: icmp6: neighbor sol: who has 2001:470:1c:8a::1 (len 24, hlim 255)

2001:470:1c:8c::1 > 2001:470:1c:8c::2: icmp6: neighbor sol: who has 2001:470:1c:8c::2 (len 24, hlim 255)
2001:470:1c:8c::1 > 2001:470:1c:8c::2: icmp6: neighbor sol: who has 2001:470:1c:8c::2 (len 24, hlim 255)
2001:470:1c:8c::1 > 2001:470:1c:8c::2: icmp6: neighbor sol: who has 2001:470:1c:8c::2 (len 24, hlim 255)

[willmc]

I hate to bump this, but I'm still having the issue and can't for the life of me figure out why it's happening.  Can anyone shed any light on this weird timeout issue?

[willmc]

For the record, I found the answer over at SixXS:

https://www.sixxs.net/faq/connectivity/?faq=conntracking