Tunnel stops working after my DSL goes down and back up with same v4

[jollino]

Hello all,
I've been using he.net's tunnel for a few months using OS X as a v6 gateway for my network. I have however repeatly stumbled on a strange problem. Whenever my dsl goes down and comes back up, even if my IP stays the same, the tunnel will stop working for a long while.

Even if I clean up the gif0 interface and the routing table and re-add everything, or even if I reboot the Mac entirely, the tunnel will just refuse to start working again. After a few hours (?) it will finally be back, but I can't really understand why. Is there some sort of time-out on the server side of the tunnel?

I don't think this is strictly related to OS X as I had the same problem when using FreeBSD as a gateway (hence my posting on the general subforum.)

I have even tried to change the client v4 endpoint on the site to something else, and then back to my IP, but to no avail.

Essentially, the only way to make it quicker is to keep my dsl down until my ISP assigns my previous IPv4 to someone else so I get a fresh one, and then change it on tunnelbroker.net and reconfigure everything.

Any hints to avoid this would be greatly appreciated!

Thanks in advance. :)

[Azendale]

I had the same problem and finally found out that I was using the same address as the tunnelbroker side of the tunnel (2001:470:a29f::1) instead of the address assigned for my end of the tunnel (2001:470:a:29f::2). I don't know how I made that mistake, and I'm amazed my tunnel worked at all. Changing the address for my end of the tunnel to what it should be (2001:470:a:29f::2) fixed the problem.

It's not necessarily what's causing your problem, but it's probably worth checking.

[jollino]

Hmm no, I did make some mistakes with the addresses at the very beginnning, but now everything's fine:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        tunnel inet 192.168.0.6 --> 216.66.80.98
        inet6 fe80::217:f2ff:fed9:eb5e%gif0 prefixlen 64 scopeid 0x2
        inet6 2001:470:25:2ad::2 --> 2001:470:25:2ad::1 prefixlen 128
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether 00:17:f2:d9:eb:5e
        inet6 fe80::217:f2ff:fed9:eb5e%en0 prefixlen 64 scopeid 0x4
        inet 192.168.0.6 netmask 0xffffff00 broadcast 192.168.0.255
        inet6 2001:470:26:2ad::1984 prefixlen 64
        media: autoselect (100baseTX <full-duplex,flow-control>)
        status: active

It may very well a problem with my router, anyway... its v6 support is non-existent, in that it just lets it go without doing anything about it. Given that even rebooting my gateway machine doesn't fix it, it may be that the router simply "chokes" when something like that happens. Next time it does, I'll reboot the router and see how it goes. :)

[donbushway]

This line is incorrect, tho it may not be causing your problem.

inet6 2001:470:25:2ad::2 --> 2001:470:25:2ad::1 prefixlen 128
It should be
inet6 2001:470:25:2ad::2 --> 2001:470:25:2ad::1 prefixlen 64

/64 is the smallest subnet allowed and every tunnel has its own block of addresses.

[jollino]

Thank you very much for pointing that out, I must have made a mess when creating my boot script. :)
However, in my experience, it doesn't affect how the tunnel works. Even with the prefixlen of the tunnel on the gif0 interface set to 128, I've been able to assign addresses within the whole /64 (and, actually, within the /48 I was also assigned.)
In any case, thanks again for noticing it! :)

[broquea]

BSDs wanted prefixlen 128 when bringing up their interfaces. At least FreeBSD <= 7.2 complains noisily about trying to use a /64.

[cholzhauer]

I've had problems with gif0 and freebsd. This is my config on a functioning freebsd system  (from /etc/rc.conf)

Code Select Expand



gateway_enable="YES"
gif_interfaces="gif1"
gifconfig_gif1="12.199.185.10 209.51.181.2"
hostname="ipv6router.sscorp.com"
ifconfig_nfe0="inet 12.199.185.10  netmask 255.255.255.0"
ipv6_defaultrouter="-interface gif1"
ipv6_enable="YES"
ipv6_gateway_enable="YES"
ipv6_ifconfig_gif1="2001:470:1f10:2aa::2/64"
ipv6_network_interfaces="nfe0 gif1 lo0"
ipv6_prefix_nfe0="2001:470:c27d:d000"


[bpier]

Thank you; I've been experiencing a similar situation when my router reboots (WRT54G-Tomato).  The router logs indicate protocol 41 being passed; the network setup looks good on my system (Linux-2.6.35); DNS searches for AAAA records work fine; no response in the tunnel (ping6 to any IPv6 address).
I've also checked the end-points by pinging the tunnel end (IPv4) and my own from another remote site; both work fine.

Similarly, after a few, without any reset to the networking on my system, the tunnel starts working again; I usually notice when I get RSS feed through Google Reader on an IPv6 addr.

It's as if the lights are on, but nobody's home .... then all of sudden someone is home!

[timbaldwin]

What sort of NAT (gateway) do you have?

I suspect incoming 6in4 packets are creating a useless mapping in your NAT, resulting in outgoing packets being dropped by the NAT. When your IPv4 address changes outgoing packets have a chance create a mapping first.

I can reproduce this in Linux 2.6.37.

I suggest you create an explicit mapping in your NAT, often this requires using the "DMZ" option which forwards everything, or if you have access to a Linux command line you can use something like:

Code Select Expand

iptables -A PREROUTING -p ipv6 -i <in interface> -j DNAT --to-destination <local IPv4>

[jollino]

What sort of NAT (gateway) do you have?

I suspect incoming 6in4 packets are creating a useless mapping in your NAT, resulting in outgoing packets being dropped by the NAT. When your IPv4 address changes outgoing packets have a chance create a mapping first.

I'm using a Netgear DG834G v4. It may be what you say, but this also happens when my connection goes down and comes back up quickly enough that my ISP reassigns the same v4 I had before. In fact, it just happened now and it was as I had theorized: it's the router that gets somewhat confused "internally."
I power-cycled it and it started working again without me doing absolutely anything on the gateway machine (and it once again re-used the same v4 as before, incidentally.)

I cannot run the iptables command you suggested, because the router has no explicit knowledge of ipv6. It just lets proto41 traffic pass through — something that the newer revision of my same router does not, my cousin eventually gave up —, and I'd rather not use DMZ.

Moreover, I really don't think it would help much. This router is getting old and sometimes crashes randomly, refusing to even respong to pings over the LAN. I'd replace it, but I'm trying to make it last until something cheap with explicit v6 support comes along. Strangely enough, v6 routers are relatively easy to find, but v6-capable routers with dsl modems built-in are impossible to find. I have no idea why.

[bpier]

Has anyone else come across this problem and found a resolution?  It's biting me again -- the tunnel gets interrupted by a router reset or cable service interrupt and then the tunnel will not function for several hours, but "magically" restarts without any configuration changes either on my tunnel end or my router!

Thank you; I've been experiencing a similar situation when my router reboots (WRT54G-Tomato).  The router logs indicate protocol 41 being passed; the network setup looks good on my system (Linux-2.6.35); DNS searches for AAAA records work fine; no response in the tunnel (ping6 to any IPv6 address).
I've also checked the end-points by pinging the tunnel end (IPv4) and my own from another remote site; both work fine.

Similarly, after a few hours, without any reset to the networking on my system, the tunnel starts working again; I usually notice when I get RSS feed through Google Reader on an IPv6 addr.

It's as if the lights are on, but nobody's home .... then all of sudden someone is home!