bf-infra/routeros/fritzbox-wg-lanlan-klickanleitung.md

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