# 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:** Beide Routen angelegt und **ohne WARP erfolgreich getestet** →
> dw → BF und fm → BF erreichbar. ✅

## Reversibilität
Routen jederzeit in der FB-UI löschbar. Keine ap1-Änderung. Entfallen automatisch beim Bridge-Cutover.