dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5498
share rss forum feed

dopamine5ht

join:2011-04-21

new firmware 6.9.1.42-enh.tm he.net tunnel no longer works.

6.9.1.42-enh.tm

Althought the cascading router option might be interesting for my friend jeff, and several other improvements.

I seem to have lost my he.net tunnel that I have been using to play with IPV6. Which coincided on the day my firmware upgraded.

It looks like this firmware is ipv6 capable but is not turned on yet.

What was cool about he.net is I had reverse dns support.

Whatever came with this update is blocking my tunnel as well :-(. Might have to try sixxs or something. But what I had worked so well. so I am bummed.

Let me know if anyone else who is using he.net and if they lost there tunnel too.

JeStEr26

join:2002-08-25
Miami, FL
my HE tunnel is also not working after my 3801 updated to 6.9.1.42 today:(


bdavenport

join:2004-09-20
Raleigh, NC
reply to dopamine5ht
Looks like I got the new firmware last night and my tunnel ability went poof too.

To which server is your tunnel terminated at? How is it terminated? I am going to spend my afternoon off figuring it out (hopefully). If I cant, I am gonna do my best to raise a stink.


freakout9903
Premium
join:2001-04-19
Gastonia, NC
reply to dopamine5ht
your ip address changed maybe?

dopamine5ht

join:2011-04-21
IP didn't change on any level. I have statics, and even the single so called dynamic ip didn't change. Something in the firmware is blocking it, I didn't modify any networking configuration files in months so. Its not that either. It coincided with the firmware update, exactly. before happy transfers, after the firmware update it stalled.

dopamine5ht

join:2011-04-21

1 edit
reply to bdavenport
Oh heck here is the actually config entry in /etc/network/interfaces under ubuntu.

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
endpoint 209.51.xxx.x
address 2001:xxxxxxxxxxxxxx
netmask 64
ttl 64
local 75.56.235.57
gateway 2001:xxxxxxxxxxxxx

I haven't changed this in long long time.


bdavenport

join:2004-09-20
Raleigh, NC
Like the few so far, have not changed anything on my setup for the entire time I have had uverse.

I could not visually spot anything that screamed you need this checkbox unchecked. So for fun I did a full modem reset and a reset of the router configuration. Still no joy.


freakout9903
Premium
join:2001-04-19
Gastonia, NC
reply to dopamine5ht
6in4 static tunnel works fine on a tomato based router , and i think i have the cfg for a linux setup if you can't get the he.net tunnel working for whatever reason.

dopamine5ht

join:2011-04-21
I would like to see this configuration.. and your running 6.9.1.42-enh.tm ?

It is possible I have to compensate for something that changed in firmware


bdavenport

join:2004-09-20
Raleigh, NC
I too would like to know if you are on the 6.9.x firmware. If so also interested in your configuration.

The only way I could get it working was to subscribe to a VPN provider (which I have been meaning to do for a while now).


freakout9903
Premium
join:2001-04-19
Gastonia, NC
I take it back, got the upgrade and smashing my head against the keyboard...found this in my link tree.

\-->ip6rd0 is DISABLED
\-->bridge2 is NOT_PROV
 
pm_bb_if_ip6rd 
Dependency State: CLIMBING 
Link State: DOWN 
Link Detail: DISABLED 
Timeout: 0
File Descriptor flags: 00000000
Reported error string: 
File Descriptor State: Count: 3 Active: 0 Events: 0
 
Module State Change History:
  To State DOWN at 00:02:15.48
 
Enabled: No, Configured: Yes
ip6rd0 state: DOWN parent dev: bridge1
flags:  SHARED,UNTRUSTED,DEF_ROUTE
llink: 0, link type: 2
IP Address: 99.144.138.XX
Configured: 99.144.138.XX
MAC Address: 00:00:00:00:00:00
IP4 Source address: 0.0.0.0
 
6rd parameters:
6rd Prefix: 2001:d000::
6rd Prefix length: 32
6rd IPv4 mask length: 0
6rd Delegated prefix: 2001:d000:6390:XXXX::
6rd Delegated prefix length: 64
6rd Delegated prefix mask: ffff:ffff:ffff:ffff::
6rd Delegated netmask: ffff:ffff::
6rd HA gateway: 2001:d000::1
BRIP4: 0.0.0.0, GWIP4: 0.0.0.0
ipsecondary: 0, bridging: 0, generation:0
all_to_br: 1
allow class c br: Active: 0  Config: 0
MTU: 1472
MTU artificially limited to: 1472 from 0 for latency
 

tried playing around with the above prefix and still no go. Wonder if a tech can enable the setting or if there is some hidden page in this firmware to do so....ill keep playing.


bdavenport

join:2004-09-20
Raleigh, NC
I tried for four hours playing with the phone support on the 1st. Your lucky if they understand that there is a new firmware being pushed out, most just go wtf is firmware.


freakout9903
Premium
join:2001-04-19
Gastonia, NC
I called to report the problem and got referred to their paid connectech service because ipv6 is beyond their level of expertise?(granted I did use some big words like: Linux,VPN,6Rd, and tunnel)


foulacy

@sbcglobal.net
So i've been talking to them for the past 7 hours, He is sending me a replacement rg with the ipv6 device enabled on it, not disabled.


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:6
Reviews:
·AT&T U-Verse
·ViaTalk
That makes no sense as you are tunneling IPv6 inside of IPv4 packets going to he.net. There should be no difference whether the RG has IPv6 enabled or not. The key is what security or filter component is triggering and blocking the tunnel traffic. It is a simple GRE tunnel, so unless the filters don't like something about GRE, they must be doing some form of payload inspection that is triggering a block rule.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


mackey
Premium
join:2007-08-20
kudos:14
said by rolande:

It is a simple GRE tunnel

Actually he.net is SIT not GRE. Assuming the 3801 does the same thing as my NVG510, in addition to the 6rd tunnel, there's a catch-all "sit0: ipv6/ip remote any local any ttl 64 nopmtudisc" tunnel as well. My guess is the RG is snatching up the packets before they have a chance to get forwarded on.

/M


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:6
Reviews:
·AT&T U-Verse
·ViaTalk
said by mackey:

Actually he.net is SIT not GRE.

Actually if you want to split hairs, it is 6in4 encapsulation using IP protocol 41. It is just another iteration of GRE using a reserved protocol number to specifically identify that it is IPv6 traffic that is encapsulated. On a Cisco router you use tunnel mode ipv6ip. SIT just appears to be the more open/generic acronym for IP protocol 41 encapsulation.

The point is that with simple IPv4 tunnel encapsulation, there should be no reason for the RG not to pass the traffic, unless it has some filter trigger for certain IP protocols (41) that are not on a defined whitelist of some sort. The RG should not be unencapsulating the traffic either and evaluating the IPv6 payload.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


freakout9903
Premium
join:2001-04-19
Gastonia, NC
Well either way its doing some sort of filtering since the update, I tested my setup right before and right after the upgrade.


mackey
Premium
join:2007-08-20
kudos:14
reply to rolande
said by rolande:

The RG should not be unencapsulating the traffic either and evaluating the IPv6 payload.

We can argue about what it should or shouldn't be doing all day; I'm just telling you what mine is doing.

/M


mackey
Premium
join:2007-08-20
kudos:14
reply to freakout9903
said by freakout9903:

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


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:6
Reviews:
·AT&T U-Verse
·ViaTalk
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.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


mackey
Premium
join:2007-08-20
kudos:14
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

dopamine5ht

join:2011-04-21
reply to rolande
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.


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:6
Reviews:
·AT&T U-Verse
·ViaTalk
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.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


bersl2

@sbcglobal.net
reply to dopamine5ht
Started a live chat with AT&T tech support for fun. Basically, I'm having the grunt the guy scheduled bring a 3600, since it presumably still has the 6.3 firmware. Will try that out and see what happens.


bersl2

@sbcglobal.net

1 recommendation

The guy who came by did not have the 3600 anymore, and the 5031NV also had issues, but the 3800 he had was still on 6.3.7.50-plus.tm and did not upgrade (at least not yet).

I can confirm that the issue is the newer firmware. This 3800 is working perfectly.


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:6
Reviews:
·AT&T U-Verse
·ViaTalk
So, I'm not losing my mind? The new firmware is killing 6rd tunnels with whatever unnecessary advanced feature they've added? I presume I can't open a ticket and get downgraded and a bug fix is probably many months to a year away. That really sucks. I upgraded my router specifically to run 6rd and now it is broke. Thanks for nothing, AT&T.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


bersl2

@sbcglobal.net
Well, let's be specific here: what broke is the ability to use IP protocol 41 by anyone except AT&T. So you'd be able to use AT&T's 6rd, once they finally turned it on. Which could be a week from now or a year. By their logic, once they go to Carrier-Grade NAT, this will all be thoroughly broken anyway, so why bother waiting?

The tech told me that they're already receiving shipments of a new device to replace the 3801. Not sure how well it will handle this stuff, but I imagine it's not entirely outside of the range of possibility that the older devices will receive one more firmware update, turning the AT&T 6rd (and CGN) on, for better or worse.

I might agree to a compromise with myself and get a business account and static IPv4 address, to try to avoid this kind of foolishness if they're going to pretend that a /64 is good enough for everybody. But man, AT&T has left a pretty awful taste, so I'm not even sure I'm going to consider them for that.


rolande
Certifiable
Premium,Mod
join:2002-05-24
Dallas, TX
kudos:6
Reviews:
·AT&T U-Verse
·ViaTalk
said by bersl2 :

I might agree to a compromise with myself and get a business account and static IPv4 address, to try to avoid this kind of foolishness if they're going to pretend that a /64 is good enough for everybody.


But they aren't just giving a /64. You actually get a /60 with each public IP you are assigned. That is 16 /64's that you can assign however you would like to your local LAN segments, if you can still actually establish a 6rd tunnel to the AT&T border relay anymore.
--
Scott, CCIE #14618 Routing & Switching
»rolande.wordpress.com/


David
I start new work on
Premium,VIP
join:2002-05-30
Granite City, IL
kudos:101
reply to dopamine5ht
As far as I last knew this was on the known firmware issues desk with no eta as they started working on the problem when I turned it in. I haven't heard back one way or the other but it will be as least another 3-5 days before I am back.