Christoph Emsenhuber
919f8623c9
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>
65 lines
4.2 KiB
Markdown
65 lines
4.2 KiB
Markdown
# 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
|
|
1. 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.
|
|
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 → **IPsec für FM auf der BF-FB deaktivieren** → erneut testen.
|
|
4. 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).
|