Problem with routing ipv6 tunnel at gateway router

[jamon]

I'm using a DDWRT router.  I previously had it working perfectly with 6to4.  I've tried switching to a registered tunnel with tunnelbroker.net and I'm having a routing issue now.

My gateway router always responds to pings over ipv6 on both 2001:470:1f11:5f4::1 (my routed addresses) and 2001:470:1f10:5f4::2 (my end of the tunnel).  I have radvd giving out ipv6 addresses to all my local machines with the prefix 2001:470:1f10:5f4::/64.  All of these local machines are always able to reach other via ipv6, and all are always able to reach the gateway at 2001:470:1f11:5f4::1 AND 2001:470:1f10:5f4::2.  Local machines can only reach the outside world if they have recently pinged the gateway at 2001:470:1f11:5f4::1.

The outside world can only reach local machines if those local machines have recently pinged the gateway, otherwise my router keeps routing it back to it's uplink.

 6  2002:d133:b502::1 (2002:d133:b502::1)  57.883 ms  58.526 ms  58.156 ms
 7  jamon-1-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:5f4::2)  73.423 ms  73.055 ms  72.479 ms
 8  2002:d133:b502::1 (2002:d133:b502::1)  78.694 ms  79.723 ms  77.163 ms
 9  jamon-1-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:5f4::2)  93.004 ms  93.584 ms *
10  2002:d133:b502::1 (2002:d133:b502::1)  103.721 ms  98.233 ms  99.735 ms
11  jamon-1-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:5f4::2)  113.637 ms  106.318 ms  106.018 ms
12  2002:d133:b502::1 (2002:d133:b502::1)  111.025 ms  119.726 ms  114.192 ms
13  jamon-1-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:5f4::2)  122.703 ms * *
14  2002:d133:b502::1 (2002:d133:b502::1)  132.54 ms e.a1ive.org (2001:470:1f11:5f4:222:43ff:fe63:d98d)  76.341 ms  75.638 ms

The infinite loop would have continued forever between 2002:d133:b502::1 and 2001:470:1f10:5f4::2 (my gateway's tunnel endpoint) except that I pinged the gateway from that machine while it was going, which caused the next hop to go straight to that machine (made it start working).

here's a pastebin with a bunch of information and another example of the problem using ping: http://pastebin.com/DqgQpH9K

Also important to note is that the problem is per-client.  Pinging the gateway only temporarily fixes the machine that pinged it, not all machines.

I'm aware there are some issues with conntrack/NAT gateways that also route ipv6 (that is the configuration i'm in), but unless I'm misunderstanding, I don't think that's my problem here.  Either way, here's my "nat" iptables configuration on the gateway:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       icmp --  0.0.0.0/0            24.217.91.124       to:192.168.1.1
DNAT       tcp  --  0.0.0.0/0            24.217.91.124       tcp dpt:58998 to:192.168.1.140:58998
DNAT       udp  --  0.0.0.0/0            24.217.91.124       udp dpt:58998 to:192.168.1.140:58998
DNAT       tcp  --  0.0.0.0/0            24.217.91.124       tcp dpt:6942 to:192.168.1.140:6942
DNAT       udp  --  0.0.0.0/0            24.217.91.124       udp dpt:6942 to:192.168.1.140:6942
DNAT       tcp  --  0.0.0.0/0            24.217.91.124       tcp dpt:8080 to:192.168.1.127:8080
DNAT       tcp  --  0.0.0.0/0            24.217.91.124       tcp dpt:22 to:192.168.1.127:22
DNAT       udp  --  0.0.0.0/0            24.217.91.124       udp dpt:22 to:192.168.1.127:22
DNAT       tcp  --  0.0.0.0/0            24.217.91.124       tcp dpt:80 to:192.168.1.127:80
TRIGGER    0    --  0.0.0.0/0            24.217.91.124       TRIGGER type:dnat match:0 relate:0

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       0    --  0.0.0.0/0            0.0.0.0/0           to:24.217.91.124
RETURN     0    --  0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast
MASQUERADE !41   --  192.168.1.0/24       192.168.1.0/24

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Does anyone have any ideas?

Thanks,
Jamon

[snarked]

What does your IPv6 routing table say?  I'm thinking that may be where the problem lies.

[jimb]

I'm using a DDWRT router.  I previously had it working perfectly with 6to4.  I've tried switching to a registered tunnel with tunnelbroker.net and I'm having a routing issue now.

My gateway router always responds to pings over ipv6 on both 2001:470:1f11:5f4::1 (my routed addresses) and 2001:470:1f10:5f4::2 (my end of the tunnel).  I have radvd giving out ipv6 addresses to all my local machines with the prefix 2001:470:1f10:5f4::/64.  All of these local machines are always able to reach other via ipv6, and all are always able to reach the gateway at 2001:470:1f11:5f4::1 AND 2001:470:1f10:5f4::2.  Local machines can only reach the outside world if they have recently pinged the gateway at 2001:470:1f11:5f4::1.

Was going to say that was your problem, but the pastebin shows that you're actually giving out the correct /64 to the LAN (1f11).


This route is wrong.  You shouldn't have a route for your routed /64 pointing through the tunnel interface:
2001:470:1f11:5f4::/64 via :: dev he-ipv6  metric 256  mtu 1480 advmss 1420

This is probably your main problem.

You also have two redundant default routes:
2000::/3 dev he-ipv6  metric 1  mtu 1480 advmss 1420
default dev he-ipv6  metric 1024  mtu 1480 advmss 1420

That shouldn't really cause any problems though, but is "messy".  Lose the 2000::/3 route.

Make sure ip forwarding is turned on in the linux box (most radvd startup scripts do that automagically since it won't run without this set anyway).

I think the bogus route is your big problem though.  Hose that.

Also, I'm not familiar with the TRIGGER target on iptables.  Not sure what you're doing there.  You may want to put a a DNAT in there for proto 41 pointing to your IPv6 router though, presuming that iptables box isn't your IPv6 router (I can't tell 'cause it looks like you've omitted the IPv4 addresses from the output).  Also, don't forget to put ACCEPT entries in the filter table for proto 41 traffic destined to your IPv6 router, either in the INPUT chain (if the tunnel terminates on the box itself) or the FORWARD chain (if it's behind it).  And of course allow proto 41 outbound too.

- Jim