6in4 IPv6 Tunnel natively on Technicolor TG582n

[#1]

Thanks for writing that up Talat - I'm sure it'll be really useful for others wanting similar.

[#2]

Have been setting up a HE.Net tunnel and am wondering if the below section is actually necessary?

Quote from: Matt

Step 3 - Configure the firewall and NAT Allow all traffic through the firewall from the IPv4 tunnel originating address (given in the email): :expr add name=6in4ipv4 type=ip addr=212.113.147.150 :firewall rule add name 6in4 chain sink_fire action accept srcip 6in4ipv4 srcintf wan state enabled All traffic from the IPv4 Tunnel address needs to go to the router (again, use the IPv4 address given in the email as the foreign_addr value). In this command, the router automatically maps 0.0.0.1 to the first IPv4 address of the Internet interface. :nat tmpladd intf=Internet type=nat protocol=ipv6 outside_addr=0.0.0.1 inside_addr=0.0.0.1 foreign_addr=212.113.147.150

I've set up the tunnel without using any of the above commands and it all appears to be working fine. Have run a few port scans and the firewall seems to be blocking external connections to my IPv6 addresses so I'm not entirely sure what the point of the above commands would be. Is anyone better versed in the TG582N NAT/firewall and able to explain in simpler terms what the above commands should be doing?

[#3]

The point of those commands are to allow all traffic from the tunnel server through, so it can unwrap the 6in4 packet and loop it back through again to the IPv6 firewall. If you don't use them, like you have done, it will be a nightmare trying to allow any ports open for a IPv6 client.
One consequence would be that the Think Broadband ping monitor will not work on the IPv6 connection, as all unsolicited packet will be dropped.

[#4]

I thought it was something similar to that but I've successfully opened ports for one of my machines by simply adding the relevant rule to the firewall. It certainly wasn't a nightmare.
Edit: The Think Broadband ping monitor works fine to my router using the ipv6 address I gave it, altho I can't think it wouldn't work if I used the address He.net allocated to my end of the tunnel.

[#5]

I don't remember why these commands are needed I'm afraid!

[#6]

I think there's something odd in the instructions given on page 1 of this thread. The tunnel point-to-point address was assigned to the LAN interface and not the 6in4tunnel interface.
That is, rather than

:ip ipadd intf=LocalNetwork addr=2a00:14f0:e000:b7::2/128 addroute=enabled

I would do

:ip ipadd intf=6in4tunnel addr=2a00:14f0:e000:b7::2/128 addroute=enabled

Then you can give the /64 routed network to the LAN interface:

:ip ipadd intf=LocalNetwork addr=2a00:14f0:e000:80b7::1/64 addroute=enabled

I've tested this using Hurricane Electric (using my own account addresses of course) and it works fine.
It also works as originally shown, but it's a bit odd:
* the same point-to-point /64 is used on both the tunnel and LAN interfaces
* the router doesn't have an address for itself from the routed /64
* the only reason client devices can send traffic to the router is because they use link-local addresses for the next-hop.

[#7]

hi all.
this worked a treat for me and i'll continue to monitor speed and router stability.
one, maybe complicated, question...
is there a way to remove the ipv6 config from the router without doing a full reset?

[#8]

Quote from: lupinehorror

is there a way to remove the ipv6 config from the router without doing a full reset?

I suppose you could back track through the commands, a bit laborious to check for each delete command but should be reversible.
Another option is to save and manually edit the config file, removing all the IPv6 specific stuff.
Just out of interest, would you want to remove the IPv6 completely or only disable it temporarily? It's very easy to disable on auto configured devices, just one command will do it.

[#9]

very good of you to reply.
the option to disable (and re-enable) it easily would be preferable rather than completely remove it.  very new to the ipv6 game.
cheers.

[#10]

Ok then, here are the two commands to temporarily remove IPv6 and add it back:
Remove

ip rt6advd ifdetach intf=LocalNetwork

Add

ip rt6advd ifattach intf=LocalNetwork

What these do is basically stop the router from advertising the IPv6 connection info to your devices, hence stopping it from working. Devices will need a refresh of connection info after issuing the command (a reboot, lease renewal or toggle the connection will do).
I've used these commands easily previously to solve an annoying problem with Netflix apps, where IPv6 lists the USA catalogue but only plays through the IPv4 connection so you just get an error trying to play most things (apart from the items listed also in the UK catalogue).

[#11]

most helpful. i'm sure that will come in extremely handy.
already had issues with ipv6 as google thought someone was hacking my girlfriend's account...but it was her using her android tablet over my wi-fi. i said 'oh dear...give me some info on the IP and i'll look into it'. she started reading it out '2001:470:...' and i thought that looks familiar. sure enough it was mine. strange thing is she accessed her accounts with no problems and received the email a little while after.
anyway...i do appreciate your help.
cheers.
dick:quote

[#12]

Right, after 3 months of hell, an average of 15 disconnects a day (causing a low line profile), a new replacement router, hours on the phone to plusnet and multiple tickets at both plusnet and Chromium, I can safely say the following:
As reported by several others, the firmware in this router as sent out by plusnet (10.2.2.b) is buggy and will crash when tunnelling over ipv6 when downloading a file with Google Chrome *in some circumstances*.
The Chromium team are working through several network dumps I've sent them, so I'll let you know what comes back.
But clearly the problem lies with the router, and this isn't some custom firmware I'm loading, this is a brand new, fresh out of the box replacement router from Plusnet 3 weeks ago.

[#13]

Well it's not crashing for me. Pretty much all software (firmware in this case) have some sort of bug in them.
The circumstances you've reported as to when it crashes are very specific, a certain task (downloading) within one single program (Chrome) on a single platform (windows), with IPv6 tunnel thrown into the mix now. In my mind that really points the finger squarely in Google's domain.

[#14]

OK, I've had some feedback from Chromium and they suggested it might be the QUIC p

Quote from: RPMozley

In my mind that really points the finger squarely in Google's domain.

Seriously? You really reckon that a piece of hardware shouldn't be resilient to a series of bytes across a network?
OK, here's what we know since yesterday, in addition to the other stuff.
1: It never crashes when not tunnelling.
2: It's not to do with the QUIC protocol as Chromium bug hunters suggested.
3: It only happens after the router has had a cold restart after configuring the tunnelling. In other words, if you setup the tunnel, do saveall, then try a download, it's fine.
If you power off and power back on again, after this point it will crash.
Of course, as I expected no reply from the Thompson customer service email I sent 3 days ago...
Is anyone going to take responsibility for this?

[#15]

Hello!
You've definately stumbled upon a bug here! And I think it is with the Technicolor router, it shouldn't just crash!
Ideally we'd get a packet capture showing what's happening, and then we'd replicate it, but with a tunnel set up on the WAN interface, your computer won't be see the important traffic we're interested in. Are you on FTTC? If you are then there's a way around this.
Is anyone else having this problem? I've not seen it myself.
Have you tried starting from scratch with a factory reset? You shouldn't need to to be honest and it would probably be a pain to get everything set up again.
I'll see about getting the latest generic firmware from Technicolor which could help.
Cheers,
Matt