# Handoff 2026-09-28 — Core erreicht FM/DW-Spoke-Netze nicht aus eigener Kraft

## Kontext / Auslöser
Christoph konnte von Notebook + macmini immer `10.101.0.254` (FM-Standort-GW) pingen, eine
überforderte Vorgänger-Session hatte behauptet, der Core „komme dort nicht hin". Befund
sollte jetzt geprüft und ausgeräumt werden.

## Befund (alles live verifiziert 2026-09-28, crs326-core)
| Quelle | → 10.101.0.254 (FM-GW) | → 10.101.0.10 (FM-Host) |
|---|---|---|
| macmini (VLAN20, gw 10.40.20.1) | ✅ 0 % Loss | ✅ 0 % Loss |
| Notebook (VLAN10, gw 10.40.10.1) | ✅ 0 % Loss | ✅ 0 % Loss |
| **Core default** (`/ping` ohne src) | ❌ **100 % Loss** | ❌ **100 % Loss** |
| **Core mit `src-address=10.40.10.1`** | ✅ **0 % Loss** (ttl 64) | ✅ **0 % Loss** (ttl 63) |

## Root Cause
`wg-hub` (TP10 Multi-Site VPN Hub) hat **keine IP-Adresse** — weder live
(`/ip address print where interface="wg-hub"` → leer) noch im GC-Template
(`mikrotik_routeros.j2:379`, nur listen-port/mtu/name/private-key).

FM-seitig erlaubt die FritzBox als AllowedIPs Richtung Hub `10.40.0.0/16`
(`routeros/fritzbox-wg-lanlan-klickanleitung.md`). Weitergeleiteter Client-Traffic
(Quell-IP 10.40.x) liegt in diesem Raum → läuft. **Core-eigener** Traffic ohne
explizite Quell-IP: RouterOS wählt mangels IP auf wg-hub eine Quell-IP **außerhalb**
von 10.40.0.0/16 (vermutlich WAN `90.146.33.177`) → FM routet die Antwort nicht zurück
→ Timeout. Der Tunnel selbst ist up (FM-Peer last-handshake ~1m45s, rx 140.8 GiB).

## SSoT / Governance
Die Core-Config liegt im GC-Template `nautobot/mikrotik_routeros.j2`. Dort existieren:
- `:375` `/ip route add ... dst-address=10.101.0.0/24 gateway=wg-hub comment="TP10: FM spoke"`
- `:376` `/ip route add ... dst-address=10.95.10.0/24 gateway=wg-hub comment="TP10: DW spoke"`
- `:379-381` wg-hub Interface + fm/dw Peers (Privkey redacted)

Ein Fix gehört **ins Template**, nicht als Direkt-Write aufs Gerät (GC-Compliance-Regel).
Deploy via `nautobot/gc-configplan.py` / GC-Job „Backup → Intended → Compliance".

## Fix-Optionen (noch nicht entschieden)
1. **`preferred-source` auf die zwei TP10-Routen** (Zeile 375/376, z. B. `10.40.10.1`).
   Kein FM-Eingriff nötig (FM erlaubt 10.40.0.0/16 bereits). Minimal-invasiv. **Empfohlen.**
2. wg-hub eine IP geben (z. B. dedizierte Adresse aus 10.40.0.0/16) — mehr Risiko, IP-Raum-
   Eingriff, FM-Abgleich nötig.
3. FM-seitig AllowedIPs um die Core-WAN-IP erweitern — FritzBox-WG-Config eingeschränkt, nicht sauber.

## Offene Entscheidungen
- Welche `preferred-source`-IP? (10.40.10.1 = MAIN-SVI ist naheliegend.)
- TP10 ist im Archiv „KERN DURCH, offen nur DDNS-Updater". Neuer Befund → TP10-Issue
  `reopen` + Prosa zurück nach `teilprojekte.md`, oder als eigenes kleines TP? (Christoph-Entscheid.)
- Fix jetzt ausführen oder nur dokumentieren?

## Aufwandsschätzung (Core-Ping-Fix)
Klein. 2 Zeilen Template-Edit + ein GC-Deploy-Zyklus (~30–60 min inkl. Backup/Intended/Compliance)
+ Ping-Verifikation. Kein Hardware-/FM-Eingriff bei Option 1.