Third VTI tunnel (or dual-stack on existing one) never passes data, even though IKE/CHILD_SA come up fine

otherwise

Hi all,

Running into something I can't get past and I'm starting to think it's a platform limit rather than something I'm doing wrong in config, so posting in case anyone's hit this or has an idea.

Setup: two pfSense boxes, each already running two VTI tunnels to each other/elsewhere (one site-to-site, one road-warrior). Both existing tunnels are IPv4-only and work perfectly. I added a real 10G point-to-point link between the two sites (bypassing the ISP entirely) and wanted to get IPv6 working across it, either by extending the existing site-to-site tunnel or building a fresh one dedicated to v6.

What I've tried, in order:

Added IPv6 traffic selectors to the existing (working) v4 tunnel's phase2. SPD ends up with the expected dual-stack wildcards (0.0.0.0/0|/0 and ::/0|/0), but IPv6 traffic through it goes nowhere.
Built a completely separate second tunnel - own ikeid, own PSK, own ipsecX interface (confirmed via ifconfig, this one actually showed up as its own device this time). Still IPv4 endpoints though. Same result - IKE_SA and CHILD_SA establish fine, but nothing passes.
Gave the underlying point-to-point link real IPv6 addresses and rebuilt the phase1 with genuine IPv6 endpoints this time (protocol=inet6, remote-gateway as an IPv6 address), since the docs say IPv6 payload needs IPv6 tunnel endpoints. Tunnel comes up, interface gets its IPv6 address, SPD/SAD both look completely correct on both ends. Still nothing gets through.
Same as #3 but swapped the interface-bound pass rule for a floating one, since I found redmine #8686 (VTI: assigned interface firewall rules are never parsed) and figured that might be it. No change.

The weirdest part: in every one of these, IKE's own control traffic (DPD keepalives) flows fine over the tunnel the whole time - I can see the packet counters ticking up in swanctl. It's specifically real data traffic that never makes it onto the wire. tcpdump on the underlying transport (proto esp) shows literally zero packets when I try to ping across, despite the SA/SPD dumps on both sides looking identical to the working v4 tunnel.

IPv4 across the same link, same interface type, works at 9.4Gbit/s without any of this drama, so it's not the physical link or the general IPsec setup.

Found two older threads that sound like the same ballpark but neither landed on a fix:

IPSEC VTI: IPv4 Working/IPv6 NFW (https://forum.netgate.com/topic/140217/ipsec-vti-ipv4-working-ipv6-nfw) - same "v4 fine, v6 dead" symptom, thread ends without resolution, OP was going to try native v6 endpoints (which is exactly what I did in step 3, also didn't help)
Problems with routed IPsec VTI (https://forum.netgate.com/topic/155132/problems-with-routed-ipsec-vti) - different specific issue (NAT/reply-to on VTI) but same general area of VTI routing weirdness

Given none of the four approaches worked and the symptom is identical across all of them, my working theory is this is specifically about having a third VTI interface at all (regardless of address family) - not really an IPv6-specific problem, just that IPv6 was the second reason I needed a third tunnel. Has anyone actually gotten more than two VTI tunnels running on one box, and if so did you have to do anything special? Or is there a known cap I'm just not finding documented anywhere?

Running pfSense 2.9.0-RELEASE if that matters.

Happy to pull any diagnostic output people want - I've already got SPD/SAD dumps, pf state tables, and swanctl logs from all four attempts.