Deperately failing to establish 6to4 tunnel with Mikrotik or Checkpoint Gaia

[astnwt]

Hej guys,

I'm trying to migrate from SixXS, but it seems that somethings wrong while being so subtle that I don't get the reason:

First I tried to terminate the tunnel on a Mikrotik device, using the configuration example provided on the tunnelbroker web interface. I opened iptables for protocol 41, later opened iptables for *everything* for debuggings sake, but the tunnel is not correctly established.

From CLI I can ping my local IPv6 P2P address (yeah, why not :-):

Code Select Expand

admin@stargate] > ping 2001:470:1f1a:1d1::2
HOST                                     SIZE TTL TIME  STATUS
2001:470:1f1a:1d1::2                       56  64 0ms   echo reply
2001:470:1f1a:1d1::2                       56  64 0ms   echo reply

But pinging the other side of the tunnel fails:

Code Select Expand

[admin@stargate] > ping 2001:470:1f1a:1d1::1
HOST                                     SIZE TTL TIME  STATUS
                                                        no route to host
                                                        no route to host

The same thing goes for trying to let the tunnel terminate on a Checkpoint Gaia,
which just "worked" with SixXs:

[Expert@scruffy:0]# ping6 2001:470:1f1a:1d1::2
PING 2001:470:1f1a:1d1::1(2001:470:1f1a:1d1::2) 56 data bytes
From 2001:470:1f1a:1d1::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:1f1a:1d1::2 icmp_seq=2 Destination unreachable: Address unreachable

On the Mikrotik router, even the dynamic route that was automatically created on the 6to4 interface (2001:470:1f1a:1d1::/64) is flagged as "unreachable".

I could really use a helping hand ..or .. brain .. :-)

[broquea]

Can you paste the commands you ran?
What does your routing table look like?

Also I appear to be able to ping your side of the tunnel:

Code Select Expand

~$ ping6 2001:470:1f1a:1d1::2
PING 2001:470:1f1a:1d1::2(2001:470:1f1a:1d1::2) 56 data bytes
64 bytes from 2001:470:1f1a:1d1::2: icmp_seq=1 ttl=50 time=178 ms
64 bytes from 2001:470:1f1a:1d1::2: icmp_seq=2 ttl=50 time=178 ms
64 bytes from 2001:470:1f1a:1d1::2: icmp_seq=3 ttl=50 time=178 ms
64 bytes from 2001:470:1f1a:1d1::2: icmp_seq=4 ttl=50 time=178 ms
64 bytes from 2001:470:1f1a:1d1::2: icmp_seq=5 ttl=50 time=178 ms
^C
--- 2001:470:1f1a:1d1::2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms


[astnwt]

I used the commands from the configuration maker on tunnelbroker.com - but I found something out due to your pings:

All my routes to IPv6 (into the SIT interface) are flagged as "unreachable" -
but as soon as someone pings me from outside (like you did) and traffic approaches
through the tunnel, the routes are flagged "reachable" again and routing kicks in.

smells like a damn bug, does it?

[astnwt]

Update: After 2 Minutes of inactivity ( inactivity in this case refers to "no packet approaching the tunnel from the remote side" ) the routes are flagged as unreachable and routing INTO the tunnel collapses. For those who are looking for a quick and dirty fix: Enable "Check Gateway: PING" and ping your end of the transport network from outside once. As soon as it goes up it stays up since the "Check Gateway" option sends ICMP requests to the far end of the tunnel and therefore provokes ICMP answers which keep the routing up and running.

Meanwhile I'll check with Mikrotik what is really happening there and will post any new insights here.

[broquea]

almost sounds like a conntrack issue behind nat