Were there are known blips on Thursday? I seemed to lose my v6 connection a couple of times. Obviously could also have been parts the underlying v4 network instead, though my monitoring graphs for my end of my v4 connection showed nothing (maybe LINX problem?)

Graph hopefully attached - times are UTC..

S.

I agree that this should definitely be communicated more transparently somewhere on the tunnelbroker site.

I thought about setting up a RiotIM server on a raspberry. Because port 443 on my IPv4 (dynamic) IP is already taken I planned to set it up using IPv6 only and use Cloudflare as IPv4->IPv6 proxy.

If I hadn't browsed this forum for a totally different reason I surely would also have spent quite some time debugging this setup.

I can assume why you did this and can a bit sympathize with that. But please make it transparent to all users!

The site has done something similar for years.  When you go to create a tunnel, it makes a request to an IP assigned to every tunnel server.  Whichever one is 'closer' by your ISP's metrics will reply, and automatically be set as the default server to create a tunnel on.  In some cases this might not turn out to be the closest by latency, but should generally be pretty close to it, unless your ISP has some unusual routing decisions.

Tunnel servers in the following locations are now running on upgraded hardware:

• Hong Kong
• Paris, France

Yes, I said "it might" as when a ping with default packet size (=56) and it works, it still works if increase the packet size to 100, then 500 then 1000 it works, and a few seconds after it doesn't anymore, even with default value.

if I let run the ping command, I have a huge loss of packet :

Code: [Select]

PING 2001:200:dff:fff1:216:3eff:feb1:44d7(2001:200:dff:fff1:216:3eff:feb1:44d7) 56 data bytes
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=12 ttl=50 time=319 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=13 ttl=50 time=320 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=14 ttl=50 time=321 ms
64 bytes from 2001:200:dff:fff1:216:3eff:feb1:44d7: icmp_seq=15 ttl=50 time=318 ms
^C
--- 2001:200:dff:fff1:216:3eff:feb1:44d7 ping statistics ---
73 packets transmitted, 4 received, 94% packet loss, time 72006ms
rtt min/avg/max/mdev = 318.390/320.028/321.046/1.240 ms

I tried to set MTU to 1480 (default value in tunnel broker account) and to minimum (1280).

Just noticed the same thing when I tried to configure an IPv6 tunnel for a site that uses Cloudflare (unfortunately, I have some servers in data centers that still don't offer native IPv6!). It would be good to document this more clearly on the tunnelbroker site.

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).