Plötzlicher Dienstausfall bei laufendem System trotz stabiler WireGuard-Verbindung

Hallo zusammen,

ich bin auf ein merkwürdiges Verhalten gestoßen, das ich nun schon zweimal beobachten konnte und für das ich bisher keine Ursache identifizieren konnte.

Ausgangslage

• Server: Netcup-Rootserver mit Ubuntu Server 22.04.5 LTS, täglich über Ubuntu Pro live gepatcht.

• Dienste:

  • hestia.service aktiv seit Sat 2025-05-31 18:26:36 CEST

  • nginx.service ebenfalls aktiv seit Sat 2025-05-31 18:26:36 CEST

• Zugänge:

  • HestiaCP

  • SSH

  • Weitere interne Dienste per WireGuard erreichbar

• VPN: WireGuard-Tunnel aktiv zu meinem Heimnetz:

  Code

  [Interface]
  Address = 192.168.178.135/24,fd4e:6fb7:3f1::135/64
  DNS = 192.168.178.109,192.168.178.1,fd4e:6fb7:3f1::2e91:abff:fe28:31cb, fritz.box
  ListenPort = 5xxx5
  
  [Peer]
  Endpoint = DYNDNS.srv64.de:50120
  AllowedIPs = 192.168.178.0/24,fd4e:6fb7:3f1::/64
  PersistentKeepalive = 25

• Routing-Tabelle:

  Code

  192.168.178.0/24 dev wg0 proto kernel scope link src 192.168.178.135

Alles funktioniert...

• Die DNS-Auflösung z. B. für jellyfin.home funktioniert problemlos (Antwort von 192.168.178.36).

• Auch eine nc -zvu 192.168.178.103 1514 auf den Wazuh-Server funktioniert aktuell erfolgreich:

  Connection to 192.168.178.103 1514 port [tcp/*] succeeded!

• Der Wazuh-Agent meldet regelmäßig an den Server im Heimnetz (192.168.178.135 aktiv registriert, letzte Keepalive-Meldung aktuell).

• Dienste wie nginx und HestiaCP laufen laut systemctl ohne Unterbrechung.

• Die Verbindung via WireGuard ist durchgehend stabil (Handshake alle 25 Sekunden, aktive Datenübertragung sichtbar).

• apt update funktionmiert, der Server kann nach draußen kommunizieren
• Domains und Mailpostfächer sind erreichbar und eingerichtet
• Wazuh meldet keine kritschen Fehler
• Greenbone check gegen den Server zeiugt keine aufälligen angreifbaren sicherheitslücken. Alles gepatched
• SSH ausschließlich per Public Key

...bis plötzlich nichts mehr erreichbar ist

Zweimal ist folgendes Phänomen aufgetreten – jeweils nachts zwischen 22:00 Uhr und 03:00 Uhr:

• SSH-Zugriff schlägt fehl.

  • Kein Eintrag im auth.log, d.h. Verbindung kommt gar nicht erst beim Dienst an.

  • traceroute und ping funktionieren aber weiterhin.

• HestiaCP-Panel nicht erreichbar.

• E-Mail-Clients (IMAP/SMTP) auf dem Handy verlieren Verbindung.

• Domains sind nicht mehr über das Internet erreichbar, DNS löst aber korrekt auf.

• Ein Rollback auf ein Snapshot vom Vorabend (z. B. 31.05.2025 um 18:19 Uhr) bringt alles wieder zum Laufen.

Die betroffenen Ports scheinen blockiert zu sein – ohne dass eine Firewallregel sie aktiv sperrt oder Dienste tatsächlich neu gestartet wurden. Ein Blick in die Logs (auth.log, nginx-error.log, hestia/nginx-error.log) zeigt keinerlei Hinweise auf einen Fehler oder externen Zugriff. Es gibt keine Cronjobs oder automatisierten Tasks, die nachts aktiv laufen und Ports ändern oder blockieren würden.

ssh nc
ssh: connect to host 152.xx.xx.xx port xxxx: Connection timed out

Vermutungen

• WireGuard scheint korrekt zu funktionieren, Routing ist in Ordnung.

• Dienste laufen intern – nur aus dem Internet scheint der Zugriff verloren zu gehen.

• DNS funktioniert, aber TCP-Verbindungen auf bekannte Ports werden verworfen oder blockiert.

• Es wirkt fast so, als ob der Server in einen Zustand gerät, in dem nur noch bestehende interne Verbindungen (z. B. über WireGuard) aktiv bleiben, neue aber abgewiesen werden – möglicherweise Kernelnetzwerk-Stack betroffen?

Frage in die Runde

Hat jemand ähnliche Symptome erlebt oder Ideen, was ich noch prüfen könnte?

• Könnte es durch Livepatch, Fail2Ban, netfilter oder etwas Ähnliches passieren?

  • Nichts auffälliges in den jails, keine sichtbaren blocks

• Welche Logs wären zusätzlich hilfreich?

Ich danke Euch vorab – gerne liefere ich weitere Details, wenn gewünscht. Viele Grüße

Nachtrag:

ein nc -zv ip 80 und 443 zeigt: time out.

Ich hege den Verdacht, das Netcup mir die Verbindung killt. Das Wiederspricht aber dem Verhalten, dass der Snapshot das Problem behebt....

DOING!

Nach intensiver Prüfung stellte sich heraus, dass meine öffentliche IP-Adresse durch das Fail2Ban-Jail recidive gebannt wurde.

Grund dafür:

Mehrfache fehlgeschlagene Anmeldeversuche eines Mailclients am Mailserver via Dovecot. Das führte zu wiederholten Bans im Jail dovecot-iptables, was letztlich recidive aktivierte.

Ein Auszug aus dem Log:

NOTICE  [dovecot-iptables] Ban xx.xx.xx.8
INFO    [recidive] Found xx.xx.xx.8
NOTICE  [recidive] Ban xx.xx.xx.8

✅ Lösung

• Die IP wurde über folgenden Befehl entbannt:

  Code

  sudo fail2ban-client set recidive unbanip xx.xx.xx.8

Viele Grüße

und sorry :p

Ja, ich habe gesehen, dass das mit der aktuellen fail2ban auch mit dyndns geht aber mal schauen.
Mein Heimnetzanschluss hat ja keine feste ip.
Den Client der der verursacht hat habeich ja gerade gezogen, sollte im besten fall nicht wieder vor kommen.