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>

routeros/fritzbox-bf-static-routes-klickanleitung.md

@@ -0,0 +1,42 @@
+# BF-FritzBox: Statikrouten für die WG-Spoke-Netze (FM/DW → ap1) — Klick-Anleitung
+
+> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der BF-FritzBox (`10.40.41.254`,
+> kein MCP). ⚠️ FRITZ!OS-Labels sind versionsabhängig — Absicht zählt.
+>
+> 🔗 Teil von TP10 (`docs/tp10-vpn-migration.md`). **Interim-Maßnahme im Double-NAT** — beim permanenten
+> FB-Bridge-Cutover ist die FB aus dem Datenpfad → diese Routen werden gegenstandslos und können weg.
+
+## 🎯 ROOT CAUSE (verifiziert 2026-06-28) + der Fix
+**Fehlerbild:** WG `peer dw` gesund (Handshake, rx/tx beidseitig), aber **dw → BF antwortet nicht**.
+Die scheinbar funktionierende Gegenrichtung lief über **WARP** (out-of-band), nicht über den Tunnel.
+
+**Ursache:** Die BF-Infra hängt auf `10.40.41.0/24` (NAS .10, macmini .167, pve .100, Omada .175/.176 …).
+ap1s DHCP auf `bridge` ist **disabled** → diese Hosts beziehen DHCP von der **FritzBox** und haben
+**Default-GW `10.40.41.254` (FB)**, nicht ap1. Antwortet ein BF-Host an `10.95.10.x`, schickt er's an die
+FB — die hat **keine Route** zu den Spoke-Netzen mehr (terminiert die Tunnel nicht mehr) → **Antwort
+verschwindet** → *no response*.
+
+> **DER FIX:** Der FB beibringen, dass die Spoke-Netze **über ap1 (`10.40.41.1`)** erreichbar sind.
+> Dann gehen die Antworten der `.41`-Hosts an die FB → FB → ap1 → Tunnel. Voll transparent, kein NAT.
+
+## Eckdaten (beide Routen)
+| Netzwerk (Ziel) | Subnetzmaske | Gateway | Spoke |
+|---|---|---|---|
+| `10.95.10.0`  | `255.255.255.0` | `10.40.41.1` (ap1) | **DW/Geli** |
+| `10.101.0.0`  | `255.255.255.0` | `10.40.41.1` (ap1) | **FM** |
+
+## Klickpfad
+**Heimnetz → Netzwerk → Netzwerkeinstellungen → „weitere Einstellungen" → IPv4-Routen → Neue Route.**
+Pro Route: Netzwerk + Maske + Gateway aus der Tabelle, **aktiv** setzen, übernehmen. Für beide Zeilen.
+
+## Verify (entscheidend: LAN-Host, **ohne** WARP)
+1. Von Geli (`10.95.10.246/.247`, WARP **aus**) → BF-Infra **per IP**: `ping 10.40.41.10`, SMB/445 `10.40.41.10`.
+2. Quell-IP am BF-Zielhost = echte `10.95.10.x` (kein `10.255.255.x`, kein `10.40.41.1`) → bestätigt no-NAT.
+3. ap1: `list_firewall_rules out-interface=wg-hub` (*F) steigt; `list_connections` zeigt `10.95.10.x ↔ 10.40.41.x` established.
+4. FM-Quercheck: von `10.101.0.x` → BF-`.41`-Host ebenfalls grün.
+
+> **Status 2026-06-28:** DW-Route angelegt, **ohne WARP erfolgreich getestet** → dw → BF erreichbar. ✅
+> FM-Route analog mit angelegt (deckt denselben Rückweg ab).
+
+## Reversibilität
+Routen jederzeit in der FB-UI löschbar. Keine ap1-Änderung. Entfallen automatisch beim Bridge-Cutover.