Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  


Welcome to Hurricane Electric's forums!

Pages: [1] 2 3 ... 10
 on: March 24, 2020, 12:35:18 PM 
Started by JanGeiger - Last post by JanGeiger

It seems like there is some kind of issue with the hop posted above, since I can see the packet loss even in HEs LG:


Is there anything you guys can do about it?  :)

 on: March 24, 2020, 08:13:23 AM 
Started by JanGeiger - Last post by JanGeiger
Hi everyone  :)

I'm using a Ubiquiti Edge Router to connect to the Tunnelbroker Service. My uplink is a DSL PPPoE Connection. (MTU 1492)
Since a few weeks I have trouble connecting to via the tunnel. The connection is extremely slow. When I use nativ IPv4 everything is fine. Every other site I have tested yet is fine via the tunnel.

Does anyone have the same problem and/or knows how I can fix it?

Here is my full setup:
Tunnel MTU: 1472 (1500 - 8 (PPPoe) - 20 (SIT))
V6 MSS Clamping is set to 1412 (1472 - 60)

Edge Router:
edit interfaces tunnel tun0
set encapsulation sit
set local-ip
set remote-ip
set address 2001:470:1f0a:2b7::2/64
set description "HE.NET IPv6 Tunnel"
set mtu 1472
set protocols static interface-route6 ::/0 next-hop-interface tun0

So as it turns out I can even see major packet loss on the way to This makes me think it is not related to an issue regarding MTU/MSS size.
The first hop where the packet loss occurs is coloured red below.
Since this hop is the first one which belongs to Facebook, it seems the problem is on their side. However since this issue exists for me since about half a year now, I wonder if there is more to this....

Here is a trace:

traceroute to (2a03:2880:f11c:8083:face:b00c:0:25de) from 2001:470:1f0a:xxxx::2, port 33434, from port 55510, 30 hops max, 60 bytes packets
 1 (2001:470:1f0a:2b7::1)  16.731 ms  14.008 ms  13.978 ms
 2 (2001:470:0:69::1)  15.000 ms  14.753 ms  13.230 ms
 3 (2001:470:0:404::2)  15.311 ms  28.471 ms  10.383 ms
 4  2001:7f8:bd::3:2934:2 (2001:7f8:bd::3:2934:2)  62.711 ms  35.523 ms  35.376 ms
 5  * (2620:0:1cff:dead:beef::21fa)  34.604 ms  *
 6 (2620:0:1cff:dead:beef::ae1)  34.722 ms  * 49.700 ms
 7  * (2a03:2880:f01c:ffff::2a3)  49.691 ms  34.225 ms
 8  * * (2a03:2880:f11c:8083:face:b00c:0:25de)  34.526 ms

 on: March 20, 2020, 12:54:01 PM 
Started by alerinaldi - Last post by fcz
+1 for a tunnel server in Milan.. it would be great not only for Italy but for southern europe in general

 on: March 03, 2020, 07:06:12 AM 
Started by tonux - Last post by broquea
"Blacklisted" is the wrong term. The session got too many prefix announcements from you than expected, tripped the max limit of 200 routes, and closed the sessions. We just had to clear & reset on our side, and ensure your side wasn't leaking routes.

For anyone running BGP, always make certain you've got a nice tidy outbound filter applied to your sessions.

 on: March 02, 2020, 10:26:01 PM 
Started by tonux - Last post by tonux
Yes, thx again for your help.

For the record, the problem is I was blacklisted because I reached the max prefix limits (mistake with my  filters).

Have a good day

 on: March 02, 2020, 10:42:35 AM 
Started by finalbeta - Last post by FostWare
+1 for API that doesn't require removing 2FA

 on: March 02, 2020, 09:19:41 AM 
Started by tonux - Last post by broquea
asked/answered in TT opened.

 on: March 02, 2020, 02:04:30 AM 
Started by tonux - Last post by tonux

I'm using bird (v2.0.7)  for my BGP routers. I wanted to route IPv6 through Cogent but they can't do it for Google IPv6 ranges ( ) so I decided to create an IPv6 BGP peering with HE (thx for that, very useful)

But during some tests, without any relevant changes, my HE BGP endpoint starts refusing BGP connections with me

bird: hurricane: Connecting to 2001:470:xxxx:1 from local address 2001:470:xxxxx:2
bird: hurricane: Connection lost (Connection refused)

The tunnel ID is "573440"

Did I do something wrong, too many tests or something?


 on: February 27, 2020, 10:04:16 AM 
Started by snarked - Last post by snarked
PowerDNS says this: 

The DNAME record, as specified in RFC 6672 is supported. However, dname-processing has to be set to yes for PowerDNS to process these records.

Please turn it on.  Queries for sub-labels of a DNAME RR label are returning NXDOMAIN instead of following the target lookup which does have records at the final label (i.e. should be NOERROR).

 on: February 26, 2020, 04:04:26 PM 
Started by woosingwoo - Last post by hucste
I'm desparately looking for DNSSEC support too, using and its webinterface as master/primary dns server.

As master/primary dns server, it's currently not possible.

DNSSEC support is only if dns are slaves.

Pages: [1] 2 3 ... 10