You said it seems to depend on packet size...can you just set the MTU to a value that works and leave it?

Hi all,

I'm using HE tunnelbroker since 2016 without issue, and since 1 month or so, it stopped working.
Since then, the linux box (a Synology NAS) has been updated, the ISP router might have been updated as well (don't know and can't know...) so it's difficult to know why.

here is more info :
- the setup is : a synology NAS with a private IPV4 address and the ISP router with a static public IPV4 address
- all commands (scripted, so they didn't changed) to bring the interface up with ips,... are successful
- ping to server IPV4 address is OK
- ping to client IPV6 address is OK
- ping to server IPV4 address is OK
- when running a IPv6 Portscan from tunnelbroker.net website, the results are OK and ports that should be opened are opened
- ping to a IPV6 website (like www.kame.net, ...) is sometime ok sometime not ok and might depend on packets size
- curl to a IPV6 fails anytime.

what I've tried :
- setup the IPV6 on another Linux box (a VM on my laptop) : same behavior
- delete tunnel and create a new one : same
- tcpdump the IPV6 traffic while pinging and curling : seeing a lot of output packet but only a few for echo request, and none for http(s) calls and so a lot of retransmission

it seems tunnel is OK, and that router is forwarding IP protocol 41 as the portscan is ok, but can't understand why outgoing traffic (except ping) is failing...

Any ideas ?
what else can I do to narrow down culprit ?

thanks a lot

Ah sorry for the confusion, I merely mentioned IPSEC on the IPv4 addresses as an indication that other services are working with both external addresses, just not 6to4 tunneling

I assume that your multi-wan device has different IPv4 addresses on the wan interfaces.  However, your use of IPSEC may interfere.  That's not what the HE tunnels use, and if your IPSEC configuration requires authentication or encapsulation, that could reject the tunnelled packets using protocol 4 (IPv4 in IPv4).

I have a question regarding having multiple tunnels with different source IPs on the same device. My router supports, and I am using multi-wan for my IPv4 connections, IPSEC-GRE, etc but I cannot get two HE tunnels to work at the same time on the device. Is this supported, known to work, or am I barking up the wrong tree?

I have changed the home router couple of days ago and I have a domain on he.net so I'm trying to get dynamic DNS to work.

But after over 10-20 retry's i have seen that tunnelbroker gives a abuse status (abuse @ 2016-08-03 02:05:12).

How can I fix this?

DynDNS_FritzBox_To Tunnel Broker:

Update-URL: https://ipv4.tunnelbroker.net/nic/update?hostname=451585  ,......,Tunnel ID
Domain: he.net
Username: ibh     ,......,Username Tunnelbroker Login
Password: RWoghAb7kIaY3n3D  ,......,Key Dynamic DNS Record

No ping response, it respolves to an IPv6 though.

But then today I find I can't connect through my tunnel to anywhere that is IPV6.

ping -6 www.he.net (timeout)
ping -6 www.google.com (timeout)
ping -6 [my upstream ipv6] 12-13ms.

don't know any further points to connect to.

I'm connecting via 66.220.18.42

edit:
my address is 'd3x0r.org' which resolves to 2001:470:d:579::4  I can ping it from my windows box (intenral network) but cannot from the world side... (found an online ping utility, that can ping www.google.com (fails for me) and can't ping d3x0r.org (which works for me).   it has been working until today.

I think you really need to take a look at the structure of the "ip6.arpa" zone.

When I create a /56 zone on HE, it's treating it as a /64 because it's separating by the colons.  The subnet is
x:x:x:6900::/56, but the web interface will only allow me to assign addresses that start with x:x:x:6900: and not 6901 through 69ff.

My thinking for a workaround is that a /56 delegation should automatically include all of the smaller included subnets, so I could just create the /64's on HE.  I can try it, I just wanted to verify before I bother my ISP with a change request.

I tried it and it timed out for me too (twice).