Files

Christoph Emsenhuber 919f8623c9 TP10 🎯 Root Cause FM-NAT gefunden: FB braucht LAN-IP als WG-Address (Proxy-ARP)

Echt-Host-Test (Ping realer 10.101.0.10 über WG) -> Antwort aus 10.255.255.2
=> FB masqueradet den Tunnel, bestätigt. Ursache: .conf nutzte Transfernetz-
Adresse (10.255.255.2/32) -> FRITZ!OS = Einzelgerät-Modus = NAT. AVM nutzt
Proxy-ARP statt Transfernetz -> FB-WG-Interface-Address muss die FB-LAN-IP sein
(FM 10.101.0.254/24, DW 192.168.178.1/24), Transfernetz streichen, AllowedIPs
10.40.0.0/16. -> WG-Spoke-Ansatz damit machbar.

- fritzbox-wg-lanlan-klickanleitung.md: Root Cause + One-Field-Fix (LAN-IP als
  Address), LAN-LAN-Wizard, Verify gegen 10.101.0.10.
- teilprojekte.md / tp10-vpn-migration.md: Status "Root Cause gefunden, machbar".

Korrigierte Spoke-Configs in routeros/.secrets/wg-{fm,dw}.conf (gitignored).
FM bleibt auf IPsec (Sicherheitsnetz); ap1-WG-Hub inert.

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

2026-06-17 00:15:32 +02:00

4.2 KiB

Raw Blame History

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 (10.101.0.0/24, GW 10.101.0.254), aktuell produktiv über IPsec. Hub = ap1 (BF). ⚠️ FRITZ!OS-Labels sind versionsabhängig — wo unsicher, zählt die Absicht.

🎯 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!)	`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-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.
WG läuft parallel zu IPsec (kein Konflikt). ap1-Seite ist fertig — dort nichts ändern.

Teil 1 — Bestehende (falsche) FM-WG-Verbindung entfernen

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 IPsec abschalten

WG aktiv (IPsec 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 mehr, echtes LAN-LAN → weiter.
- Quelle = 10.255.255.2 → noch NAT → Adresse/Modus in Teil 2 nochmal prüfen.
Gegenrichtung: FM-Host → BF-Host (NAS) per IP; SMB/445 per IP (NetBIOS-Lehre: per IP/DNS, kein Broadcast).
Beide Richtungen grün → IPsec für FM auf der BF-FB deaktivieren → erneut testen.
Stabil → FM migriert. DW danach gleich (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).

4.2 KiB Raw Blame History