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, GW10.101.0.254). IPsec ist längst gekillt → FM läuft bereits über FB-WireGuard (peert aktuell mit der BF-FB aufxvbeo64…myfritz:51821; FM-FB horcht selbst aufabxhutfgsid9snmy.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 jetztbf4.emsenhuber.net:51821(DDNS), nicht mehr MyFRITZ — denn die BF-FB geht in den Bridge-Mode und verliert MyFRITZ + Portfreigabe.bf4zeigt 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), nicht10.255.255.2/32. Transfernetz10.255.255.0/24komplett 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.confimportieren — die hat jetzt die korrekteAddress = 10.101.0.254/24. - Kernpunkt: Die WG-Interface-Adresse dieser Verbindung muss
10.101.0.254/24sein (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
peer1auf 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
- Neuer Tunnel aktiv (alte FM↔BF-FB-WG noch an lassen). Ich pinge von ap1 sourced
10.40.20.1→10.101.0.10torch 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).
- Gegenrichtung: FM-Host → BF-Host (NAS) per IP; SMB/445 per IP (NetBIOS-Lehre: per IP/DNS, kein Broadcast).
- Beide Richtungen grün → alte FM↔BF-FB-WG auf der BF-FB deaktivieren → erneut testen.
- 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):
- FB-LAN renumbern:
Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv4-Adressen→ FB-LAN-IP10.95.10.1, Maske255.255.255.0, DHCP-Range10.95.10.x. (Geli-Geräte ziehen neue Leases.) - WG-
Addressder ap1-Verbindung auf10.95.10.1/24(single) setzen — das192.168.178.1/24raus. - ap1-Seite ist schon fertig:
peer dwallowed-address =10.95.10.0/24, Route10.95.10.0/24 → wg-hub. - Verify: ap1-Ping (src
10.40.20.1) auf einen echten Geli-Host10.95.10.x→ Antwort aus derselben IP (nicht aus.1, nicht aus10.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.