Centos 5.4 IPv6 unreachable after a few minutes

[aprsca]

I'm not even quite sure how to explain this, so I will do my best.  I am also not quite sure what additional info you might need, so I will just present the scenario for now.  I have successfully configured the tunnel on my Centos 5.4 box, and have assigned an IPv6 address under my /64 block to eth0.  Everything always works great from the Linux box - I can ping6 all day long and connectivity doesn't seem to be an issue at all.  Next, I go to an external site and ping the IPv6 address assigned to the Centos box.  Works!  No problem!  Now, wait a few minutes, and try to ping from remote again, and it cannot reach the address.  Huh?  So I go back on the Centos box and try a few more ping6, and it works great!  Go back to the remote box, and I can ping again.  A few minutes later, it disappears.  The only way to make my Centos box reappear after a couple of minutes is to go on the physical box (or SSH shell) and initiate some IPv6 activity.  Why does the address become unreachable after a few minutes like this?  Anyone?

Tunnel to static IPv4
Linksys router running DD-WRT-micro (2 MB flash, so can't do IPv6 on that).  Protocol 41 seems to be passing fine.
sitx interface assigned my /64 address, say 2001:470:x:1234::2/64
eth0 interface assigned a static IPv6 address, say 2001:470:x:1234::4321, and the same address as the default gateway.

Thanks in advance for your help!

Phil

[jimb]

It's your Linksys timing out the connection/NAT table entry for the 6in4 (IP proto 41) traffic.

You have two choices:

• Set up a static NAT on the Linksys forwarding IP protocol 41 to your IPv6 router (the best option)
• Set up a ping on your IPv6 router, pinging the other side of the tunnel every few minutes, whatever is lower than the expiry time for your NAT FW's connection table entries.

That should fix it.  On a system I have no access to the IPv4 NAT firewall, I use a crontab entry like this:

*/2 * * * * ping6 -c1 -n -w5 2001:db8:1234:56::1 >/dev/null 2>&1

This pings the other side of the tunnel every two minutes.  The FW seems to time out connection table entries after about three minutes.  If you don't know how long it takes your FW to time out a connection table entry (usually poorly, or simply not documented), just ping it every minute.  That's usually sufficient.

[cholzhauer]

broquea had also suggested scripting an NTP task to run every so often

http://www.tunnelbroker.net/forums/index.php?topic=837.msg4229#msg4229

Reply #2

I used to have this problem with other tunnel brokers and was able to "fix" it by using a ping crontab entry.

[jimb]

Yeh running ntpdate in a crontab entry would at least do something useful I suppose, rather than a ping which does nothing. 

FYI, just having an ntpd running wouldn't query often enough once the clock stabilizes though.  That can slow down to one poll every ~17 minutes, which isn't frequent enough.  So it'd have to be ntpdate in a cron job about every 2 mins or so, depending on the expiry time of your connection/nat table on your FW.

[aprsca]

It's your Linksys timing out the connection/NAT table entry for the 6in4 (IP proto 41) traffic.

You have two choices:

• Set up a static NAT on the Linksys forwarding IP protocol 41 to your IPv6 router (the best option)

I have input the following commands into my Linksys:

iptables -t nat -A PREROUTING -i vlan1 -p 41 -j DNAT --to 10.0.0.x
iptables -t filter -A FORWARD -i vlan1 -p 41 -d 10.0.0.x -j ACCEPT

I verified the entries in the iptables, but no dice.  Still times out after a few minutes of inactivity on the Linux box.  I know I could set up a cron ping job, but I'm one of those folks who likes to get things to work that should work!  

[jimb]

It's your Linksys timing out the connection/NAT table entry for the 6in4 (IP proto 41) traffic.

You have two choices:

• Set up a static NAT on the Linksys forwarding IP protocol 41 to your IPv6 router (the best option)

I have input the following commands into my Linksys:

iptables -t nat -A PREROUTING -i vlan1 -p 41 -j DNAT --to 10.0.0.x
iptables -t filter -A FORWARD -i vlan1 -p 41 -d 10.0.0.x -j ACCEPT

I verified the entries in the iptables, but no dice.  Still times out after a few minutes of inactivity on the Linux box.  I know I could set up a cron ping job, but I'm one of those folks who likes to get things to work that should work!  

That looks like it should work, presuming that you're only natting a single public IP, and that there are no rules ahead of it in either chain which would match before those.  Especially DROP rules.  

EDIT: Another thought.  If your inside linux IPv6 router box is also running netfilter, make sure you have a similar filter table rule as above in the INPUT chain accepting the 6in4 traffic from the HE server.  If that is also relying on the netfilter connection table, it could also break things there, the router rejecting the "unsolicited" 6in4 traffic if no such rule is in place.

[aprsca]

That looks like it should work, presuming that you're only natting a single public IP, and that there are no rules ahead of it in either chain which would match before those.  Especially DROP rules.  

For the benefit of our readers, this seemed to be the trick.  Replacing the -A switch with -I causes the rules to be "inserted" into the first position of each chain, and thus they will be adhered to before anything else.  Also, after doing some further reading, it seemed to be helpful to turn off the tracking of the ipv6 packets as well.  I have added the following to my DD-WRT iptables:

iptables -t nat -I POSTROUTING --proto ! 41 -o vlan1 -j MASQUERADE
iptables -t nat -I PREROUTING -i vlan1 -p 41 -j DNAT --to $ipv4b
iptables -I FORWARD -s $ipv4a -i vlan1 -j ACCEPT

It still might not work for everyone, but it is working for me.  Thanks for your guidance!  Now, on to radvd...

Phil

[jimb]

That looks like it should work, presuming that you're only natting a single public IP, and that there are no rules ahead of it in either chain which would match before those.  Especially DROP rules.  

For the benefit of our readers, this seemed to be the trick.  Replacing the -A switch with -I causes the rules to be "inserted" into the first position of each chain, and thus they will be adhered to before anything else.  Also, after doing some further reading, it seemed to be helpful to turn off the tracking of the ipv6 packets as well.  I have added the following to my DD-WRT iptables:

iptables -t nat -I POSTROUTING --proto ! 41 -o vlan1 -j MASQUERADE
iptables -t nat -I PREROUTING -i vlan1 -p 41 -j DNAT --to $ipv4b
iptables -I FORWARD -s $ipv4a -i vlan1 -j ACCEPT

It still might not work for everyone, but it is working for me.  Thanks for your guidance!  Now, on to radvd...

Phil

You probably didn't need to exclude proto 41 from masquerading.  As long as the DNAT is in there and the ACCEPT is in the FORWARD chain before any rule which would drop the traffic, it should have worked.  I typically put rules like that ahead of the normal match rule in the FORWARD chain for established/related traffic so that the counters shown with the -v flag give me some stats on the traffic for that protocol.

Also FYI, if you didn't know, you can also use a number after -I or --insert to place a rule in front of the numbered line anywhere in the chain.  You can list the line numbers by adding --line to "iptables --list".  For example, if you wanted to put something in front of rule number 3, you could do "iptables -I FORWARD 3 <rule>".

[feld]

I just ran into this same issue. My tunnel endpoint is an OpenWRT router.

I think we should sticky this as it's a pretty important issue that can arise.