# 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).