1

I have an ipv6 tunnel that refuses to work until traffic goes outbound. if I turn the device on and ping in, I get no response until the second I start to ping out. if I then walk away for a few hours and try to ping in again, I'll get no response.

I'm using Debian Lenny and Hurricane Electric for my tunnel. I'm not even sure where to begin debugging this behavior because it's so unusual. I've used both of the Debian configs from http://www.tunnelbroker.net/forums/index.php?topic=18.0 and the configs from http://wiki.debian.org/DebianIPv6 and a variety of tweaks in between, but I still cannot get the device to persistently accept inbound traffic. there's no ip6tables, but I do have a variety of iptable rules. has anyone else experienced this kind of issue? what could I possibly do to debug or solve this?

edit: there's no NAT involved and it's all IPv4 Cisco infrastructure. I dont think there's any IPv6 between me, the switches and the router.

Improve this question

2 Answers 2

Reset to default
2

The real answer is given in the SixXS FAQ:

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

See that article for the full explanation.

Improve this answer
1
  • I eventually fixed this problem by using 'metric 1' on the interface up. however, I'm having issues with my server providing ipv6 to my laptop, so I'll play with this and see what happens. if you're interested, there's 2 questions related to it on serverfault, just check my profile.
    – neoice
    Nov 17, 2010 at 17:09
2

Without knowing more about your network design, I'm assuming your tunnel endpoint is on a device on your LAN, behind your internet router. I'm also assuming that device gets access to the internet via NATting on the router.

The likely cause of your inbound problem is the NAT table on the router. The router doesn't know how to route inbound v6 (protocol 41) traffic to the tunnel endpoint device. As soon as you send v6 traffic outbound through the tunnel an entry in the NAT table is created. This entry allows the router to also send inbound traffic back to the tunnel endpoint.

After a while without traffic, the router expires the entry and flushes it from its NAT table, therefore no inbound traffic is able to reach your tunnel endpoint any more.

How you solve this depends on your router's abilities.

  1. Either make a forwarding rule on your router, that forwards incoming 'protocol 41' traffic towards the tunnel endpoint device on your LAN. Most consumer routers can't do this.
  2. or make sure there is enough outbound traffic to trigger the router to never expire the NAT table entry. This can be accomplished by setting a cronjob to ping6 an outside server every 5 minutes.

An example for solution 2: Put the following in your crontab 

# Ping6 every 5 minutes to keep NAT open
*/5 * * * * ping6 -c1 -q www.sixxs.net 2>&1  >/dev/null
Improve this answer
2
  • I dont think there should be any NAT involved. I'm on a static IP, plugged into a switch in a datacenter. from the switch, it goes to a Cisco router and then off onto the web. I'd already considered a ping cronjob, but I prefer solutions to dirty hacks :/
    – neoice
    Oct 18, 2009 at 4:37
  • so I've been using this workaround for almost a month, although its not a real solution. hopefully someone else will stumble across this and solve it.
    – neoice
    Nov 13, 2009 at 11:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .