BF-FritzBox: Bridge/Passthrough + alte Tunnel abbauen — Klick-Anleitung

Methode: Claude erklärt Absicht + Klickpfad, du klickst an der BF-FritzBox (FB 6660, Liwest, 10.40.41.254). ⚠️ FRITZ!OS-Labels sind versionsabhängig — wo unsicher, zählt die Absicht; sag mir, was die UI anbietet. 🔗 Teil des permanenten Cutovers — Gesamtablauf: routeros/wan-cutover-runbook.md + docs/tp10-vpn-migration.md.

Ziel

Die BF-FB gibt die öffentliche Liwest-IPv4 per Passthrough an ap1-ether1 weiter → ap1 wird der Edge (Public-IP, VPN-Hub). Die FB verliert ihre Router-/VPN-Rolle, Telefonie bleibt auf der FB (separater Voice-Pfad, von der IPv4-Weitergabe unberührt). Mechanismus = LAN4-Passthrough (= der reversible Weg aus dem Test, kein Liwest-Anruf nötig). Optionaler späterer Schritt: echter DOCSIS-Bridge/Modem via Liwest-Support (sauberer, aber nicht erforderlich).

⚠️ Reihenfolge — Hand in Hand mit ap1

FM-FB hat die neue WG-.conf (bf4-Endpoint) — fritzbox-wg-lanlan-klickanleitung.md. DW: laut dir erledigt.
ap1-Apply läuft (routeros/tp10-cutover-apply.rsc) — Hub scharf, WAN-Seal aktiv. Erst danach an die BF-FB.
DIESE Anleitung: Passthrough an + ether1 umstecken. (Tunnel-Teardown unten erst nach Verify.)

Konsole während des Cutovers: FB-WiFi → ap1 10.40.41.1 (WebFig) über ether2. ether2 NIE ziehen.

Teil 1 — IPv4 an ap1 durchreichen (LAN4-Passthrough)

Internet → Zugangsdaten (bzw. Internet → ...) → Funktion „Gerät mit eigener öffentlicher IPv4" / „Passthrough" / „Exposed Host an LAN4" suchen.

Absicht: Die eine öffentliche Liwest-IPv4 wird per DHCP an das Gerät an LAN4 (= ap1-ether1) übergeben.
Aktivieren, LAN4 als Passthrough-Port wählen, speichern.
Falls FRITZ!OS das nicht direkt anbietet: sag mir die vorhandenen Menüpunkte — dann lotse ich Feld für Feld (alternativ DOCSIS-Bridge via Liwest-Anruf, dann ist die FB reines Modem).

Teil 2 — Umstecken

ether1 von ap1 an den FB-LAN4-Passthrough-Port. ether2 bleibt stecken (Uplink/Konsole).
ap1-ether1 zieht jetzt Lease + Public-IP; Default-Route distance=1 übernimmt automatisch (Bridge-Fallback@2), Egress masquerade-ether1 greift. → Prüfen via mcp__mikromcp__list_dhcp_clients (ether1 status=bound) und mcp__mikromcp__list_routes (Default via ether1 aktiv).

Teil 3 — 🔴 DDNS abgleichen (sonst finden die Spokes den Edge nicht)

ether1-Public-IP lesen: mcp__mikromcp__run_command → /ip address print where interface=ether1.
bf4.emsenhuber.net (Cloudflare, Zone emsenhuber.net, proxied=false, TTL 120) auf genau diese IP setzen, falls abweichend. (ap1 kann device-mode-bedingt nicht selbst aktualisieren → vom Laptop/NAS aus.)

Teil 4 — Verify (erst danach Tunnel abbauen!)

mcp__mikromcp__list_wireguard_peers → peer1 (FM) und peer2 (DW) Handshake, rx/tx > 0.
Von einem BF-Host per IP (kein NetBIOS/Broadcast): SMB/445 auf je einen FM- und DW-Host.
Antwort-Quelle MUSS die echte LAN-IP sein (z.B. 10.101.0.x / Geli-LAN), nicht 10.255.255.x (= FB-NAT).

Teil 5 — Alte AVM-Tunnel abbauen (nach grünem Verify)

Internet → Freigaben → Reiter „VPN (WireGuard)":

Alte FM↔BF-FB-WG deaktivieren/löschen — die WG-Kopplung, über die FM bisher lief (FM peerte mit der BF-FB auf xvbeo64…myfritz:51821). Jetzt peert FM↔ap1 (bf4…:51821). (IPsec ist längst gekillt → dort nichts zu tun.)
Alte DW/Geli-FB-WG (Server-Port 51820) deaktivieren/löschen. (DW-Gotcha: Gelis FB lehnt 2 WG zum selben Zielnetz ab → der neue Geli↔ap1-Tunnel ersetzt den alten direkt; der Swap auf Geli-Seite ist laut dir bereits erfolgt.)
Portfreigabe 51821 → 10.40.41.1 wird im Passthrough hinfällig → entfernen.

Rollback (jederzeit, lockout-sicher)

WAN zurück: Passthrough an der FB aus → ether1 zurück an einen normalen FB-LAN-Port. ap1 fällt über die distance-2-Route via bridge automatisch in den Double-NAT zurück. LAN bleibt durchgehend online (ether2 unberührt).
Tunnel: alte IPsec/WG erst nach grünem Verify abschalten → bis dahin jederzeit reaktivierbar.
ap1-Seite: per routeros/tp10-cutover-apply.rsc-Umkehr (Peers disabled, Seal/Routen entfernen).

4.3 KiB Raw Permalink Blame History