TP10 🔧 dw→BF Rückweg-Blackhole gefixt: BF-FB-Statikrouten → ap1

peer dw gesund, aber dw→BF stumm: .41-Infra hat FB-Default-GW (ap1-DHCP
auf bridge disabled) → Antworten an Spoke-Netze landen bei der FB ohne
Route → Blackhole. "Funktionierende" Gegenrichtung war WARP, nicht Tunnel.

Fix (Interim, Double-NAT): 2 Statikrouten auf der BF-FB,
10.95.10.0/24 + 10.101.0.0/24 → 10.40.41.1 (ap1). Transparent, FM mit
abgedeckt. DW ohne WARP getestet ✅. Beim Bridge-Cutover obsolet.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/tp10-vpn-migration.md

@@ -14,6 +14,13 @@ BF-FB-Portfreigabe (51821 → ap1). Live verifiziert: `peer fm` (`10.101.0.0/24`
 - **→ FB-Bridge entblockt:** die FB terminiert keine Tunnel mehr. **Rest:** WAN-Input-Seal (Block C aus
   `routeros/tp10-cutover-apply.rsc`) + **Liwest-Anruf** → ether1 = Public Edge, Double-NAT weg; danach BF-FB-eigenen
   WG-Server 51820 abräumen; DDNS-Auto-Updater für `bf4` auf NAS/pve.
+- **⚠️ Rückweg-Gotcha behoben (2026-06-28):** `peer dw` war gesund (Handshake, rx/tx beidseitig), aber
+  **dw → BF = no response**. Root Cause: die BF-Infra hängt auf `10.40.41.0/24` und bezieht DHCP/Default-GW von der
+  **FritzBox** (ap1-DHCP auf `bridge` = disabled) → Antworten an `10.95.10.x` gehen an die FB, die keine Route zu den
+  Spoke-Netzen mehr hat → Blackhole. Frühere „verifiziert" waren **ap1-sourced bzw. WARP**, nie ein LAN-`.41`-Host.
+  **Fix (Interim, Double-NAT):** 2 Statikrouten auf der BF-FB — `10.95.10.0/24` + `10.101.0.0/24 → 10.40.41.1` (ap1).
+  Voll transparent (echte LAN-IPs), deckt FM mit ab. **DW ohne WARP getestet ✅.** Anleitung:
+  `routeros/fritzbox-bf-static-routes-klickanleitung.md`. Beim Bridge-Cutover obsolet (FB raus aus dem Pfad).
 
 ## 🟢 STATUS 2026-06-25: CUTOVER-READY — Apply-Skript gestaged, wartet auf Bridge-Tag
 ap1-Live-Stand verifiziert; alle ap1-Änderungen in **`routeros/tp10-cutover-apply.rsc`** gebündelt (idempotent):