BGP /40 advertised globally but CHR won't forward traffic FROM my own prefix — dies inside router, never reaches upstream

SETUP

  • Own ASN (AS2028xx), IPv4 /24 + IPv6 /40 from RIPE
  • CHR (RouterOS 7.22.3) at provider, eBGP to upstream
  • Home router (CCR, ROS 7.22.3) behind it
  • GRE tunnel between them: fd00:10:10:10::1 (CHR) <-> ::2 (home)
  • iBGP CHR <-> home over the tunnel
  • VMs live behind home router, in 2a14:1ec7:8300::/64

WHAT WORKS

  • IPv4 /24: fully working, in production
  • IPv6 /40: advertised, 99% globally visible (verified RIPEstat)
  • Both BGP sessions stable (eBGP to upstream + iBGP to home)
  • CHR can ping the IPv6 internet itself using its peering address
    (src = 2a07:xxxx:xxxx:23a::1) -> 0% loss
  • VM can ping its own gateway (2a14:1ec7:8300::1 on home) -> 0% loss
  • Home reaches CHR over tunnel (ping fd00:10:10:10::1) -> 0% loss

THE PROBLEM
VMs cannot reach the IPv6 internet. Traffic leaves home, enters CHR
through the tunnel, but never exits toward the upstream.

DIAGNOSTICS
Home firewall counters:
"forward accept src=2a14:1ec7:8300::/40" -> 62458 packets OUT
"forward accept dst=2a14:1ec7:8300::/40" -> 0 packets IN

Sniffer on home gre interface: VM's v6 packets leave home correctly
(all outgoing, no replies).

Torch on CHR gre-2-home: VM traffic ARRIVES at CHR
(RX ~832bps icmpv6 from VM -> Cloudflare).

Torch on CHR bridge1 (toward upstream): NO /40 traffic at all —
only the BGP session + NDP. So traffic enters CHR and dies before
reaching bridge1.

KEY CLUE — source-address dependent on CHR:
ping 2606:4700:4700::1111 src=2a07:xxxx:xxxx:23a::1 -> WORKS
ping 2606:4700:4700::1111 src=2a14:1ec7:8300::1 -> "address
unreachable from 2a14:1ec7:8300::1" (CHR rejects itself)
ping 2606:4700:4700::1111 src=fd00:10:10:10::1 -> "address
unreachable"

CHR ROUTING
::/0 -> fe80::1%bridge1 (distance 1, ACTIVE — the
only default that ever goes active)
::/0 -> 2a07:xxxx:xxxx:400::179 (becomes INACTIVE — can't
be resolved as next-hop, even though CHR CAN ping it)
DAb 2a14:1ec7:8300::/40 -> fd00:10:10:10::2 (iBGP from home, dist 200)

CHR had 2a14:1ec7:8300::1/64 connected on bridge1. I suspected this
connected /64 conflicts with the iBGP /40 toward the tunnel (CHR thinks
the VMs are on the upstream link, not behind the tunnel). I removed it
— the error CHANGED (VM now gets "Destination unreachable from
fd00:10:10:10::1" instead of timeout) but it did NOT fix forwarding.

CHR OTHER STATE
/ipv6 settings: forward=yes, no RPF setting visible
/ipv6 firewall filter: all rules currently disabled
/ipv6 firewall mangle: empty
/ipv6 firewall nat: empty (public IPs, no NAT intended)
Upstream gave a static route 2a07:xxxx:xxxx:400::/64 -> bridge1
(this fixed an earlier hold-timer issue)

QUESTION
Traffic from my own /40 enters CHR via the tunnel but never gets
forwarded out bridge1. CHR forwards fine when the source is its
peering-subnet address, but "address unreachable" when source is the
/40 or the tunnel IP. What's the correct way to set up CHR so it
forwards /40 traffic toward the upstream while routing return traffic
back through the tunnel to home — without breaking the BGP
advertisement? Is the connected /64 the issue, the link-local default
gateway, or something with how the global next-hop won't resolve?

Happy to post any full config sections needed.