# VM 101 ↔ Horus WireGuard tot — Ursache war NAT, nicht die Keys

**Datum:** 2026-06-28  
**Status:** gelöst  
**Betroffen:** WireGuard-Tunnel VM 101 (`server5`, `10.1.1.5`) ↔ Horus VPS (`10.1.1.1`)

---

## Symptom

- `ping 10.1.1.1` von VM 101 → 100 % Loss, **0 Bytes empfangen**
- WireGuard-Handshake auf VM 101 kam nie zustande (latest handshake blieb stehen)
- Der **OPNsense**-Tunnel zu Horus (`10.1.1.22`) lief dagegen normal weiter

## Falsche Spur (kostete viel Zeit)

Das Vorgänger-Handover führte alles auf **Key-/PSK-Chaos** zurück („kimi hat die Keys verstellt"). Das war für **dieses** Problem **falsch**:

- VM-101-Seite: PrivateKey → Pubkey `VB3Cf8kD…`, PSK `xeXr67…` — korrekt
- Horus-Seite (Peer `VB3Cf8kD…`): **identischer** PSK `xeXr67…`, korrekte AllowedIPs `10.1.1.5/32, 10.2.2.0/24`
- Probeweises Setzen anderer PSKs (OPNsense-PSK `fBnIJ…`, leer) brachte **keinen** Handshake → es war kein Crypto-Problem

## Diagnose, die zur Wahrheit führte

Mit Root auf Horus (Zugang siehe unten) Paketfluss direkt gemessen:

```
# Auf Horus, tcpdump während VM 101 sendet:
In   93.199.218.174:46165 → 207.180.222.207:61951   UDP len 148  (Handshake-Init kommt an)
Out  207.180.222.207:61951 → 93.199.218.174:46165   UDP len 92   (Handshake-Response geht raus)
# Auf VM 101 gleichzeitig: In = 0  (Antwort kommt NIE an)
```

→ **Hinweg VM 101 → Horus OK, Rückweg Horus → VM 101 tot.** Horus antwortete korrekt an den Quellport (`:46165`), aber das Paket erreichte VM 101 nie.

## Echte Ursache

VM 101 sitzt hinter OPNsense (NAT). Ihr WireGuard nutzte den **festen** Quellport `61951`, der **konstant** auf WAN-Port `46165` ge-NAT-et wurde. Durch kimis `qm stop 104` + manuelle Wiederherstellung wurde der **NAT-/State-Tisch von OPNsense durchgewirbelt** — diese eine, langlebige Zuordnung `61951↔46165` war danach **verwaist**: Hinweg funktionierte, der Rückweg lief ins Leere.

Da **UDP** verbindungslos ist, merkte WireGuard nichts und sendete endlos weiter, ohne je eine Antwort zu sehen. (Bezeichnend: **TCP-SSH** von VM 101 zu Horus' Public-IP ging — frischer Zufalls-Port = frische, gesunde NAT-Zuordnung.)

## Lösung

**Frischen Quellport auf der Client-Seite erzwingen** → neue, saubere NAT-Zuordnung:

```bash
# Auf VM 101:
sudo wg set wg0 listen-port 51871          # Live-Test → Handshake sofort da
sudo sed -i 's/^ListenPort = 61951/ListenPort = 51871/' /etc/wireguard/wg0.conf   # persistent
```

- **Nur Client-Seite (VM 101) geändert.** Horus' Port `61951` und alle Keys blieben unverändert.
- **Kein** Eingriff an OPNsense / VM 104.
- Reboot-getestet: `systemctl restart wg-quick@wg0` → kommt auf `51871` hoch, Handshake < 3 s.

## Verifikation

- `ping 10.1.1.1` von VM 101 → 3/3, ~24 ms
- SSH durch den Tunnel (`ssh root@10.1.1.1`) wieder OK
- Überlebt wg-Neustart

## Nützliche Zugangswege (für nächstes Mal)

- **Horus Root, wenn Tunnel läuft:** `ssh jean@192.168.10.10` → `ssh root@10.1.1.1`
- **Horus Root, wenn Tunnel tot ist:** über die **Public-IP** `ssh root@207.180.222.207` — aber nur erreichbar, wenn auf Horus per ufw Port 22 offen ist (Notfall: am Contabo-VNC `ufw allow ssh`, danach wieder `ufw delete allow ssh`). VM 101 hat den Horus-SSH-Key, geht also auch von dort über die Public-IP.
- **Horus WireGuard wird per `wireguard-ui` verwaltet**, Config-Datei `/etc/wireguard/wg0.conf` (nicht manuell editieren — wird regeneriert). Live-Kernel vs. Datei können auseinanderlaufen; Wahrheit ist `wg show wg0` / `wg showconf wg0`.
- VM 101 hat **kein** wireguard-ui — nur `wg-quick@wg0`.

## Prävention / offene Risiken

- Der eigentliche Übeltäter — **OPNsenses fragiler NAT/CARP-Zustand nach dem VM-104-Stop** — besteht weiter. Wird dort erneut State geflusht (Reboot/Failover), kann ein WireGuard-Tunnel wieder „einschlafen". Workaround dann: Client-Port wechseln.
- Lehre: Bei „Handshake-Init kommt an, aber 0 empfangen" **zuerst den Rückweg/NAT prüfen** (tcpdump auf beiden Seiten), nicht stundenlang an PSK/Keys.
- **VM 104 / OPNsense** nie per `qm stop/start` anfassen (Auslöser dieses ganzen Vorfalls).