All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
tunnelbroker.net randomly losing access
Recently I've been playing tunnelbroker on a NAT box with no native ipv6. I'm encountering a very weird behaviour and hoping someone with better ipv6 knowledge can explain.
I've configured tunnelbroker and I do get ipv6 access, but then without touching anything this v6 connection would stop working (no ping from outside and can't reach out from within the box). But leaving it untouched sometimes it would start working again, and of course it will stop working eventually, and back and so forth...
I have another VM with a dedicated IP and configured tunnelbroker just fine, appears that the connection doesn't drop like the NAT box. I'm convinced that there's something with the NAT part, but I can't understand why it would work then stop working randomly.
I'm not great with v6 stuff, I'm hoping someone can point me in the right direction to why this is happening and possibly how to fix it.
Thanks
Comments
You must configure the router to forward protocol 41 to the inner host or set the inner host as "DMZ host".
TunnelBroker would not work properly otherwise.
IPv4/IPv6 tunnels are not TCP/UDP, and it has no port. Although it can be NATed, it cannot be shared. If more than one system try to use it in a shared IP, you will conflict each others.
It's not protocol 41, I've eliminated that. I tested in an environment where protocol 41 is not passed and the message I got when pinging the v6 address was time out. Now, I get destination host unreachable.
What confuses me is it would work at some point, but stops working on its own. Feels like something is causing a conflict.
I don't think anyone else is sharing this, otherwise tunnelbroker would complain the IP is in use. Unless if someone else is using another service. But I've tried three different environments/hosts and all have the same issue.
Capture packet traces on both external and internal interfaces of the NAT box.
This would allow you to figure out what's wrong.
If the NAT box is Linux or OpenWrt, you can use tcpdump.
Otherwise, you'll need to connect a managed switch and continue port-mirroring, and then run tcpdump on a machine attached to the mirror target port.
I'm not sure if I'm doing this right, but I'm capturing the tunnel interface and it's really quiet. When I try to ping out from the VM (say the server's v6 address), I do see the ICMP6 echo requests, but no replies.
16:51:52.527185 IP6 (flowlabel 0x59053, hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:xxxx::2 > 2001:xxxx::1: [icmp6 sum ok] ICMP6, echo request, id 56420, seq 9You need to capture on the NAT box (router), not the inner host.
OK and what's happening on the external interface?
I see the ICMP6 echo requests, again no reply. I've tried capturing the nat bridge interface and the device interface for my VM.
Seems a lot like it's actually it's own protocol like @Nya already mentioned. NAT would have no way to tell apart different hosts behind it wanting to use this (i highly doubt there's a NAT implementation smart enough to actually look at the source/destination of the encapsulated packet - even if there is chances are it's not available on the NAT you are using), so as soon as there's another NAT'd box trying to communicate with tserv1.tyo1.he.net problems are pretty much guaranteed.
Your best option would probably be to tunnel to your other box (using Wireguard, OpenVPN or whatever) first and either run the connection to tunnelbroker over it or connect tunnelbroker from your other box and route the provided IPv6 subnet over the VPN.
I looked at the host server, I don’t see another vm attempting to connect to that tunnel broker server. But it does sound like the host is unsure where to route the traffic.
When I look at the sample configs provided by tunnelbroker, I also see windows 10 and stuff. Most likely those are running within a router of some sort, so NAT is there and in theory should work. Maybe the idea of this running inside NAT VM would require an actual router?
Tunnels have no keepalive, so it could be your NAT conntrack expired once no traffic for sometime.
NAT will cause weird behavior, it always has..
Natively setup the tunnelbroker connection on your NAT gateway, use the /48 and route a /64 to your VM.
Best chance of it working with NAT, you need to be using a NAT gateway that can forward protocol 41.. Only difference from forwarding protocol 6, is that port numbers are not needed.
So NAT is there?? No it isn't. There is no NAT in any of their example configs.
SixXS would work through NAT, by creating a VPN type connection, but SixXS has been gone for almost 10 years now.
There's a TTL value on debian interface file, I even set it to like 10 and didn't help. Maybe this is it...
There's a mention of a router on tunnelbroker.net and protocol 41.
Yes.. Routers are mentioned a lot.
I've encountered a similar problem (on a colocrossing VPS which tunnel-brokers with he.net to get IPv6 access) that after some time the assigned IPv6 address can't be reached from public internet.
My solution is setting a cron task which ping6 dns.google (2001:4860:4860::8844) or one.one.one.one(2606:4700:4700::1001) twice every 7 minutes:
*/7 * * * * ping -c2 -w3 -6 2001:4860:4860::8844 || ping -4 -c2 -w3 8.8.4.4 && sudo systemctl restart he-ipv6.serviceThis is what I did. I added a post-up ping command and just ping the tunnel gateway and it seems to have fixed the issue. Over 24 hours and tunnel is still up. It’s currently continuous ping to the gateway, not sure if HE cares or not, I might switch it over to a cron task instead and do it once every minute or something.
You could adjust the interval of ping with -i option:
ping -i 500 2001:470:20::2Yep, exactly what I did, except 30 seconds intervals.