# FritzBox WireGuard als LAN-LAN-Kopplung (FM/DW-Spoke → ap1-Hub) — Klick-Anleitung > **Methode:** Claude erklärt Absicht + Klickpfad, **du klickst** an der FritzBox. FM-Standort > (`10.101.0.0/24`, GW `10.101.0.254`). **IPsec ist längst gekillt** → FM läuft bereits über **FB-WireGuard** > (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 masqueradet den Tunnel.** Ursache: unsere `.conf` hatte als Interface-`Address` eine **Transfernetz-IP** (`10.255.255.2/32`) → FRITZ!OS behandelt das als **Einzelgerät** und NAT't. **AVM-Modell:** FRITZ!OS nutzt für WG-LAN-LAN **kein Transfernetz, sondern Proxy-ARP**. Die WG-Interface-Adresse der FB **muss ihre eigene LAN-IP** sein → dann routet die FB ihr LAN **ohne NAT**, echte Host-IPs. > **DER FIX (eine Zeile):** FB-WG-Interface-`Address` = **`10.101.0.254/24`** (FM-LAN-IP), **nicht** `10.255.255.2/32`. > Transfernetz `10.255.255.0/24` **komplett streichen**. ## Eckdaten (FM; DW analog) | Feld | Wert FM | Wert DW | |---|---|---| | **WG-Interface-Address (FB)** | **`10.101.0.254/24`** (LAN-IP!) | **`10.95.10.1/24`** (LAN-IP! **single**, nach Renumber) | | Erreichbare Netze / AllowedIPs (→Hub) | `10.40.0.0/16` | `10.40.0.0/16` | | 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!) - Die **bestehende FM↔BF-FB-WG bleibt an** = Sicherheitsnetz, bis der Echt-Host-Test über ap1 grün ist. - ap1-Seite kommt per `routeros/tp10-cutover-apply.rsc` (Hub scharf, peer1 mit FM-Endpoint) — dort nichts klicken. --- ## ⚡ 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). ## Teil 2 — Neu als LAN-LAN-Kopplung anlegen `„Verbindung hinzufügen"` → Typ **„Netzwerke koppeln" / „LAN-LAN"** wählen (**nicht** „Einzelnes Gerät"). - Falls FRITZ!OS dort nur den **FB↔FB**-Assistenten anbietet: stattdessen **benutzerdefinierte/importierte Config** und **`routeros/.secrets/wg-fm.conf`** importieren — die hat jetzt die korrekte `Address = 10.101.0.254/24`. - **Kernpunkt:** Die WG-Interface-Adresse dieser Verbindung muss **`10.101.0.254/24`** sein (die FB-LAN-IP), erreichbares Netz Richtung Hub = **`10.40.0.0/16`**. **„Gesamten Internetverkehr über VPN" = AUS.** - ⚠️ Falls der Import eine LAN-IP als Interface-Adresse **ablehnt** (Überlapp mit dem LAN): dann den AVM-Wizard „Netzwerke koppeln" nutzen und dort die **lokale FB-IP** als Verbindungs-IP eintragen (das ist genau der Proxy-ARP-Weg). Sag mir, was die UI anbietet — dann lotse ich Feld für Feld. - **Public-Key** der Verbindung notieren → mir geben, falls FRITZ!OS einen **eigenen** Key erzeugt (dann gleiche ich `peer1` auf ap1 ab; aktuell steht dort der Key aus unserer `.conf`). ## Teil 3 — ap1-Abgleich (mache ich, falls nötig) - Falls FB neuen Key erzeugt: `peer1`-Public-Key aktualisieren. - 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 die alte FM↔BF-FB-WG abbauen 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`** + `torch wg-hub`: - **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 → **alte FM↔BF-FB-WG auf der BF-FB deaktivieren** → erneut testen. 4. Stabil → FM migriert. **DW** läuft analog (CGNAT → ausgehend/Keepalive), aber Single-Address — siehe unten. ## DW-Spezial: Renumber auf 10.95.10.0/24 + Single-Address (LEHRE 2026-06-25) **Symptom war:** Tunnel stand (Handshake ✓, rx/tx ✓), aber **BF→Geli-Host per IP ging nicht**; ap1-Ping auf `192.168.178.1` **und** `10.95.10.1` kam immer aus `10.95.10.1` zurück. **Ursache:** Die WG-`Address` war **Dual** (`192.168.178.1/24, 10.95.10.1/24`). FRITZ!OS macht daraus `10.95.10.1` als **Primäradresse** und koppelt das echte LAN (`192.168.178.0/24`) **nicht** mehr → kein Host-Routing. **Regel:** WG-`Address` = **GENAU EINE** Adresse = die **aktuelle** FB-LAN-IP. Kein Dual, kein Vorab-Netz. **Vorgehen bei Geli (vor Cutoff):** 1. **FB-LAN renumbern:** `Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv4-Adressen` → FB-LAN-IP **`10.95.10.1`**, Maske `255.255.255.0`, DHCP-Range `10.95.10.x`. (Geli-Geräte ziehen neue Leases.) 2. **WG-`Address`** der ap1-Verbindung auf **`10.95.10.1/24`** (single) setzen — das `192.168.178.1/24` raus. 3. ap1-Seite ist schon fertig: `peer dw` allowed-address = `10.95.10.0/24`, Route `10.95.10.0/24 → wg-hub`. 4. **Verify:** ap1-Ping (src `10.40.20.1`) auf einen **echten** Geli-Host `10.95.10.x` → Antwort aus **derselben** IP (nicht aus `.1`, nicht aus `10.255.255.x`). Dann BF↔Geli per IP/SMB testen. ## Rollback - 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.