Keeping up tunnel

[auscity]

I have had to put in a cron on my two servers, to ping6 ipv6.google.com every minute.

If I don't my server becomes unavailable.  It comes back in another few minutes, like the tunnel is being refreshed every 5 minutes, but it goes off after about 2 minutes or so, resulting in it being unavailable for a minute or two to some built in refresh.

I can't give  exact time, but its something like this.

Since starting cron with that, it up constantly.

Before the cron, if I ssh in and simply ping6 ipv6.google.com, immediately my subnet was reachable from outside.

Any idea's?  I have not touched anything, it seems crazy to constantly ping ipv6.google to keep the damn tunnel up 100%.

My other server the same.  Also outbound is way faster with the ping, I dont see the delay in lookup my the name for an ip6 site.


Thanks!

[broquea]

Check conn-track rules either on the machine itself; or if there is a nat/router/firewall in front, on that machine. Sounds like the session stops getting stored and then you need to source an outbound connection to make it live again.

[auscity]

Nope it's a web server all the IPs on the eth0 are WAN addresses, there is no nat. There is also no port blocking apart from a DOS attack firewall.

I can't figure it out. The ipv4 addresses never ever do this. It's something with the hurricane tunnel. The only ipv6 address I can ping6 is the eth0 adapter as it's got a static ipv6 address.

Once the ping6 happens on the server, all the IPs that are allocated by radvd then reply.

It's definitely tunnel related to hurricane.

Also my second server does with as well (this one does have NAT as it's our LAN/WAN GW server). Without a minute ping6 I get long DNS lookups (if you in firefox look up a IPv6 site you see it resolving xxxx and after about 2 seconds the site comes up.

Running 1 minute pings on this server, then you firefox on a client, the site comes immediately up without the 2 second lookup.

[cholzhauer]

The only time I've seen this is when there's a firewall interfering with packets, like broquea suggested.