TP10 ⏸ pausiert: FM-Cutover revertiert (IPsec), FB-WG-LAN-LAN-Klickanleitung

FM-Cutover-Versuch gescheitert: .conf importiert, Handshake grün, IPsec voreilig
deaktiviert -> FM unerreichbar. Diagnose-Fehler: nur FB-eigene .254 gepingt (FB
antwortet aus Tunnel-IP 10.255.255.2 -> OS verwirft); echte FM-LAN-Hosts nie
getestet -> NAT-These unbewiesen. Research (Bouni) bestätigt FB<->MikroTik
LAN-LAN ohne NAT ist machbar. FM auf IPsec zurückgestellt; ap1-WG-Hub bleibt inert.

- routeros/fritzbox-wg-lanlan-klickanleitung.md: Diagnose->Fix->Verify, Echt-Host-
  Test ZUERST (10.101.0.10, nicht .254), IPsec bleibt Sicherheitsnetz.
- teilprojekte.md / tp10-vpn-migration.md: Status ⏸ + Incident dokumentiert.

Spoke-.conf mit Private-Keys bleiben gitignored in routeros/.secrets/ (die
ungetrackten Duplikate in routeros/ Root sind bewusst NICHT committet).

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

docs/teilprojekte.md

@@ -117,14 +117,20 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
   **Empfehlung:** VRRP nur für **MAIN/INFRA**, sonst ap2 als **Kalt-Ersatz** + Backup. DHCP/DNS schon redundant (Split + 2 Resolver).
 - Abh.: TP4. (Research erledigt, s. TP-R + Config-Skizze im Report.)
 
-### TP10 — Multi-Site VPN ▸ 🟡 Phase A erledigt (Hub gebaut), Cutover offen (`docs/tp10-vpn-migration.md`)
+### TP10 — Multi-Site VPN ▸ ⏸ PAUSIERT (FM auf IPsec zurück), Klickanleitung steht (`docs/tp10-vpn-migration.md`)
 - **✅ Phase A (2026-06-16):** ap1-WG-**Hub** `wg-hub` live (UDP **51821**, MTU 1412, keine IF-IP). 2 Peers
   vorkonfiguriert: **FM** `10.101.0.0/24` (war IPsec) = `peer1` · **DW/Geli** `192.168.178.0/24` CGNAT (war WG) = `peer2`.
   Routen + Firewall (input/forward) gesetzt; NAT braucht nichts (Egress wg-hub ≠ masq-Interface). Hub-Pub
   `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=`, Endpoint `xvbeo64jqlqd9gfo.myfritz.net:51821`.
   Spoke-Configs in `routeros/.secrets/wg-{fm,dw}.conf` (Private-Keys, nicht im Git). FB-Portfreigabe 51821→ap1 gesetzt.
-- **⏳ Phase B (Cutover, offen):** `.conf` je FB importieren → Handshake/L3-Verify (FM: SMB per IP wg. NetBIOS-Lehre)
-  → erst dann alten AVM-Tunnel (IPsec/WG) abschalten. Parallelphase, reversibel. **Port 51821** hält FB-51820-WG (DW) intakt.
+- **⛔ Phase-B-Versuch FM gescheitert → revertiert (2026-06-16):** `.conf` importiert, Handshake grün, IPsec
+  voreilig deaktiviert → FM-LAN nicht erreichbar. **Befund:** WG-Tunnel routet (rx/tx fließen), aber Test war nur
+  Ping auf FB-eigene `.254` (antwortet aus Tunnel-IP `10.255.255.2` → OS verwirft) — **echte LAN-Hosts nie getestet**.
+  → **NAT-These unbewiesen.** Research (Bouni) bestätigt FB↔MikroTik-LAN-LAN **ohne NAT** ist machbar. User hat
+  **FM auf IPsec zurückgestellt** (FB-WG aus). ap1-WG-Hub/Peers bleiben (inert).
+- **⏳ Resume:** Klickanleitung `routeros/fritzbox-wg-lanlan-klickanleitung.md` — **Echt-Host-Test zuerst**
+  (realer `10.101.0.X`, nicht `.254`), FB-WG als LAN-LAN/AllowedIPs `10.40.0.0/16` prüfen, ap1-Route `10.255.255.0/24→wg-hub`,
+  IPsec erst nach grünem Verify abschalten. **Port 51821** hält FB-51820-WG (DW) intakt.
 - **Empfehlung:** **Hybrid** — **WireGuard Site-to-Site-Backbone** (BF/hAP = WG-**Hub**, FM/DW = FritzBox-**Spokes**, hub&spoke, **KEINE Zusatz-HW**) **+ WARP für Remote-User** (ergänzt, ersetzt nicht).
 - **WARP kann FBs NICHT direkt** ansprechen → bräuchte Connector-Host hinter der FB (an reinen-FB-Standorten FM/DW unattraktiv).
 - **Vorab-Check (User, entscheidend):** WAN je Standort — **public/dynamisch (OK: DynDNS/MyFRITZ) vs. CGNAT/DS-Lite am BF-Hub (= K.O. → dann CF/WARP-Pfad, CGNAT-immun)**.

docs/tp10-vpn-migration.md

@@ -4,6 +4,14 @@
 > gated: permanenter FB-Bridge-Mode (AP4.1) hängt an diesem TP.
 > **Reihenfolge fix: VPNs migrieren → Liwest-Anruf (Bridge) → FB wird Modem.**
 
+> ## ⏸ STATUS 2026-06-16: PAUSIERT — FM auf IPsec zurück
+> Phase-A-Hub auf ap1 steht (s.u.). **Phase-B-Versuch FM gescheitert + revertiert:** `.conf` importiert,
+> Handshake grün, IPsec voreilig aus → FM nicht erreichbar. **Diagnose-Fehler:** nur FB-eigene `.254` gepingt
+> (antwortet aus Tunnel-IP `10.255.255.2` → OS verwirft); **echte FM-LAN-Hosts nie getestet** → NAT-These unbewiesen.
+> Research (Bouni) sagt: FB↔MikroTik-LAN-LAN **ohne NAT geht**. User hat **FM auf IPsec zurückgestellt** (FB-WG aus),
+> ap1-WG-Hub bleibt (inert). **Wiederaufnahme via Klickanleitung `routeros/fritzbox-wg-lanlan-klickanleitung.md`**
+> (Echt-Host-Test ZUERST, dann FB-LAN-LAN-Check, IPsec bleibt Sicherheitsnetz).
+
 ## Zielbild
 - **ap1 (hAP ax², 7.23.1) = WireGuard-Hub** (nativ). FM & DW = FritzBox-Spokes (hub-&-spoke, keine Zusatz-HW).
 - Ablösung der **2 produktiven AVM-LAN-LAN-Tunnel** auf der BF-FB → **2× WireGuard auf ap1**:

routeros/fritzbox-wg-lanlan-klickanleitung.md

@@ -0,0 +1,98 @@
+# FritzBox WireGuard als LAN-LAN-Kopplung (FM-Spoke → ap1-Hub) — Klick-Anleitung
+
+> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der FritzBox. FB = **FM-Standort**
+> (`10.101.0.0/24`, GW `10.101.0.254`), aktuell wieder produktiv über **IPsec**. Hub = ap1 (BF).
+> ⚠️ **FRITZ!OS-Labels sind versionsabhängig** — wo ich unsicher bin, steht die **Absicht** dabei; nimm das
+> passende Menü, nicht das wörtliche Label. Bezieht sich auf FRITZ!OS 7.5x/8.x (WireGuard).
+
+## Was wir wollen (in einem Satz)
+Die FM-FritzBox so per **WireGuard** an den ap1-Hub koppeln, dass **echte LAN-Hosts** (`10.101.0.x`) und
+das **BF-LAN** (`10.40.0.0/16`) sich gegenseitig mit ihren **realen IPs** erreichen — **kein NAT/Masquerade**,
+echtes Site-to-Site-Routing. Das war beim letzten Versuch vermutlich genau die Lücke („NetBIOS ging nicht").
+
+## ⚠️ Bevor du klickst — Sicherheit (FM ist produktiv!)
+- **IPsec bleibt an** — das ist das Sicherheitsnetz. **Erst** abschalten, wenn der Echt-Host-Test (Teil 4) grün ist.
+- WG läuft **parallel** zu IPsec (anderer Mechanismus, kein Konflikt). Wir testen WG, ohne IPsec zu opfern.
+- ap1-Seite ist fertig und verifiziert (Hub `wg-hub` UDP 51821, Peer `peer1`, Route, Firewall) — **hier nichts ändern**
+  außer der einen Route in Teil 3.
+
+## Eckdaten (zum Eintragen)
+| Feld | Wert |
+|---|---|
+| Hub-Endpoint | `xvbeo64jqlqd9gfo.myfritz.net:51821` |
+| Hub-Public-Key | `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=` |
+| FM-Tunnel-IP (diese FB) | `10.255.255.2/32` |
+| Remote-Netz (BF, „erreichbare Netze") | `10.40.0.0/16` (+ Tunnelnetz `10.255.255.0/24`) |
+| MTU / Keepalive | `1412` / `25` |
+| FM-Spoke-`.conf` (vorbereitet) | `routeros/.secrets/wg-fm.conf` |
+
+---
+
+## Teil 0 — Erst messen, ob überhaupt was kaputt ist (WICHTIG)
+Beim letzten Versuch haben wir nur die FB-**eigene** IP `10.101.0.254` gepingt — die antwortet aus der Tunnel-IP
+`10.255.255.2`, was das OS verwirft. Das **beweist keinen** Fehler. **Echt-Host-Test zuerst:**
+
+1. WG an der FM-FB wieder **aktivieren** (die in Teil 1 inspizierte/erstellte Verbindung), IPsec **an lassen**.
+2. Von einem **BF-VLAN10/20-Host** (Gateway = ap1) einen **realen FM-LAN-Host** ansprechen — **nicht** die `.254`:
+   - z.B. `ping 10.101.0.10` oder im Browser/Explorer `\\10.101.0.10` (SMB per **IP**).
+3. Sag mir den Host — ich schaue parallel auf ap1 mit `torch wg-hub` + sourced
+   `/ping 10.101.0.10 src-address=10.40.20.1` und prüfe die **Quell-IP der Rückpakete**:
+   - **Reale `10.101.0.X`** → es war nie kaputt, nur das `.254`-Artefakt → direkt zu Teil 4 (Cutover).
+   - **`10.255.255.2`** → echtes NAT/Forward-Problem → Teil 1–3 abarbeiten.
+
+---
+
+## Teil 1 — Bestehende WG-Verbindung inspizieren
+**Klickpfad:** `Internet → Freigaben → Reiter „VPN (WireGuard)"` → die FM-Verbindung auswählen/bearbeiten.
+
+Prüfe drei Dinge:
+1. **Modus = Netzwerk-Kopplung, nicht Einzelgerät.**
+   Absicht: Die Verbindung darf **nicht** „dieses eine Gerät einwählen + gesamten Internetverkehr" sein.
+   → Falls es eine Option **„gesamten Internetverkehr über die VPN-Verbindung senden"** gibt: **AUS**.
+2. **Erreichbare/erlaubte Netze (AllowedIPs).**
+   Es muss **`10.40.0.0/16`** (BF) + **`10.255.255.0/24`** (Tunnel) enthalten — **nicht** nur die Hub-IP oder `0.0.0.0/0`.
+   Wenn die FB beim Import die AllowedIPs gekürzt hat → das ist die Ursache.
+3. **Public-Key der FM-FB notieren** (steht in der Verbindungs-/Schlüsselansicht).
+   → Den brauche ich, **falls** die FB einen **eigenen** Key erzeugt hat (statt dem aus unserer `.conf`).
+   Schick ihn mir; ich gleiche `peer1` auf ap1 ab.
+
+> Wenn alles oben schon stimmt und Teil 0 trotzdem `10.255.255.2` zeigte → die FB routet ihr LAN nicht in den
+> Tunnel. Dann Verbindung in **Teil 2** sauber neu anlegen.
+
+---
+
+## Teil 2 — WG-Verbindung als LAN-LAN neu/korrekt anlegen
+Nur nötig, wenn Teil 1 einen falschen Modus/AllowedIPs zeigt.
+
+1. Alte FM-WG-Verbindung **löschen**.
+2. `Internet → Freigaben → VPN (WireGuard) → „Verbindung hinzufügen"`.
+3. Verbindungstyp wählen, der **zwei Netze koppelt** (LAN-LAN / „Netzwerk koppeln"), **nicht** „Einzelnes Gerät".
+   - Falls FRITZ!OS nur den FB↔FB-Assistenten anbietet: stattdessen **eigene/importierte Konfiguration** nutzen
+     und die Datei **`routeros/.secrets/wg-fm.conf`** importieren (enthält die korrekten AllowedIPs `10.40.0.0/16`).
+4. Falls manuell statt Import — Werte aus „Eckdaten" oben eintragen:
+   Endpoint, Hub-Public-Key, Tunnel-IP `10.255.255.2`, erreichbare Netze `10.40.0.0/16` + `10.255.255.0/24`,
+   Keepalive 25, MTU 1412.
+5. **„Gesamten Internetverkehr über VPN" AUS.** Speichern.
+6. **Public-Key** der neuen Verbindung notieren → mir geben (für `peer1`-Abgleich auf ap1).
+
+---
+
+## Teil 3 — ap1-Begleitänderung (mache ich)
+Damit ap1 auch die Tunnel-IPs selbst adressieren kann (Diagnose + saubere Rückwege):
+- Route **`10.255.255.0/24 → wg-hub`** auf ap1 ergänzen.
+- Falls FB neuen Key hat: `peer1`-Public-Key aktualisieren.
+> Sag Bescheid — das sind zwei nicht-disruptive Befehle, die ich per MikroMCP setze.
+
+---
+
+## Teil 4 — Verifizieren, dann erst IPsec abschalten
+1. **Echt-Host-Test** wie Teil 0 → muss **reale `10.101.0.X`** zeigen, beide Richtungen:
+   - BF-Host → FM-Host (Ping + SMB/445 per IP).
+   - FM-Host → BF-Host (z.B. NAS) per IP.
+2. **Namensauflösung** per IP/DNS testen, **nicht** über Netzwerkumgebung/Broadcast (NetBIOS routet nicht).
+3. Erst wenn **beide Richtungen grün** sind: **IPsec für FM auf der BF-FritzBox deaktivieren** → erneut testen.
+4. Bleibt es grün → FM ist migriert. **DW** läuft danach nach demselben Muster (CGNAT → wählt ausgehend, Keepalive).
+
+## Rollback
+- Jederzeit: WG an der FM-FB deaktivieren + **IPsec wieder aktivieren** → Ausgangszustand.
+- ap1-Seite unverändert lassen (inert ohne aktive Spoke-Gegenstelle).