AT&T U-verse → Re: new firmware 6.9.1.42-enh.tm he.net tunnel no longer works.

Well either way its doing some sort of filtering since the update, I tested my setup right before and right after the upgrade.

Like I said, I don't think it's filtering per se, but rather it's tunnel-aware and attempting (and failing) to unwrap the packets itself.

/M

I wonder if it is an order of operations issue on the return traffic with NAT. The RG wants to terminate the tunnel because it sees the IPv4 destination as itself. In other words, the tunnel process on the RG is executed before NAT on the ingress traffic, thus breaking it, once the traffic is unencapsulated and the IPv6 packets have nowhere to forward. This sounds like a highly likely scenario. The RG has now become aware of 6in4 tunneling and does not support NATing 6in4 tunnels or at least was not properly programmed to support it.

Yeah, that sounds like pretty much it.

On the bright side it looks like T is about to deploy 6rd IPv6 to VDSL users.

/M

Changing to Cacade router didn't help either.

RG -> (eth0)->[Linux Router][isolated switch][5 static machines]

hping made it to my linux router and stalled. so There is so there is something in its code definitely be it nat or something else messing with it.

Well just hope for IPV6 in year or try a tunnel broker with a different mecanism. I am not holding my breath on reverse delegation, but you never know if at will suprise ya.

I've been persistently trying to get a 6rd tunnel working to AT&T from my Cisco 3825 sitting behind my 3801 without much success yet. I finally figured out my issue with setting up DMZ+ mode for my router this morning which is at least another step towards resolving this. My tunnel shows that it is Up Up and I am getting the proper AT&T IPv6 prefix assigned based on the publicly assigned IP now. My router is setup for EUI-64 on my internal network and I can ping6 my router's Global Unicast address from hosts on my network. I just can't seem to get any response from public IPv6 hosts sourced from my router or my clients. I ran a reverse tracepath from outside and got as far as the gateway at AT&T. When I ping6 from outside I just get timeouts. So that indicates that AT&T has a route to me. So there is something else that is causing this tunneled traffic to die. I can see my packets destined externally hitting the tunnel, as the counters are increasing.

I disabled all of my security configuration on my interfaces just to be sure it wasn't something stupid on my end blocking the traffic. Still no luck. :/ If I can't get this to work soon, I'm going to have to insert a port mirror between my router and RG to capture this traffic and figure out what is breaking. The only thing I can think of, at this point, is that the return traffic is sinking on the 3801 somehow. But I would think it would kill the tunnel completely and not just drop certain traffic.