docu/issues/2026-06-28-vm101-horus-wireguard-nat.md

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:

# 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).