CRITICAL and RECURRING Issue: Total Network Connectivity Loss on KVM VPS (SSH "Connection refused" / Ping Fails) – Identical to June 26th, 2025 Problem – Connectivity remains cut even after Snapshot Restoration!

Hello everyone and Netcup support, linked to Same June 2025 issue

I am facing an extremely severe and recurring issue on my KVM VPS instances, which is jeopardizing the stability of my services, particularly my mail server.

Problem Description: I have suddenly lost all external connectivity (SSH, HTTP(S), etc.) to my KVM VPS: srv-apps.democrasite.com (IP 152.53.180.152). From my client machine (iMac), any attempt to SSH via the IP results in a "Connection refused."

Confirmed on the VPS side (via Cockpit):

• The SSH daemon (sshd) is running and listening correctly on port 22 (IPv4 and IPv6).
• The UFW firewall is active and configured to ALLOW IN Anywhere on port 22 (as well as all necessary ports for my web and mail services).
• SSH logs show that the server is listening and even recorded connection attempts from an older IP, but none from my current public IP.
• Most alarming: From the VPS, I am unable to "ping" my current public IP address (37.67.114.10). I get 100% packet loss.

Context of the Issue's Onset and Recurrence: This problem appeared while I was configuring SSH connectivity between two Netcup VPS instances (for Cockpit Master/Slave setup). It's important to note that no VPS reboot was performed after the UFW configuration before the blocking occurred. My iMac was initially able to connect via SSH using a password/passphrase, but subsequent unsuccessful attempts from my MacBook Pro (possibly due to a passphrase issue or an unconfigured SSH key pair) followed, and then connectivity was cut off for all my machines.

This problem is an exact recurrence of the one I encountered on June 26th, 2025, on another Netcup KVM VPS (see this forum thread for reference: [Link to your old forum thread]). On that occasion, the same lack of ping response and network blockage occurred, and the only solution was to completely reinstall the KVM from a fresh image to regain connectivity.

Why this is a Netcup Infrastructure Issue (according to my analysis):

• The SSH daemon is active and UFW is open, so the problem is not OS-side.
• The ping failure from the VPS to my IP proves that the connection is blocked upstream, even before reaching my VPS.
• Most critically: I restored a snapshot of my VPS (taken just before these configurations, when everything was working). EVEN AFTER THE SNAPSHOT RESTORATION, THE PROBLEM PERSISTS! This definitively rules out any software configuration error on the VPS and confirms an external blockage.

Consequences and Urgency: I have spent several days configuring this VPS to migrate my websites and, most importantly, my mail server onto it. Such network instability, which is recurring identically, is unacceptable for such a critical service. It implies the loss of days of work if I have to completely reinstall everything again.

Questions to the community and Netcup support:

• Have other users experienced this type of "mysterious" network disconnection where ping fails and the only solution is a complete reinstallation?
• Does Netcup have network-level firewall or monitoring systems that might automatically block IPs or isolate VPS instances in case of "suspicious" behavior (e.g., repeated SSH attempts, dynamic UFW configurations)? Is the absence of a reboot after such operations a known trigger?
• What are the precise policies regarding this, and how can stable network connectivity be ensured for critical VPS instances? How can this be prevented from happening again?
• How can I regain reliable connectivity without having to redo days of work?

The stability and predictability of your infrastructure are vital. I look forward to your urgent clarification and a lasting solution.

Thank you in advance for your help.

Sincerely,

------ DE version :

KRITISCHES und WIEDERKEHRENDES Problem: Totaler Netzwerk-Konnektivitätsverlust auf KVM VPS (SSH "Connection refused" / Ping-Fehler) – Identisch mit dem Problem vom 26. Juni 2025 – Konnektivität bleibt auch nach Snapshot-Wiederherstellung unterbrochen!

Hallo zusammen und Netcup-Support,

Ich stehe vor einem äußerst schwerwiegenden und wiederkehrenden Problem mit meinen KVM-VPS-Instanzen, das die Stabilität meiner Dienste, insbesondere meines Mailservers, gefährdet.

Problembeschreibung: Ich habe plötzlich die gesamte externe Konnektivität (SSH, HTTP(S) usw.) zu meinem KVM VPS: srv-apps.democrasite.com (IP 152.53.180.152) verloren. Von meinem Client-Rechner (iMac) führt jeder SSH-Versuch über die IP zu einem "Connection refused".

Auf der VPS-Seite bestätigt (über Cockpit):

• Der SSH-Daemon (sshd) läuft und lauscht korrekt auf Port 22 (IPv4 und IPv6).
• Die UFW-Firewall ist aktiv und so konfiguriert, dass sie ALLOW IN Anywhere auf Port 22 zulässt (sowie alle notwendigen Ports für meine Web- und Mail-Dienste).
• SSH-Logs zeigen, dass der Server lauscht und sogar Verbindungsversuche von einer älteren IP protokolliert hat, aber keine mehr von meiner aktuellen öffentlichen IP.
• Am alarmierendsten: Vom VPS aus kann ich meine aktuelle öffentliche IP-Adresse (37.67.114.10) nicht anpingen. Ich erhalte 100% Paketverlust.

Kontext des Problembeginns und Wiederauftretens: Dieses Problem trat auf, während ich die SSH-Konnektivität zwischen zwei Netcup-VPS-Instanzen (für das Cockpit Master/Slave-Setup) konfigurierte. Es ist wichtig zu beachten, dass kein VPS-Neustart durchgeführt wurde, nachdem die UFW-Konfiguration vorgenommen wurde, bevor die Blockade auftrat. Mein iMac konnte sich zunächst über SSH mit Passwort/Passphrase verbinden, aber nachfolgende erfolglose Versuche von meinem MacBook Pro (möglicherweise aufgrund eines Passphrase-Problems oder eines nicht konfigurierten SSH-Schlüsselpaares) folgten, und danach wurde die Konnektivität für alle meine Rechner unterbrochen.

Dieses Problem ist eine exakte Wiederholung des Problems, das ich am 26. Juni 2025 auf einem anderen Netcup KVM VPS erlebt habe (siehe diesen Foren-Thread als Referenz: [Link zu Ihrem alten Foren-Thread]). Damals kam es zu derselben fehlenden Ping-Antwort und Netzwerkblockade, und die einzige Lösung war eine komplette Neuinstallation des KVM von einem frischen Image, um die Konnektivität wiederherzustellen.

Warum dies ein Netcup-Infrastrukturproblem ist (gemäß meiner Analyse):

• Der SSH-Daemon ist aktiv und UFW ist geöffnet, daher liegt das Problem nicht auf der OS-Seite.
• Der Ping-Fehler vom VPS zu meiner IP beweist, dass die Verbindung vorgeschaltet blockiert wird, noch bevor sie meinen VPS erreicht.
• Am kritischsten: Ich habe einen Snapshot meines VPS wiederhergestellt (aufgenommen kurz vor diesen Konfigurationen, als alles funktionierte). AUCH NACH DER SNAPSHOT-WIEDERHERSTELLUNG BLEIBT DAS PROBLEM BESTEHEN! Dies schließt definitiv jeglichen Software-Konfigurationsfehler auf dem VPS aus und bestätigt eine externe Blockade.

Konsequenzen und Dringlichkeit: Ich habe mehrere Tage damit verbracht, diesen VPS zu konfigurieren, um meine Websites und vor allem meinen Mailserver darauf zu migrieren. Eine solche Netzwerkinstabilität, die sich identisch wiederholt, ist für einen so kritischen Dienst inakzeptabel. Sie bedeutet den Verlust von tagelanger Arbeit, falls ich wieder alles von Grund auf neu installieren muss.

Fragen an die Community und den Netcup-Support:

• Haben andere Benutzer diese Art von "mysteriöser" Netzwerk-Trennung erlebt, bei der Ping fehlschlägt und die einzige Lösung eine komplette Neuinstallation ist?
• Verfügt Netcup über netzwerkbasierte Firewall- oder Überwachungssysteme, die IPs automatisch blockieren oder VPS-Instanzen bei "verdächtigem" Verhalten (z.B. wiederholte SSH-Versuche, dynamische UFW-Konfigurationen) isolieren könnten? Ist das Fehlen eines Neustarts nach solchen Vorgängen ein bekannter Auslöser?
• Wie sehen die genauen Richtlinien hierzu aus und wie kann eine stabile Netzwerkkonnektivität für kritische VPS-Instanzen gewährleistet werden? Wie kann dies zukünftig verhindert werden?
• Wie kann ich eine zuverlässige Konnektivität wiederherstellen, ohne tagelange Arbeit wiederholen zu müssen?

Die Stabilität und Vorhersagbarkeit Ihrer Infrastruktur sind von entscheidender Bedeutung. Ich erwarte dringend eine Klärung und eine dauerhafte Lösung.

Vielen Dank im Voraus für Ihre Hilfe.

Mit freundlichen Grüßen,

ich melde mich erneut bei Ihnen nach Ihrem Feedback und den Analysen, die ich meinerseits durchgeführt habe, um die Situation zu klären. Vielen Dank für den Vorschlag bezüglich tcpdump; das ist in der Tat ein ausgezeichnetes Tool, das ich sicherlich eingesetzt hätte, wenn die Situation so unklar geblieben wäre.

Als ich an mein Problem vom 26. Juni dachte, das zu einer vollständigen Neuinstallation führte (und diese "schreckliche" VNC-Erfahrung!), zog ich es diesmal vor, zu einem früheren Snapshot meines VPS srv-hosting.democrasite.com (152.53.118.225) zurückzukehren, den ich etwa eine Stunde vor Beginn der Probleme erstellt hatte.

Und wider Erwarten funktionierte die SSH-Verbindung nach der Wiederherstellung, und meine Websites sowie mein Mailserver sind wieder voll funktionsfähig. Mein anderer VPS, srv-apps.democrasite.com (152.53.180.152), war von diesem Vorfall überhaupt nicht betroffen und lief währenddessen normal weiter.

Um so präzise wie möglich zu sein, was auf srv-hosting vor der Wiederherstellung geschah:

1. Ich hatte UFW installiert und seine Regeln konfiguriert (einschließlich der Integration bestehender iptables-Regeln und der Änderung einer Direktive von DROP auf ACCEPT in den before.rules), und es dann aktiviert. Es gab zu diesem Zeitpunkt keinen Server-Neustart.
2. Nach diesen Änderungen und Versuchen, eine SSH-Schlüsselverbindung (mit einem passphrase-Problem meinerseits) herzustellen, reagierte der SSH-Dämon (sshd) auf srv-hosting nicht mehr.
3. Von diesem Zeitpunkt an konnte ich mich nicht mehr per SSH mit der Maschine verbinden, und schlimmer noch, der Server srv-hosting konnte nicht einmal mehr externe Ziele (ping-en (z.B. Google-Server), was auf einen totalen Verlust des Zugangs zum Netcup-KVM-Netzwerk für diesen VPS hindeutete.

Meine zentrale Frage bleibt daher: Gibt es nach Ihrem Kenntnisstand einen Mechanismus auf Seiten der Netcup-Infrastruktur, der den Zugriff auf das externe Netzwerk eines KVM-VPS vorübergehend "isolieren" oder "einsperren" kann? Insbesondere nach einem als abnormal eingestuften internen Verhalten (wie vielen fehlgeschlagenen SSH-Verbindungsversuchen, möglicherweise im Zusammenhang mit Fail2Ban, oder einer Instabilität des SSH-Dienstes selbst)?

Sollte dies nicht der Fall sein, weiß ich zumindest, dass das Problem vollständig auf meine Fehlkonfiguration zurückzuführen war, und ich entschuldige mich natürlich für die Unannehmlichkeiten. Ziel ist es, das Problem zu verstehen, um eine Wiederholung zu vermeiden.

Vielen Dank im Voraus für Ihre Zeit und Hilfe.

Mit freundlichen Grüßen,

--------
Thank you for the tcpdump suggestion; it is indeed an excellent tool that I would have used if the situation had remained unclear.

Recalling my problem on June 26th, which resulted in a complete reinstallation (and that "horrible" VNC experience!), this time I preferred to revert to the last snapshot I had made on my VPS srv-hosting.democrasite.com (152.53.118.225) about an hour before the issues began.

Unexpectedly, the SSH connection worked after the restoration, and my websites, as well as my mail server, are fully operational again. My other VPS, srv-apps.democrasite.com (152.53.180.152), was not affected at all by this incident and continued to function normally throughout.

To be as precise as possible about what happened on srv-hosting before the restoration:

1. I had installed UFW and configured its rules (including integrating existing iptables rules and changing a DROP to ACCEPT directive in the before.rules), and then I enabled it. There was no server reboot at that time.
2. Following these modifications and attempts to establish an SSH key connection (with a passphrase issue on my part), the SSH daemon (sshd) on srv-hosting became unresponsive.
3. From that point, I could no longer connect to the machine via SSH, and more seriously, the srv-hosting server could not even ping external targets (e.g., Google's servers), indicating a total loss of access to the Netcup KVM network for this VPS.

My central question therefore remains: To your knowledge, is there a mechanism within the Netcup infrastructure that can temporarily "isolate" or "jail" a KVM VPS's access to the external network? Particularly after an internal behavior deemed abnormal (such as numerous failed SSH connection attempts, possibly related to Fail2Ban, or an instability of the SSH service itself)?

If this is not the case, I will at least know that the problem was entirely due to my misconfiguration, and I would, of course, apologize for the inconvenience. The goal is to understand the issue to prevent it from recurring.

Thank you in advance for your time and assistance.

Sincerely

Ich melde mich bezüglich des Problems, das ich kürzlich mit meinem VPS srv-hosting.democrasite.com (IP: 152.53.118.225) hatte. Dieser war blockiert, per SSH unerreichbar und hatte keine externe Netzwerkverbindung mehr.

Nach einer gründlichen Analyse und mit Hilfe eines technischen Assistenten konnten wir die Ereigniskette rekonstruieren und die Hauptursache identifizieren, die auf meine eigenen Handlungen zurückzuführen ist, wahrscheinlich verursacht durch eine gewisse Übereilung.

Zunächst möchte ich meine Fehler im Management eingestehen, die mich dazu veranlasst haben, aus Sicherheitsgründen einen Snapshot wiederherzustellen, da ich die Situation anfänglich nicht vollständig verstanden hatte.

Hier ist die detaillierte Diagnose und der Zeitplan der Ereignisse:

Kontext meines srv-hosting VPS:

• Der Server lief unter Ubuntu und verwendete iptables mit aktivem Fail2Ban zum Schutz vor Brute-Force-Angriffen über SSH.
• Die sshd-Konfiguration (/etc/ssh/sshd_config) sah wie folgt aus und erlaubte unter anderem den root-Login sowie die Passwort- und Public-Key-Authentifizierung:
  Code

  PubkeyAuthentication yes@@@WCF_PRE_LINEBREAK@@@PasswordAuthentication yes@@@WCF_PRE_LINEBREAK@@@PermitRootLogin yes@@@WCF_PRE_LINEBREAK@@@UsePAM yes@@@WCF_PRE_LINEBREAK@@@

Die zum Problem führenden Aktionen (am 16. Juli):

1. "Hot"-Installation und Aktivierung von UFW: Ich habe UFW auf srv-hosting installiert und konfiguriert (insbesondere durch Anpassung von /etc/ufw/before.rules für die Kompatibilität mit Fail2Ban). Der entscheidende Fehler war hier, UFW (sudo ufw enable) zu aktivieren, ohne danach einen vollständigen Systemneustart durchzuführen. Diese "Hot"-Aktivierung führte potenziell zu einer instabilen Umgebung oder Konflikten in der iptables-Verwaltung.
2. Mehrere, fehlerhafte SSH-Authentifizierungsversuche: Unmittelbar nach der UFW-Aktivierung versuchte ich, mich über SSH zu verbinden:
   • Von meinem MacBook Air: Ich versuchte SSH-Zugriffe (als root und/oder als mein Standardbenutzer via sudo) unter Verwendung von SSH-Schlüsseln mit einer falschen Passphrase. Darüber hinaus ist es möglich, dass der Public Key dieses MacBook Air nicht korrekt konfiguriert oder von srv-hosting erkannt wurde.
   • Der "Gnadenstoß" erfolgte, als ich dasselbe von meinem iMac, meinem gewohnten Arbeitsgerät, versuchte. Obwohl der Public Key des iMacs korrekt auf srv-hosting installiert ist, gab ich erneut wiederholt und schnell eine falsche Passphrase ein.

Folgen und Problem manifestierung:

Die schnelle Abfolge dieser Aktionen führte zu einer kritischen Kettenreaktion:

1. Massive Fail2Ban-Aktivierung: Jeder fehlgeschlagene SSH-Authentifizierungsversuch, der von zwei verschiedenen Client-IPs stammte und mehrere Benutzer/Methoden ansprach, wurde von Fail2Ban erkannt. Fail2Ban begann daraufhin, dynamisch und schnell Sperrregeln in die iptables des Servers für meine IPs hinzuzufügen.
2. sshd-Sättigung und Absturz: Die Kombination aus einer neu aktivierten Firewall (UFW), die mit einem dynamischen Regelverwaltungssystem (Fail2Ban) interagierte, und dem Stress, der durch einen intensiven Fluss fehlgeschlagener Authentifizierungsversuche erzeugt wurde, hat den sshd-Dämon wahrscheinlich gesättigt und/oder korrumpiert.
   • Der sshd-Dienst wurde für neue Verbindungen unerreichbar. Obwohl systemctl status sshd möglicherweise "active (running)" anzeigte (wahrscheinlich durch meine bestehende Cockpit-Sitzung am Leben gehalten), reagierte er nicht.
   • Ein Befehl wie which sshd gab "command not found" zurück, was auf einen korrumpierten oder eingefrorenen Prozesszustand hindeutete.
3. Völliger Verlust der externen Netzwerkverbindung: Infolge dieser Instabilität auf Firewall- und SSH-Dienstebene kam es zu einem vollständigen Verlust der externen Netzwerkverbindung für srv-hosting. Der Server konnte keine externen Ziele (wie Google) mehr anpingen oder Pakete herunterladen (sudo apt install --reinstall openssh-server schlug aus diesem Grund fehl), was eine Remote-Fehlerbehebung unmöglich machte.

Ausschluss von Netcup-Infrastrukturproblemen:

Um sicherzustellen, dass das Problem nicht mit der Netcup-Infrastruktur zusammenhing, führten wir Konnektivitätstests durch:

• Ich konnte meinen anderen VPS (srv-hosting.democrasite.com, IP: 152.53.118.225) von srv-apps.democrasite.com (mein anderer Netcup VPS, IP: 152.53.180.152) aus mit 0% Paketverlust anpingen. Dies beweist, dass die Netzwerkverbindung zwischen meinen eigenen VPS innerhalb der Netcup-Infrastruktur einwandfrei funktionierte.
• Im Gegensatz dazu zeigte der ping an 37.67.114.10 (ein früherer Test, den ich geteilt hatte) auch von einem gesunden Server aus immer noch 100% Paketverlust, was bestätigt, dass diese IP kein zuverlässiger Referenzpunkt ist.

Zusammenfassend:

Der Ausfall von srv-hosting war das direkte Ergebnis einer komplexen "Selbst-Sperrung" und Systeminstabilität, verursacht durch die Kombination einer neuen Firewall-Konfiguration (UFW) ohne Neustart, eines sehr aktiven Fail2Ban und eines intensiven Flusses fehlgeschlagener SSH-Authentifizierungsversuche (aufgrund meiner falschen Passphrasen).

Vielen Dank für Ihre Geduld und die Unterstützung der Netcup-Community. Diese Erfahrung hat mich gelehrt, wie entscheidend wichtig es ist:

1. Immer einen Systemneustart durchzuführen nach größeren Installationen oder Neukonfigurationen sensibler Elemente wie Firewalls oder SSH-Diensten.
2. Passphrasen und SSH-Schlüsselkonfigurationen sorgfältig zu überprüfen, insbesondere bei den ersten Verbindungen von neuen Geräten.

Ich hoffe, diese detaillierte Diagnose kann anderen Benutzern in ähnlichen Situationen nützlich sein.

Moral von der Geschichte: Nicht in Panik geraten, nicht überstürzt handeln und immer daran denken, Ihren VPS nach jeder sensiblen Konfiguration oder Installation von sensiblen Softwarepaketen, wie zum Beispiel der Firewall, neu zu starten.

Mit freundlichen Grüßen.

Sincerely,

[attach=15296]English Version[/attach]