TP10 🔐 Cutover-Ready: ap1-Apply-Skript + WAN-Input-Seal + FB-Klickanleitungen

ap1-Seite gestaged in routeros/tp10-cutover-apply.rsc (idempotent, am Bridge-Tag
anwenden): WG-Peers säubern (Transfernetz-/32 raus) + enable, peer1/FM bidirektional
(Endpoint abxhutfgsid9snmy.myfritz.net:52476, kein CGNAT), peer2/DW Dial-in; Spoke-
Routen → wg-hub; Input-Chain WAN-Seal (schließt Mgmt-Dienste + offenen Resolver,
sobald ether1 die Public-IP hält); ether1 use-peer-dns=no.

FB-Seite (kein MCP → Klickanleitung): neue fritzbox-bf-bridge-cutover-klickanleitung.md
(Passthrough + alte FM/DW-WG-Teardown + Rollback); fritzbox-wg-lanlan-klickanleitung.md
mit Schnellpfad (FM nur Peer-Endpoint auf bf4 umbiegen) + IPsec-Korrektur.

Doku: tp10-vpn-migration.md Status → CUTOVER-READY, Live-Stand verifiziert; FM=FB-WG
(IPsec längst gekillt) korrigiert. wan-cutover-runbook.md als permanenter Cutover markiert.

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

docs/tp10-context-digest.md

@@ -3,7 +3,7 @@
 > Verdichteter Handoff-Stand. Vollständig: `docs/tp10-vpn-migration.md`. (Erstellt lokal via Ollama
 > `nemotron-3-nano:4b`, fakten-gegengeprüft.)
 
-- **TP10** = 2 AVM-Tunnel (FM=IPsec, DW/Geli=FB-WireGuard) → **2× WireGuard mit Hub auf ap1** (MikroTik hAP). Gated: permanenter FB-Bridge.
+- **TP10** = 2 AVM-Tunnel (FM **= FB-WG**, IPsec längst gekillt; DW/Geli = FB-WireGuard) → **2× WireGuard mit Hub auf ap1** (MikroTik hAP). Gated: permanenter FB-Bridge.
 - **Entscheidung 2026-06-17:** TP10 **vertagt, gebündelt mit FB-Bridge-Cutover** (VPN-auf-FB ⊕ Bridge schließen sich aus). Am Bridge-Tag hat ap1 die Public-IP → kein Port-Forward. Vorerst beide VPN über die BF-FritzBox: **FM=IPsec, DW=FB-WG**.
 - **Root Cause (FM-PoC bewiesen):** FB masqueradet den WG-Tunnel, wenn die WG-Interface-`Address` eine **Transfernetz-IP** ist. AVM = Proxy-ARP → **FB-WG-`Address` MUSS die LAN-IP sein**. Beweis: Ping `10.101.0.10` kam aus `10.255.255.2` (NAT).
 - **Eckdaten:**
@@ -13,6 +13,6 @@
   - FM LAN **`10.101.0.0/24`** GW .254, FB-WG-`Address` = **`10.101.0.254/24`**
   - DW/Geli CGNAT v4, LAN heute **`192.168.178.0/24`** GW .1, künftig **`10.95.10.0/24`**. FB-WG-`Address` = **`192.168.178.1/24, 10.95.10.1/24`** (dual, renumber-fest). Keepalive 25.
 - **Zustand:** ap1-Hub geparkt (Peers disabled, WG-Routen entfernt, Firewall bleibt). DW-Config bei Geli vor Ort gestaged 2026-06-17.
-- **Offen (sobald BF erreichbar):** `peer2` enable, allowed-address **`192.168.178.0/24,10.95.10.0/24`** (Key `FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw=` oder Gelis FB-eigener Key), Routen `192.168.178.0/24` + `10.95.10.0/24` → wg-hub. `peer1`/FM bleibt disabled.
+- **Gestaged (`routeros/tp10-cutover-apply.rsc`, am Bridge-Tag anwenden):** `peer1`/FM enable, allowed-address `10.101.0.0/24`, **Endpoint `abxhutfgsid9snmy.myfritz.net:52476`** (bidirektional, FM kein CGNAT). `peer2`/DW enable, allowed-address **`192.168.178.0/24,10.95.10.0/24`** (Key `FqYZLztQ…PbzUw=` oder Gelis FB-eigener Key), Endpoint leer (CGNAT-Dial-in). Routen `10.101.0.0/24` + `192.168.178.0/24` + `10.95.10.0/24` → wg-hub. Plus Input-WAN-Seal + ether1 `use-peer-dns=no`.
 - **Gotchas:** (1) FB-WG-`Address` = LAN-IP, kein Transfernetz. (2) NetBIOS routet nicht über Tunnel → per IP/DNS testen (SMB 445), kein Broadcast. (3) Gelis FB lehnt 2 WG zum selben Zielnetz ab → direkter Swap. (4) Verify: Antwort-Quelle muss echte LAN-IP sein, nicht `10.255.255.x`.
 - **v6-Variante (später):** Gelis FB hat natives öffentliches IPv6 `2a0e:7a02:31c:3000::/56` (rotiert ~30h via MyFRITZ), v6-Inbound offen → direktes WG ap1↔Geli über v6 umgeht CGNAT; Inner-Tunnel bleibt IPv4.

docs/tp10-vpn-migration.md

@@ -3,11 +3,18 @@
 > **Single Source of Truth** für TP10. Research: `docs/research/vpn-comparison.md` · IPv6: Memory `project-ipv6-state`.
 > Plan-Scratch (historisch, teils überholt): `~/.claude/plans/pure-wibbling-graham.md`.
 
+## 🟢 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):
+WG-Peers säubern+enable, Spoke-Routen, **Input-Chain WAN-Seal** (🔴 ap1 bekommt Public-IP → Management/Resolver dicht),
+ether1 `use-peer-dns=no`. FM-`.conf`-Endpoint auf **`bf4…`** umgestellt. Klick-Anleitungen:
+`routeros/fritzbox-wg-lanlan-klickanleitung.md` (FM-FB) + `routeros/fritzbox-bf-bridge-cutover-klickanleitung.md` (BF-FB).
+Modus: **stagen → am Bridge-Tag 1× Apply + ether1 umstecken** (Runbook unten). FritzBox = kein MCP (UI/Klick).
+
 ## 🅿️ STATUS 2026-06-17: VERTAGT — gebündelt mit dem FB-Bridge-Cutover
 TP10 wird **nicht** mehr als Parallel-Migration vorab gemacht, sondern **zusammen mit dem permanenten FB-Bridge-Cutover**
 — denn **VPN-auf-FB und FB-Bridge schließen sich aus** (Bridge = Modem = keine VPN-Terminierung). Bonus: am Bridge-Tag
 hat **ap1 die echte Public-IP** → **kein FB-Port-Forward-Umweg** mehr, Spokes zeigen direkt auf ap1 (via DDNS).
-- **Beide VPN laufen vorerst über die BF-FB:** **FM = IPsec**, **DW = FB-WG** (Status quo, produktiv).
+- **Beide VPN laufen vorerst über die BF-FB:** ~~FM = IPsec~~ → **FM = FB-WG** (IPsec längst gekillt), **DW = FB-WG**.
 - **DW-Config ist aber schon bei Geli vor Ort gestaged** (2026-06-17, seltener Zugriff genutzt) — wird erst aktiv,
   wenn die ap1-Seite live geht (s.u. „Offen").
 
@@ -23,7 +30,7 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n
 | Hub `wg-hub` (ap1) | UDP **51821**, MTU 1412, **keine IF-IP**, Key `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=` |
 | **Endpoint (Spokes)** | **`bf4.emsenhuber.net:51821`** — DDNS via Cloudflare (Zone `emsenhuber.net`, **proxied=false**, TTL 120) → `86.56.201.104`. Überlebt IP-Wechsel **und** FB-Bridge. NICHT MyFRITZ (stirbt im Bridge). |
 | BF-Seite (AllowedIPs der Spokes) | `10.40.0.0/16` |
-| FM | LAN `10.101.0.0/24` (GW .254), war IPsec. FB-WG-`Address` = **`10.101.0.254/24`** (LAN-IP!) |
+| FM | LAN `10.101.0.0/24` (GW .254). **IPsec gekillt → bereits FB-WG** (peert heute mit BF-FB; FM-FB horcht auf `abxhutfgsid9snmy.myfritz.net:52476`, erreichbar/kein CGNAT). FB-WG-`Address` = **`10.101.0.254/24`** (LAN-IP!). Migration = Peer-Endpoint auf `bf4…:51821` umbiegen. ap1-peer1 bekommt FM-Endpoint → **bidirektional** |
 | DW/Geli | LAN heute `192.168.178.0/24` (GW .1), **CGNAT v4**, Antennengem. Geroldsgrün. Künftig **`10.95.10.0/24`**. FB-WG-`Address` = **`192.168.178.1/24, 10.95.10.1/24`** (Dual, renumber-fest) |
 | Keepalive | Spoke-Seite `PersistentKeepalive=25` (CGNAT-Dial-out) |
 
@@ -31,13 +38,19 @@ echte LAN-IPs, LAN-LAN sauber. (Gleiche Ursache wie der alte „NetBIOS routet n
 **ap1-Park-Zustand:** Peers **disabled**, WG-Routen **entfernt** (FM/DW laufen über FB-Default), `wg-hub` bleibt
 (Key erhalten), Firewall-Regeln bleiben (TP5-Vorarbeit). NAT braucht nichts (Egress wg-hub ≠ masq-Interface bridge/ether1).
 
-## ⏳ Offen — ap1-Seite aktivieren (sobald BF erreichbar; aktuell locked out)
+## ✅ ap1-Seite — gestaged in `routeros/tp10-cutover-apply.rsc` (am Bridge-Tag anwenden)
-- `peer2` (DW) enable/neu: `public-key=FqYZLztQ/qME5VDie5QLGH++5299WJiE1dPpQnPbzUw=` (unser Key; falls Gelis FB
+Das Skript erledigt idempotent (Live-Stand 2026-06-25 verifiziert):
-  **eigene** Keys erzeugt → deren Public-Key eintragen), **allowed-address = `192.168.178.0/24, 10.95.10.0/24`**, Endpoint leer.
+- **peer1 (FM)** allowed-address `10.101.0.0/24` (Transfernetz-/32 raus), enable. Key `dzRY0lnn…fyiVE=`.
-- Routen `192.168.178.0/24 → wg-hub` **und** `10.95.10.0/24 → wg-hub`.
+- **peer2 (DW)** allowed-address `192.168.178.0/24,10.95.10.0/24` (Transfernetz-/32 raus, künftiges Netz rein), enable.
-- `peer1` (FM) bleibt **disabled** (FM auf IPsec, vertagt bis Bridge-Tag).
+  Key `FqYZLztQ…PbzUw=` (falls Gelis FB **eigene** Keys erzeugt → deren Public-Key eintragen).
-- Verify: `list_wireguard_peers` Handshake; `/ping 10.101.0.10 src-address=10.40.20.1` bzw. ein Geli-Host → **Quelle muss
+- Routen `10.101.0.0/24`, `192.168.178.0/24`, `10.95.10.0/24` → `wg-hub`.
-  die echte LAN-IP sein**, nicht `10.255.255.x`. **NetBIOS-Lehre:** per IP/DNS testen (SMB 445), nie Broadcast/Netzwerkumgebung.
+- **Input-WAN-Seal** (est/rel · drop invalid · WG51821 · dhcp68 · icmp · LAN · **drop WAN**) — schließt
+  telnet/ftp/ssh/api/winbox/www + offenen Resolver/53 gegenüber dem Internet, sobald ether1 die Public-IP hat.
+- ether1-DHCP `use-peer-dns=no` (DoH bleibt einzige DNS-Quelle).
+
+Hinweis: **NAT, Forward-FW (wg-hub), Default-Fallback-Route, masquerade-ether1 sind bereits korrekt** — nicht im Skript.
+- Verify: `list_wireguard_peers` Handshake; SMB/445 per IP auf FM-/Geli-Host → **Quelle = echte LAN-IP**, nicht
+  `10.255.255.x`. **NetBIOS-Lehre:** per IP/DNS testen, nie Broadcast/Netzwerkumgebung.
 
 ## DW-Gotchas
 - **2 WG zum selben Zielnetz**: Gelis FB lehnt zwei WG-Verbindungen mit überlappenden AllowedIPs (`10.40.0.0/16`) ab

routeros/fritzbox-bf-bridge-cutover-klickanleitung.md

@@ -0,0 +1,58 @@
+# BF-FritzBox: Bridge/Passthrough + alte Tunnel abbauen — Klick-Anleitung
+
+> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der BF-FritzBox (FB 6660, Liwest, `10.40.41.254`).
+> ⚠️ FRITZ!OS-Labels sind versionsabhängig — wo unsicher, zählt die **Absicht**; sag mir, was die UI anbietet.
+> 🔗 Teil des permanenten Cutovers — Gesamtablauf: `routeros/wan-cutover-runbook.md` + `docs/tp10-vpn-migration.md`.
+
+## Ziel
+Die BF-FB gibt die **öffentliche Liwest-IPv4 per Passthrough an ap1-ether1** weiter → **ap1 wird der Edge** (Public-IP,
+VPN-Hub). Die FB verliert ihre Router-/VPN-Rolle, **Telefonie bleibt auf der FB** (separater Voice-Pfad, von der
+IPv4-Weitergabe unberührt). Mechanismus = **LAN4-Passthrough** (= der reversible Weg aus dem Test, **kein Liwest-Anruf
+nötig**). Optionaler späterer Schritt: echter DOCSIS-Bridge/Modem via Liwest-Support (sauberer, aber nicht erforderlich).
+
+## ⚠️ Reihenfolge — Hand in Hand mit ap1
+1. **FM-FB** hat die neue WG-`.conf` (bf4-Endpoint) — `fritzbox-wg-lanlan-klickanleitung.md`. DW: laut dir erledigt.
+2. **ap1-Apply** läuft (`routeros/tp10-cutover-apply.rsc`) — Hub scharf, WAN-Seal aktiv. **Erst danach** an die BF-FB.
+3. **DIESE Anleitung:** Passthrough an + ether1 umstecken. (Tunnel-Teardown unten erst **nach** Verify.)
+> Konsole während des Cutovers: **FB-WiFi → ap1 `10.40.41.1`** (WebFig) über ether2. **ether2 NIE ziehen.**
+
+---
+
+## Teil 1 — IPv4 an ap1 durchreichen (LAN4-Passthrough)
+`Internet → Zugangsdaten` (bzw. `Internet → ...`) → Funktion **„Gerät mit eigener öffentlicher IPv4" / „Passthrough"
+/ „Exposed Host an LAN4"** suchen.
+- **Absicht:** Die eine öffentliche Liwest-IPv4 wird **per DHCP an das Gerät an LAN4** (= ap1-ether1) übergeben.
+- Aktivieren, LAN4 als Passthrough-Port wählen, speichern.
+- Falls FRITZ!OS das nicht direkt anbietet: sag mir die vorhandenen Menüpunkte — dann lotse ich Feld für Feld
+  (alternativ DOCSIS-Bridge via Liwest-Anruf, dann ist die FB reines Modem).
+
+## Teil 2 — Umstecken
+- **ether1** von ap1 an den **FB-LAN4-Passthrough-Port**. **ether2 bleibt stecken** (Uplink/Konsole).
+- ap1-ether1 zieht jetzt Lease + **Public-IP**; Default-Route distance=1 übernimmt automatisch (Bridge-Fallback@2),
+  Egress masquerade-ether1 greift. → Prüfen via `mcp__mikromcp__list_dhcp_clients` (ether1 status=bound) und
+  `mcp__mikromcp__list_routes` (Default via ether1 aktiv).
+
+## Teil 3 — 🔴 DDNS abgleichen (sonst finden die Spokes den Edge nicht)
+- ether1-Public-IP lesen: `mcp__mikromcp__run_command` → `/ip address print where interface=ether1`.
+- **`bf4.emsenhuber.net`** (Cloudflare, Zone `emsenhuber.net`, **proxied=false**, TTL 120) auf **genau diese IP** setzen,
+  falls abweichend. *(ap1 kann device-mode-bedingt nicht selbst aktualisieren → vom Laptop/NAS aus.)*
+
+## Teil 4 — Verify (erst danach Tunnel abbauen!)
+- `mcp__mikromcp__list_wireguard_peers` → **peer1 (FM) und peer2 (DW) Handshake**, rx/tx > 0.
+- Von einem BF-Host **per IP** (kein NetBIOS/Broadcast): SMB/445 auf je einen FM- und DW-Host.
+- **Antwort-Quelle MUSS die echte LAN-IP sein** (z.B. `10.101.0.x` / Geli-LAN), **nicht** `10.255.255.x` (= FB-NAT).
+
+## Teil 5 — Alte AVM-Tunnel abbauen (nach grünem Verify)
+`Internet → Freigaben → Reiter „VPN (WireGuard)"`:
+- **Alte FM↔BF-FB-WG** **deaktivieren/löschen** — die WG-Kopplung, über die FM **bisher** lief (FM peerte mit der
+  BF-FB auf `xvbeo64…myfritz:51821`). Jetzt peert FM↔**ap1** (`bf4…:51821`). *(IPsec ist längst gekillt → dort nichts zu tun.)*
+- **Alte DW/Geli-FB-WG** (Server-Port **51820**) **deaktivieren/löschen**.
+  *(DW-Gotcha: Gelis FB lehnt 2 WG zum selben Zielnetz ab → der neue Geli↔ap1-Tunnel ersetzt den alten direkt; der
+  Swap auf Geli-Seite ist laut dir bereits erfolgt.)*
+- Portfreigabe **51821 → 10.40.41.1** wird im Passthrough hinfällig → entfernen.
+
+## Rollback (jederzeit, lockout-sicher)
+- **WAN zurück:** Passthrough an der FB aus → **ether1** zurück an einen normalen FB-LAN-Port. ap1 fällt über die
+  distance-2-Route via bridge automatisch in den Double-NAT zurück. **LAN bleibt durchgehend online** (ether2 unberührt).
+- **Tunnel:** alte IPsec/WG erst nach grünem Verify abschalten → bis dahin jederzeit reaktivierbar.
+- **ap1-Seite:** per `routeros/tp10-cutover-apply.rsc`-Umkehr (Peers disabled, Seal/Routen entfernen).

routeros/fritzbox-wg-lanlan-klickanleitung.md

@@ -1,8 +1,13 @@
 # FritzBox WireGuard als LAN-LAN-Kopplung (FM/DW-Spoke → ap1-Hub) — Klick-Anleitung
 
-> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der FritzBox. Beispiel FM-Standort
+> **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der FritzBox. FM-Standort
-> (`10.101.0.0/24`, GW `10.101.0.254`), aktuell produktiv über **IPsec**. Hub = ap1 (BF).
+> (`10.101.0.0/24`, GW `10.101.0.254`). **IPsec ist längst gekillt** → FM läuft bereits über **FB-WireGuard**
-> ⚠️ FRITZ!OS-Labels sind versionsabhängig — wo unsicher, zählt die **Absicht**.
+> (peert aktuell mit der **BF-FB** auf `xvbeo64…myfritz:51821`; FM-FB horcht selbst auf
+> `abxhutfgsid9snmy.myfritz.net:52476`). Hub = ap1 (BF). ⚠️ FRITZ!OS-Labels sind versionsabhängig — Absicht zählt.
+>
+> 🔗 **Teil des permanenten Cutovers** (`docs/tp10-vpn-migration.md` + `routeros/wan-cutover-runbook.md`).
+> Der Hub-Endpoint ist jetzt **`bf4.emsenhuber.net:51821`** (DDNS), **nicht** mehr MyFRITZ — denn die BF-FB
+> geht in den Bridge-Mode und verliert MyFRITZ + Portfreigabe. `bf4` zeigt direkt auf ap1-ether1 (Public-IP).
 
 ## 🎯 ROOT CAUSE (bestätigt 2026-06-16) + der Fix
 **Messung:** Ping auf realen FM-Host `10.101.0.10` über WG → Antwort kam aus **`10.255.255.2`** (Tunnel-IP) → **die FB
@@ -20,18 +25,27 @@ FB **muss ihre eigene LAN-IP** sein → dann routet die FB ihr LAN **ohne NAT**,
 |---|---|---|
 | **WG-Interface-Address (FB)** | **`10.101.0.254/24`** (LAN-IP!) | **`192.168.178.1/24`** (LAN-IP!) |
 | Erreichbare Netze / AllowedIPs (→Hub) | `10.40.0.0/16` | `10.40.0.0/16` |
-| Hub-Endpoint | `xvbeo64jqlqd9gfo.myfritz.net:51821` | dito (DW: CGNAT → wählt ausgehend) |
+| Hub-Endpoint | **`bf4.emsenhuber.net:51821`** | dito (DW: CGNAT → wählt ausgehend) |
 | Hub-Public-Key | `P/bztIk13cAmLHbN6oHGGnWAKLZsqR5TXAbFP+NGGBk=` | dito |
 | MTU / Keepalive | `1412` / `25` | `1412` / `25` |
 | Vorbereitete `.conf` | `routeros/.secrets/wg-fm.conf` | `routeros/.secrets/wg-dw.conf` |
 
 ## ⚠️ Sicherheit (FM ist produktiv!)
-- **IPsec bleibt an** = Sicherheitsnetz. Erst abschalten, wenn der Echt-Host-Test grün ist.
+- Die **bestehende FM↔BF-FB-WG bleibt an** = Sicherheitsnetz, bis der Echt-Host-Test über ap1 grün ist.
-- WG läuft parallel zu IPsec (kein Konflikt). ap1-Seite ist fertig — dort nichts ändern.
+- ap1-Seite kommt per `routeros/tp10-cutover-apply.rsc` (Hub scharf, peer1 mit FM-Endpoint) — dort nichts klicken.
 
 ---
 
-## Teil 1 — Bestehende (falsche) FM-WG-Verbindung entfernen
+## ⚡ Schnellpfad (wahrscheinlich ausreichend)
+FM ist **schon** auf WG mit korrektem LAN-IP-Modell (`Address=10.101.0.254/24`) — sonst liefe es nicht sauber.
+Dann ist die ganze Migration **ein Feld**: in der bestehenden FM-WG-Verbindung den **Peer-Endpoint** von
+`xvbeo64…myfritz.net:51821` (BF-FB) auf **`bf4.emsenhuber.net:51821`** (ap1) umbiegen — fertig.
+Erlaubt FRITZ!OS kein Bearbeiten des Endpoints → Verbindung **löschen + via `wg-fm.conf` neu importieren**
+(gleicher Key/Address, nur neuer Endpoint). **Nur wenn FM noch die alte Transfernetz-Adresse hat**, brauchst du
+Teil 1+2 unten.
+
+## Teil 1 — Bestehende (falsche, transfernetz-basierte) FM-WG-Verbindung entfernen
+*(Nur falls FM noch NICHT auf dem LAN-IP-Modell ist.)*
 `Internet → Freigaben → Reiter „VPN (WireGuard)"` → die FM-Verbindung **löschen** (sie hat die falsche
 Transfernetz-Adresse → NAT).
 
@@ -52,13 +66,15 @@ Transfernetz-Adresse → NAT).
 - peer1 allowed-address bleibt `10.101.0.0/24` (Transfernetz-/32 ist obsolet, schadet aber nicht).
 > Sag Bescheid — nicht-disruptiv per MikroMCP.
 
-## Teil 4 — Verifizieren, dann erst IPsec abschalten
+## Teil 4 — Verifizieren, dann erst die alte FM↔BF-FB-WG abbauen
-1. WG aktiv (IPsec an lassen). Ich pinge von ap1 sourced `10.40.20.1` → **`10.101.0.10`** + `torch wg-hub`:
+1. Neuer Tunnel aktiv (alte FM↔BF-FB-WG noch an lassen). Ich pinge von ap1 sourced `10.40.20.1` → **`10.101.0.10`**
-   - **Quelle = `10.101.0.10`** → ✅ kein NAT mehr, echtes LAN-LAN → weiter.
+   + `torch wg-hub`:
-   - Quelle = `10.255.255.2` → noch NAT → Adresse/Modus in Teil 2 nochmal prüfen.
+   - **Quelle = `10.101.0.10`** → ✅ kein NAT, echtes LAN-LAN → weiter.
+   - Quelle = `10.255.255.x` → noch NAT → Adresse/Modus prüfen (Teil 2).
 2. Gegenrichtung: FM-Host → BF-Host (NAS) per IP; **SMB/445 per IP** (NetBIOS-Lehre: per IP/DNS, kein Broadcast).
-3. Beide Richtungen grün → **IPsec für FM auf der BF-FB deaktivieren** → erneut testen.
+3. Beide Richtungen grün → **alte FM↔BF-FB-WG auf der BF-FB deaktivieren** → erneut testen.
-4. Stabil → FM migriert. **DW** danach gleich (Address `192.168.178.1/24`, CGNAT → ausgehend/Keepalive).
+4. Stabil → FM migriert. **DW** läuft analog (Address `192.168.178.1/24`, CGNAT → ausgehend/Keepalive).
 
 ## Rollback
-- WG an der FM-FB deaktivieren + IPsec aktivieren → Ausgangszustand. ap1-Seite unverändert lassen (inert).
+- Auf der FM-FB den Peer-Endpoint zurück auf `xvbeo64…myfritz:51821` (BF-FB) biegen bzw. die alte Verbindung
+  wieder aktivieren → Ausgangszustand. ap1-Seite ist inert, kann bleiben.

routeros/tp10-cutover-apply.rsc

@@ -0,0 +1,70 @@
+# =====================================================================
+# TP10 Cutover-Apply (ap1)  —  WG-Hub scharf + WAN-Input-Seal
+# =====================================================================
+# Zweck: ap1 in einem Rutsch von "geparkt" auf "Edge + VPN-Hub" bringen.
+# WANN ANWENDEN: am Bridge-Tag, SCHRITT 2 des Runbooks — VOR dem Umstecken
+#                von ether1 an den FB-Passthrough-Port.
+# SICHERHEIT: im Double-NAT harmlos — Peers warten auf die Spokes, der
+#             WAN-Drop trifft nur das (noch tote) ether1. Kein LAN-Lockout
+#             (Drop greift ausschliesslich in-interface-list=WAN = ether1).
+# IDEMPOTENT: alle Blöcke sind wiederholbar (find-Guards / set).
+# ROLLBACK:   Peers disabled=yes, WG-Routen + TP10-seal-* Regeln entfernen.
+#
+# Anwenden via MikroMCP:  upload_file -> run_script   (oder /import)
+# Vorab IMMER:            export_config / create_backup
+# ---------------------------------------------------------------------
+
+:log info "TP10-cutover: apply start"
+
+# --- A) WireGuard-Hub: Peers säubern (Transfernetz raus) + scharf schalten
+# peer1/FM: erreichbar (eigener myfritz-Endpoint, KEIN CGNAT) -> Endpoint setzen
+#           => bidirektional (ap1 ODER FM kann aufbauen). peer2/DW bleibt Dial-in (CGNAT, Endpoint leer).
+/interface/wireguard/peers
+set [find where name="peer1"] allowed-address=10.101.0.0/24 \
+  endpoint-address=abxhutfgsid9snmy.myfritz.net endpoint-port=52476 disabled=no
+set [find where name="peer2"] allowed-address=192.168.178.0/24,10.95.10.0/24 disabled=no
+
+# --- B) Routen zu den Spoke-Netzen (Gateway = Interface wg-hub)
+#       RouterOS leitet aus allowed-address KEINE Routen ab -> explizit.
+/ip/route
+:if ([:len [find where dst-address="10.101.0.0/24" gateway="wg-hub"]]=0) do={ \
+  add dst-address=10.101.0.0/24 gateway=wg-hub comment="TP10: FM spoke -> wg-hub" }
+:if ([:len [find where dst-address="192.168.178.0/24" gateway="wg-hub"]]=0) do={ \
+  add dst-address=192.168.178.0/24 gateway=wg-hub comment="TP10: DW spoke (heute) -> wg-hub" }
+:if ([:len [find where dst-address="10.95.10.0/24" gateway="wg-hub"]]=0) do={ \
+  add dst-address=10.95.10.0/24 gateway=wg-hub comment="TP10: DW spoke (kuenftig) -> wg-hub" }
+
+# --- C) Input-Chain abdichten (WAN-Seal). Reihenfolge oben->unten:
+#       est/rel | drop invalid | [WG 51821 vorhanden] | dhcp68 | icmp | LAN | drop WAN
+/ip/firewall/filter
+# 1+2 ueber die bestehende WG-Regel schieben (est zuerst, dann invalid)
+:if ([:len [find where comment="TP10-seal-est"]]=0) do={ \
+  add chain=input action=accept connection-state=established,related,untracked \
+    comment="TP10-seal-est" place-before=[find where comment="TP10: WG hub listen (51821)"] }
+:if ([:len [find where comment="TP10-seal-inv"]]=0) do={ \
+  add chain=input action=drop connection-state=invalid \
+    comment="TP10-seal-inv" place-before=[find where comment="TP10: WG hub listen (51821)"] }
+# 4-7 NACH der WG-Regel anhaengen (in dieser Reihenfolge)
+:if ([:len [find where comment="TP10-seal-dhcp"]]=0) do={ \
+  add chain=input action=accept protocol=udp dst-port=68 in-interface-list=WAN \
+    comment="TP10-seal-dhcp" }
+:if ([:len [find where comment="TP10-seal-icmp"]]=0) do={ \
+  add chain=input action=accept protocol=icmp comment="TP10-seal-icmp" }
+:if ([:len [find where comment="TP10-seal-lan"]]=0) do={ \
+  add chain=input action=accept in-interface-list=LAN comment="TP10-seal-lan" }
+:if ([:len [find where comment="TP10-seal-wandrop"]]=0) do={ \
+  add chain=input action=drop in-interface-list=WAN comment="TP10-seal-wandrop" }
+
+# --- D) ether1-DHCP-Client: kein ISP-DNS-Leak (DoH bleibt einzige Quelle)
+#       default-route-distance=1 ist bereits gesetzt (Auto-Switchover < Bridge-Fallback@2)
+/ip/dhcp-client
+set [find where interface="ether1"] use-peer-dns=no
+
+:log info "TP10-cutover: apply done"
+# =====================================================================
+# NICHT Teil dieses Skripts (bereits korrekt auf ap1):
+#   - NAT: masquerade out-interface=ether1 (*3) + no-NAT 10.40.0.0/16 (*4)
+#   - Forward-FW: accept in/out-interface=wg-hub (*E/*F)
+#   - Default-Fallback-Route 0.0.0.0/0 via 10.40.41.254 distance=2
+#   VPN-Traffic egresst ueber wg-hub -> matcht keine Masquerade -> echte LAN-IPs.
+# =====================================================================

routeros/wan-cutover-runbook.md

@@ -1,6 +1,13 @@
 # WAN-Cutover Runbook + Tutorial (ap1 / Liwest FB-Passthrough)
 
-> ## ⚠️ DAS IST EIN REVERSIBLER TEST — KEIN PERMANENTER UMSTIEG
+> ## 🟢 UPDATE 2026-06-25: jetzt der PERMANENTE Cutover (TP10 gekoppelt)
+> Die Tunnel-Sperre ist gelöst: TP10 ist **cutover-ready**. Der permanente Ablauf (FM-FB → ap1-Apply → Passthrough →
+> DDNS → Verify → alte Tunnel abbauen) steht in `docs/tp10-vpn-migration.md` + den Klick-Anleitungen
+> `routeros/fritzbox-bf-bridge-cutover-klickanleitung.md` (BF-FB) und `routeros/fritzbox-wg-lanlan-klickanleitung.md` (FM-FB).
+> ap1-Apply = **`routeros/tp10-cutover-apply.rsc`**. Das Folgende bleibt als **Test-/Diagnose- und Rollback-Referenz** gültig
+> (Verkabelung, Konsolenpfad, `wantest-*`/`wanmac-*`, Sicherheitsnetze — alles weiterhin korrekt).
+
+> ## ⚠️ Ursprünglich: REVERSIBLER TEST — die Reversibilität gilt weiter bis zum Tunnel-Teardown
 > Die FritzBox bleibt **produktiver Router + VPN-Endpunkt + Telefon**. Wir testen nur, ob der
 > Bridge/Passthrough-Mode sauber funktioniert, sammeln Diagnose-Daten und **bauen danach zurück**.
 > **Grund:** Die BF-FritzBox terminiert aktuell **2 Site-to-Site-Tunnel** (AVM LAN-LAN: 1× IPsec +