Connection breaks after a while

[adenis]

Hello,

I am on Mac OS X Mountain Lion (10.8) and I have setup a tunnel:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
   tunnel inet 192.168.20.2 --> 209.51.181.2
   inet6 fe80::ca2a:14ff:fe33:479c%gif0 prefixlen 64 scopeid 0x2
   inet6 2001:xxxx:1f11:xxxx::bad:cafe prefixlen 64
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
   ether c8:2a:14:33:47:9c
   inet6 fe80::ca2a:14ff:fe33:479c%en0 prefixlen 64 scopeid 0x4
   inet6 2001:xxxx:1f11:xxxx:ca2a:14ff:fe33:479c prefixlen 64 autoconf
   inet6 2001:xxxx:1f11:xxxx:c041:6254:50b0:62e0 prefixlen 64 autoconf temporary
   inet 192.168.20.2 netmask 0xffffff00 broadcast 192.168.20.255
   media: autoselect (1000baseT <full-duplex,flow-control>)
   status: active

The connection works for a while:
ping6 www.yahoo.com
PING6(56=40+8+8 bytes) 2001:xxxx:1f11:xxxx::bad:cafe --> 2001:4998:44:4::c:9102
16 bytes from 2001:4998:44:4::c:9102, icmp_seq=0 hlim=56 time=135.087 ms
16 bytes from 2001:4998:44:4::c:9102, icmp_seq=1 hlim=56 time=134.229 ms
16 bytes from 2001:4998:44:4::c:9102, icmp_seq=2 hlim=56 time=147.762 ms

And then it breaks:
ping6 www.yahoo.com
PING6(56=40+8+8 bytes) 2001:xxxx:1f11:xxxx:c041:6254:50b0:62e0 --> 2001:4998:f00d:1fe::3001
ping6: sendmsg: No route to host
ping6: wrote ds-any-fp3-real.wa1.b.yahoo.com 16 chars, ret=-1
ping6: sendmsg: No route to host

What gives? It seems to still be able to resolve the address but the ping fails.

Help!

adenis

[cholzhauer]

what are you using for a firewall?

[adenis]

No firewall, I know this is bad but I'll figure one thing at a time.

[cholzhauer]

Just curious because some firewalls interrupt the flow and "break" your tunnel

[broquea]

And by firewall he might have meant NAT appliance, since your Mac is using rfc1918 space. D-link? Netgear? There is a chance that it's conntrack is broken, however generally sourcing traffic out from behind it over the tunnel usually fixes that.

[adenis]

Turns out rtadvd was resetting my default route. I was experiencing the same issue as in this post:
http://www.tunnelbroker.net/forums/index.php?topic=1268.0
Thank you for your help.