Routing problems

elventear · May 01, 2009, 12:39:41 PM

Hello,

I have configured my OpenWRT router running a Kamikaze SVN trunk build to use HE's IPv6 service. The problem that I am noticing is that the connection from my LAN dies suddenly (It doesn't route anymore via IPv6) and the odd thing is that if I execute a traceroute6 to a site, then the connection comes back up. Example:

Quote
elventear@utumno:~$ ping6 ipv6.google.com
PING ipv6.google.com(yo-in-x68.google.com) 56 data bytes
^C
--- ipv6.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

elventear@utumno:~$ traceroute6 ipv6.google.com
traceroute to ipv6.l.google.com (2001:4860:0:2001::68) from 2001:470:1f10:545:224:8cff:fe15:154d, 30 hops max, 24 byte packets
1 elventear-1.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:545::1) 4.599 ms 1.26 ms 0.855 ms
^C
elventear@utumno:~$ ping6 ipv6.google.com
PING ipv6.google.com(yo-in-x68.google.com) 56 data bytes
64 bytes from yo-in-x68.google.com: icmp_seq=1 ttl=58 time=93.5 ms
64 bytes from yo-in-x68.google.com: icmp_seq=2 ttl=58 time=91.5 ms
^C
--- ipv6.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 91.574/92.548/93.523/1.020 ms
elventear@utumno:~$

After a while the connection dies again.

From within the router, the connection is flawless.

The instructions that I followed to configure my OpenWRT are the ones contained in this thread:

http://forum.openwrt.org/viewtopic.php?id=19603

One thing that strikes me as odd, is that they say I should use the IPv6 address of the server endpoint as the IPv6 address of the lan bridge. This is not something that I would've done intuitively, but it seems to work and when I tried an additional variation (adding) a new IPv6 address (xxxx::3/64) it didn't seem to work.

On the router:

Quote
he-ipv6 Link encap:IPv6-in-IPv4
inet6 addr: 2001:470:1f10:545::2/64 Scope:Global
inet6 addr: fe80::d8f3:b0a0/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1434 Metric:1
RX packets:6405 errors:0 dropped:0 overruns:0 frame:0
TX packets:5866 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2200821 (2.0 MiB) TX bytes:518534 (506.3 KiB)

br-lan Link encap:Ethernet HWaddr 00:0F:66:8E:70:FC
inet addr:192.168.144.1 Bcast:192.168.144.255 Mask:255.255.255.0
inet6 addr: 2001:470:1f10:545::1/64 Scope:Global
inet6 addr: fe80::20f:66ff:fe8e:70fc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:394562 errors:0 dropped:0 overruns:0 frame:0
TX packets:538051 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:173925746 (165.8 MiB) TX bytes:204952500 (195.4 MiB)

Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
2001:470:1f10:545::/64 :: U 256 0 0 br-lan
2001:470:1f10:545::/64 :: U 256 267 0 he-ipv6
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth0.0
fe80::/64 :: U 256 0 0 eth0.1
fe80::/64 :: U 256 0 0 br-lan
fe80::/64 :: U 256 0 0 wlan0
fe80::/64 :: U 256 0 0 he-ipv6
::/0 2001:470:1f10:545::1 UG 1024 5752 0 he-ipv6
::1/128 :: U 0 0 1 lo
2001:470:1f10:545::/128 :: U 0 0 1 lo
2001:470:1f10:545::/128 :: U 0 0 1 lo
2001:470:1f10:545::1/128 :: U 0 128 1 lo
2001:470:1f10:545::2/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::/128 :: U 0 0 1 lo
fe80::d8f3:b0a0/128 :: U 0 0 1 lo
fe80::20f:66ff:fe8e:70fc/128 :: U 0 0 1 lo
fe80::20f:66ff:fe8e:70fc/128 :: U 0 0 1 lo
fe80::20f:66ff:fe8e:70fc/128 :: U 0 0 1 lo
fe80::20f:66ff:fe8e:70fc/128 :: U 0 166 1 lo
fe80::20f:66ff:fe8e:70fe/128 :: U 0 0 1 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth0.0
ff00::/8 :: U 256 0 0 eth0.1
ff00::/8 :: U 256 0 0 br-lan
ff00::/8 :: U 256 0 0 wlan0
ff00::/8 :: U 256 0 0 he-ipv6

On a LAN client:

Quote
eth0 Link encap:Ethernet HWaddr 00:24:8c:15:15:4d
inet addr:192.168.144.4 Bcast:192.168.144.255 Mask:255.255.255.0
inet6 addr: 2001:470:1f10:545:224:8cff:fe15:154d/64 Scope:Global
inet6 addr: fe80::224:8cff:fe15:154d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:863401 errors:0 dropped:0 overruns:0 frame:0
TX packets:485447 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:213709389 (213.7 MB) TX bytes:211424557 (211.4 MB)
Interrupt:251 Base address:0x2000

Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2001:470:1f10:545::/64 :: UAe 256 0 130 eth0
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 virbr0
::/0 fe80::20f:66ff:fe8e:70fc UGDAe 1024 0 245 eth0
::/0 :: !n -1 1 424 lo
::1/128 :: Un 0 1 142 lo
2001:470:1f10:545:224:8cff:fe15:154d/128 :: Un 0 1 2430 lo
fe80::224:8cff:fe15:154d/128 :: Un 0 1 616 lo
fe80::9ce9:91ff:fe1a:5ec3/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 virbr0
::/0 :: !n -1 1 424 lo
elventear@utumno:~$

Any ideas what could be wrong in my configuration? Or what to try to diagnose the problem?

musashix90 · May 19, 2009, 11:58:51 PM

I am having the *exact* same problem. Did you ever get it working?

broquea · May 20, 2009, 12:50:30 AM

Stop using the tunnel's ptp /64 for your LAN and use the routed /64 we gave you which would be either:

Routed /48: 2001:470:c1c3::/48
Routed /64: 2001:470:1f11:545::/64

As it seems you even allocated yourself a /48

elventear · May 20, 2009, 07:07:42 AM

Thanks for the help. I have the tunnel up and running.

Now I am experiencing another issue. I have two different sites that are running an HE Tunnel. The one of the tunnels seems to have the problem of going down after not being used for a while. I cannot reach the machines on that network and I have to login via IPv4, generate some IPv6 activity (like ping6 for instance) and then everything will be back.

Is this something known? Is this problem related to the sit tunnel? Or maybe the autoconfiguration in radvd?

kristiankrohn · May 20, 2009, 08:16:23 AM

My guess would be that you have a stateful firewall on your tunnel endpoint.

Make sure that you allow incoming protocol 41 connections from the HE tunnel endpoint on your IPv4 firewall.

elventear · May 20, 2009, 08:46:13 AM

I am using Linux. So you are saying the conntrack feature in iptables is marking the connection as stale or something like that?

I have this on my openwrt box:

iptables -A INPUT -p 41 -i $WAN -j ACCEPT
iptables -t nat -D POSTROUTING -o $WAN -j MASQUERADE
iptables -t nat -A POSTROUTING --protocol ! 41 -o $WAN -j MASQUERADE

Is this enough?

kristiankrohn · May 20, 2009, 09:13:28 AM

The explicit accepting of incoming protocol 41 connections on the WAN interface should be enough.
The exclusion of protocol 41 from masquerading should not be necessary -- but can't hurt either.

(I assume the openwrt box is the tunnel endpoint and I further assume that your INPUT rules have something like "-m state --state ESTABLISHED,RELATED -j ACCEPT" somewhere.)

News:

Routing problems

elventear

musashix90

broquea

elventear

kristiankrohn

elventear

kristiankrohn