Weird failure with a brand new tunnel on Warsaw server.

[MaZe]

I've got about 12 years of pretty deep Linux (both Kernel side and network config) ipv6 experience as my day job, so I'm pretty sure the problem isn't on my side... but it is a brand new tunnel in a new location, behind a nat-ing ADSL modem, so everything is theoretically possible...  Still, my gut feeling says the Warsaw server side is misconfigured.

Anyway, here's what I'm seeing.

Linux Fedora 34 box behind a Netgear D1500 ADSL modem with NAT:

# max possible mtu is 1438, due to ADSL ipv4 mtu being 1458,
# but HE web interface only accepts multiples of 4 and ipv6 fragmentation likes multiples of 8, so round down to multiple of 8
MTU=1432

wget -O - 'https://...:...@ipv4.tunnelbroker.net/nic/update?hostname=649805'
ip link del he6
ip link add name he6 type sit mode ip6ip remote 216.66.80.162 local 10.0.0.3 ttl inherit tos inherit
ip link set he6 mtu "${MTU}"
ip link set he6 up
ip -6 addr add 2001:470:70:32e::2/64 dev he6
ip -6 route add default dev he6

ip -d link show he6
ping6 -c1 2001:470:70:32e::1
ping6 -c1 2001:470:70:32e::1 -M do -s $[MTU-40-8]

up until here, everything is ok - ie. both of the above pings *work*.

ping6 -c1 2001:470:70:1::1
  also works, and yet
ping6 ipv6.google.com
  does not (dns resolution succeds over ipv4).

Nor does any other ipv6 address I try (except for those I would reasonably expect to be served by the Warsaw tunnelserver itself, ie. in general ping to 2001:470:70:*::1 works - for small values of *, ie. up to 0x33E as I type this).
TCPdump'ing shows outgoing ipv6-in-ipv4 packets, but nothing coming back (for ips that don't respond).
Trying to traceroute back to 2001:470:70:32e::2 from outside, also shows nothing in tcpdump...

Indeed AFAICT it seems like the Warsaw tunnel server is blackholing traffic to/from the tunnel that isn't local to the box itself.  That's why pinging 2001:470:70:*::1 (which are presumably the server side of someone else's tunnel) works, but nothing else does...

[MaZe]

I did eventually manage to fix this, but it was pretty weird.

I deleted and recreated the tunnel, got new subnets, that didn't work.
Eventually I created another tunnel, changed the client IPv4 address on a bunch of tunnels finally got things working.

This isn't verified, but I think the problem is tunnels don't actually work until you change the client IPv4 address on them.
(ie. if you create them with the right ipv4 address through the web ui they're broken until you change the address - possibly via the web UI - and possibly change it back again to what you want/need)

Mind you, I got this fixed a few days back, and no longer remember the details, and I'm not at all certain of the conclusions.  I know things started working without any configuration changes on my side (besides updating the ipv6 subnets), so the problem was some sort of misconfig on the warsaw tunnel server side that eventually resolved itself...