macOS-Desktop-Sonos-App braucht SSDP über VLAN-Grenze; iOS/HA reichen für den
Alltag nicht, sobald der User die Desktop-App nutzen will. Reflector-Container
auf NAS/pve (nicht am hAP), Scope vlan10↔vlan40.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause: ap2 (CAP, local forwarding) hatte bridge vlan-filtering=no →
datapath.vlan-id wurde nie getaggt → alle WLAN-Clients (main/media/iot/…)
egressten ungetaggt in VLAN1 → OG-iPhone-Drops beim Roaming ap1↔ap2.
Fix wie ap1: VLAN1 untagged=bridge,ether2 (Mgmt), 10/30/40/50/90 tagged
auf ether2 + wifi1/wifi2 als tagged-Member (nur Master-Radios sind
Bridge-Ports, CAPsMAN legt das auf dem CAP nicht an). As-built +
teilprojekte.md TP3.1 + CLAUDE.md-Gotcha. OG-Funktionstest offen (User).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DW/Geli on-site abgeschlossen (2026-06-27): Geli auf 10.95.10.0/24
renumbert, FB-WG single 10.95.10.1/24, alter FB↔FB-WG geswappt.
End-to-End verifiziert (macmini/Linz → Gelis 24/7-APs .246/.247,
echte LAN-IPs, kein 10.255.255.x-NAT-Leak). FM+DW live im Double-NAT.
Doku/Status von "🅿️ vertagt/geparkt" auf Ist-Stand gezogen, Bridge-Gate
an allen Stellen aufgelöst, stale 192.168.178-Referenzen bereinigt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- tp10-vpn-migration.md zur Single Source of Truth umgeschrieben: widerspruechliche
alte Transfernetz-Tabelle/MyFRITZ-Endpoint entfernt, aktueller Stand (Proxy-ARP
LAN-IP, DDNS bf4.emsenhuber.net, dual-range DW, geparkter ap1-Hub, vertagt+
gebuendelt mit Bridge-Cutover, v6-Variante) konsolidiert.
- teilprojekte.md TP10-Eintrag von verbose Saga auf kompakten Status + Verweis gekuerzt.
- tp10-context-digest.md neu: ultrakompakter Handoff (lokal via Ollama nemotron-3-nano:4b
destilliert, fakten-gegengeprueft) fuer kleines Kontextfenster.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Entscheidung: TP10 nicht mehr als Parallel-Migration vorab, sondern zusammen
mit dem permanenten FB-Bridge-Cutover. Grund: VPN-auf-FB und FB-Bridge
schließen sich aus (Bridge = Modem = keine VPN-Terminierung) -> Migration muss
am Bridge-Tag passieren; dann hat ap1 die echte Public-IP -> kein
Port-Forward-Umweg, Spokes zeigen direkt auf ap1/DDNS. FM-PoC hat den
WG-Spoke-Fix bewiesen (de-risked).
Park-Zustand ap1: Peers disabled, WG-Routen entfernt (FM/DW wieder über die FB),
wg-hub bleibt (Key erhalten), Firewall bleibt (TP5-Vorarbeit). Beide VPN vorerst
über die FB: FM=IPsec, DW=FB-WG. Resume = Bridge-Tag (Klickanleitung,
FB-LAN-IP als Interface-Address).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Gelis CGNAT ist nur v4 → ihre FB über natives v6 erreichbar (Port offen).
WARP (schon im Einsatz) liefert Christoph outbound-v6 trotz Liwest-v4-only.
- PoC = ad-hoc Fernwartung; Daueform = direktes WG ap1↔Geli-FB über echtes
v6 (HE-6in4, da Liwest auch mit Fiber kein v6) statt Hub-Spoke-Gymnastik.
- Endgeräte (Note10, Cudy) bleiben v6-agnostisch: v6 nur äußerer Transport,
LAN bleibt IPv4. Nicht für Telefonie.
- teilprojekte.md: TP10 von ⏸ PAUSIERT auf 🅿️ VERTAGT (Bridge-Cutover-Bündelung).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
FM-Cutover-Versuch gescheitert: .conf importiert, Handshake grün, IPsec voreilig
deaktiviert -> FM unerreichbar. Diagnose-Fehler: nur FB-eigene .254 gepingt (FB
antwortet aus Tunnel-IP 10.255.255.2 -> OS verwirft); echte FM-LAN-Hosts nie
getestet -> NAT-These unbewiesen. Research (Bouni) bestätigt FB<->MikroTik
LAN-LAN ohne NAT ist machbar. FM auf IPsec zurückgestellt; ap1-WG-Hub bleibt inert.
- routeros/fritzbox-wg-lanlan-klickanleitung.md: Diagnose->Fix->Verify, Echt-Host-
Test ZUERST (10.101.0.10, nicht .254), IPsec bleibt Sicherheitsnetz.
- teilprojekte.md / tp10-vpn-migration.md: Status ⏸ + Incident dokumentiert.
Spoke-.conf mit Private-Keys bleiben gitignored in routeros/.secrets/ (die
ungetrackten Duplikate in routeros/ Root sind bewusst NICHT committet).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Variante A (BIND/RFC2136) verworfen: HW-Vorgabe "Container nur am Router
oder gar nicht, keine NAS/pve-Abhaengigkeit" + hAP kann praktikabel keinen
DNS-Container hosten (live: ~90MB frei, kein USB, Flash-Wear).
- research-Doc umgeschrieben: Entscheidung + Variante A als parkierter Anhang
- teilprojekte TP4 auf finale Entscheidung
- technitium/ -> dns/ umbenannt + README
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>