Container skeptic checking in. The real crime is Kubernetes clusters that require v6 for pod networking (looking at you, Cilium with kube-proxy replacement) being deployed on clouds that don't offer it natively. Then you get this Rube Goldberg of 6in4 tunnels carrying encapsulated VXLAN carrying container traffic.
Three layers of encapsulation because someone wanted the latest CNCF graduated project on a 5 EUR VPS. The tunnel broker isn't the problem. The architecture is the problem.
Member
This. A thousand times this. I consult on cloud cost optimization and the number of times I've seen a 3-node "high availability" K3s cluster on 3 USD/month NAT VPS instances, each with an HE tunnel for v6 pod CIDRs...
The tunnel works fine. The insanity is the architecture that requires it.
Buenos Aires. Fibertel has v6 in Buenos Aires proper but not in my suburb (Morón). Same metro area, different headend, different century apparently.
I keep the HE tunnel for my Plex server so friends can reach it v6-only from their mobile providers. The tunnel has been up 940 days. Is it elegant? No. Does it work? Yes. Will I replace it the day Fibertel extends v6 here? Immediately.
Has anyone benchmarked MTU issues with HE tunnels recently? I still see fragmentation problems with 6in4 on paths that don't support 1280 properly. Docker default bridge MTU is 1500 and doesn't account for the 20 byte IPv4 + 40 byte IPv6 overhead, so you get weird failures on large transfers.
Or is this a solved problem in 2026 and I'm just running old images?
Not solved, still a footgun. You need to drop the Docker bridge MTU to 1400 or lower, or use PMTUD which breaks on any path with ICMP blackholes. Most "my container download is slow" issues I debug trace back to this.
WireGuard has the same problem (1440 effective MTU) but at least it's documented. HE's tunnelbroker setup instructions still claim 1480 works everywhere, which hasn't been true since middleboxes started clamping.
