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

6.7 KiB

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.