connecting to VPN server w/IPv6 address from client with IPv4

Question

I'm a migratory bird with three locations. Each has an OpenVPN server with several uses: connect to devices on the LAN to update configs or troubleshoot, present a 'home' IP when making a purchase (consistent with shipping/billing address), bypass IP geo restrictions (e.g. homedepot.com is inaccessible from countries where they don't have stores), stream video.

All was well (everything IPv4) until SFR, my ISP in Paris, switched from providing a public IPv4 address to CGNAT. IPv6 works fine so I changed the server to use it and thought all was well again. But I get to Bangkok and discover that True, my ISP here, doesn't support IPv6 at all.

First, I tried Teredo based on https://techcommunity.microsoft.com/t5/windows-insider-program/teredo-problem-on-windows-11/m-p/2614126 . It appears to connect ok (state shows qualified), and a Wireshark capture seems to show proper encapsulation of IPv6 packets, but nothing arrives at the other end. I know the router or True isn't blocking Teredo, because the control packets get proper responses. I don't know how to troubleshoot this further.

Next, tried https://tunnelbroker.net/ . I can't complete the setup -- HE's instructions stop at Win 10, the netsh interface commands in Win 11 have new syntax and symantics, and I failed to find a solution online.

Then, tried SOCAT IPv4 to IPv6 Routing on a dual-stack VPS I have in Los Angeles. It is fully functional, but performance is awful, primarily caused by routing across 18 timezones instead of 6. I could fix this with a VPS in e.g. Singapore, but if possible I'd like to avoid the expense, administrative hassle and additional point of failure.

Finally, tried https://1.1.1.1/ . This works fine for e.g. SSH access, and I can even bring up the VPN, but Cloudflare messes with the routing tables so traffic doesn't flow through the VPN. When I try to fix this manually, they quickly overwrite my changes.

Answer 1

Thanks for suggesting that I focus on Tunnel Broker; I was able to find a solution.

The problem was that I misinterpreted this note from HE: "When behind a firewall appliance that passes protocol 41, use the IPv4 address you get from your appliance's DHCP service instead of the IPv4 endpoint you provided to our broker." I incorrectly thought that the ISP-supplied consumer router would be unlikely to handle protocol 41 and the system would fall back to UDP, so the note didn't apply.

As I didn't want to waste time fighting Windows if there were other obstacles (router or ISP), I tested the tunnel with Linux. There were no errors at setup but I got an Address Unreachable ICMP when attempting to pass traffic. Still not understanding what was going on, I tried MacOS. Though Apple is generally not known for informative error messages, in this case they were right on "unable to bind to ". I substituted the MAC's LAN address and the tunnel starting working.

I did the same on Linux, which was also successful, but with Windows, still no workie. Eventually discovered that giving a correct v6v4tunnel command after an incorrect one, does not update the bad tunnel but creates a new one. So, after manually deleting all incorrect objects, HE's recommended setup for Win10 worked fine with Win11!

Thanks again for your help.