Bitte loggen sie sich ein oder registrieren sie sich.
1 Stunde 1 Tag 1 Woche 1 Monat Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge

Hallo zusammen,

ich wollte mich kurz melden: Das Problem besteht leider weiterhin – SSH-Verbindungen zu meinem VS2-free vServer (2a02:180:6:1::617) werden nach wie vor sofort mit "closed by foreign host" abgebrochen, auch im Rescue-System.

Könnte bitte jemand einen Blick darauf werfen? Vielen Dank!

Hallo zusammen,

ich wollte mich erkundigen, ob es zu meinem Anliegen bereits Neuigkeiten gibt. Das Problem besteht weiterhin – sämtliche SSH-Verbindungen (einschließlich Rescue-System) werden nach wie vor sofort mit „closed by foreign host" abgebrochen.

Über jede Rückmeldung würde ich mich freuen. Vielen Dank!

Seit heute 2026-10-07 15:41 funktioniert es endlich wieder.
Das System war 10 Minute nicht erreichbar und bootete um 15:41 von Geisterhand.

Schade, dass es keine Info dazu vom Support gibt.

Hallo zusammen,

ich habe ein Problem mit meinem VS2-free vServer (IPv6: 2a02:180:6:1::617): Jede SSH-Verbindung wird sofort mit "closed by foreign host" abgebrochen.

Bereits ausgeschlossen:
- Lokales Netz / ISP: von mehreren Netzen und mit verschiedenen Clients (macOS Terminal, FinalShell) getestet – überall dasselbe.
- sshd / fail2ban / Firewall auf dem Server: Auch das Rescue-System (über Kundencenter aktiviert) zeigt dasselbe Verhalten.
- IPv6 grundsätzlich: Ping6 zum Server funktioniert.

Da selbst das Rescue-System per SSH nicht erreichbar ist, vermute ich ein host-seitiges Problem. Könnte das bitte jemand prüfen?

Vielen Dank!

Das Problem tritt mitten im laufenden Betrieb heute seit 2026-10-04 18:00 wieder auf.
Reboot hilft nicht.

Schade, dass es keine Infos vom Support gibt.

Update (28.09.):

Hallo zusammen,

die Netzwerkerreichbarkeit und der SSH-Zugriff funktionieren inzwischen wieder einwandfrei (getestet von Computer und Smartphone). Vielen Dank an alle, die sich darum gekümmert haben.

Ein kleines Problem besteht allerdings weiterhin: Die Webconsole im Kundencenter (support.euserv.com → Configure → Tools → Webconsole) lehnt die Anmeldung mit "falsches Passwort" ab. Ich habe sowohl das aktuelle Passwort (nach der Neuinstallation auf der Server-Data-Seite angezeigt, funktioniert per SSH) als auch das ursprüngliche Passwort von vor zwei Jahren getestet, beides ohne Erfolg.

Könnte sich bitte jemand aus dem Team kurz ansehen, ob die Webconsole-Funktion für meinen Server (VS2-free) möglicherweise ein Problem hat? Falls Sie weitere Angaben benötigen, sende ich sie gerne per PN.

Vielen Dank für Ihre Zeit und Mühe.

Viele Grüße
Mitsubishi

Scheduled Jobs
Queue ID   Type   Scheduled Date
19875773   Reboot   2026-09-26 14:38:50 CEST

Customer ID: 13220732
Server name:   srv24271
Main IPv6-Address:   2a02:0180:0006:0001:0000:0000:0000:49ca

Update (24.09.):

SSH-Zugriff und die allgemeine Netzwerkerreichbarkeit funktionieren jetzt wieder einwandfrei. Vielen Dank für die (vermutlich zwischenzeitlich erfolgte) Behebung des Problems.

Ein separates, davon unabhängiges Problem besteht allerdings weiterhin: Die webbasierte Konsole (Kundencenter → Configure → Tools → Webconsole) zeigt bei der Anmeldung nach wie vor "falsches Passwort" an. Ich habe dabei sowohl das ursprüngliche Passwort (von der Ersteinrichtung vor rund zwei Jahren) als auch das aktuelle Passwort (nach der letzten Neuinstallation automatisch auf der Server-Data-Seite angezeigt) ausprobiert — beide werden von der Webconsole als falsch abgelehnt.

Der SSH-Zugriff mit dem aktuellen Passwort funktioniert dabei einwandfrei, sowohl von meinem Computer als auch von meinem Smartphone aus getestet. Da also zwei unterschiedliche Geräte den SSH-Login problemlos akzeptieren, aber keines der beiden Passwörter über die Webconsole funktioniert, vermute ich, dass es sich um ein eigenständiges Problem der Webconsole-Funktion selbst handelt, unabhängig vom ursprünglichen Netzwerkproblem.

Ich wollte es der Vollständigkeit halber trotzdem erwähnen, falls es für Sie relevant ist.

Vielen Dank nochmals für Ihre Unterstützung.

Zusätzlich (nur der Vollständigkeit halber, falls es hilfreich ist):

Mir ist noch aufgefallen, dass sich die webbasierte Konsole (Tools :: Webconsole) nicht mit dem Passwort anmelden lässt, das nach der Neuinstallation automatisch auf der Server-Data-Seite angezeigt wurde. Mit genau diesem Passwort konnte ich mich zuvor problemlos per SSH verbinden. Ich bin mir nicht sicher, ob das mit dem oben beschriebenen Problem zusammenhängt, wollte es aber der Vollständigkeit halber erwähnen.

Vielen Dank nochmals für Ihre Mühe.

Hallo zusammen,

ich melde hier ein wiederkehrendes Problem mit der IPv6-Erreichbarkeit meines VS2-free Servers, da mein gebuchter Tarif laut Support keinen kostenpflichtigen E-Mail-/Telefon-Support beinhaltet. Kontodaten (Kundennummer, Vertragsnummer) sende ich zur Verifizierung per PN, um sie hier nicht öffentlich zu posten.

Server: `srv****.blue.kundencontroller.de`
IPv6: `2a02:180:6:1::2**`

Symptome:
- Server über IPv6 nicht erreichbar (SSH-Timeout, Cloudflare Tunnel zeigt "offline").
- Web-Reset über das Kundencenter behebt das Problem nicht.
- Globale Erreichbarkeitstests  zeigen während der Störung Nichterreichbarkeit von praktisch allen getesteten Standorten weltweit.

Bisheriger Verlauf:
- Erste Störung: [20.09]
- Behoben am 22.09., nachdem ich über das Kundencenter eine komplette Neuinstallation des Betriebssystems durchgeführt habe (Konnektivität kehrte unmittelbar danach zurück).
- Zweite, aktuell andauernde Störung: seit dem 23.09.

Technische Diagnose (erste Störung):
Ich habe einen anderen EUserv-Kunden gebeten, per mtr von seinem eigenen EUserv-Server aus (also innerhalb Ihres Netzwerks, ohne externen Transit) sowohl seine eigene Adresse als auch meine anzupingen, zum direkten Vergleich:

- Zu seinem eigenen Server: vollständig erfolgreich, 0% Paketverlust am letzten Hop.
- Zu meinem Server: identischer Pfad durch Ihr Netzwerk bis zum Knoten `2a02:180:6:9::5`, danach Abbruch mit "no route to host".

Zusätzlich habe ich externe Traces von zwei unabhängigen Netzwerken durchgeführt (Oracle Cloud, Hetzner) — beide liefen über komplett unterschiedliche Upstream-Pfade (einmal via Tata/AS6453, einmal via HE/Zayo/AS6939), liefen aber exakt am selben internen Knoten (`2a02:180:6:9::5`) zusammen, bevor sie fehlschlugen. Das deutet stark auf einen fehlenden oder veralteten Routing-/Neighbor-Table-Eintrag für meine spezifische IP-Adresse hin, nicht auf ein externes Transit- oder Peering-Problem.

Aktuelle Situation (23.09.) — vermutlich größeres Problem:
Die Störung ist nach nur ca. 24 Stunden erneut aufgetreten, was darauf hindeutet, dass die Ursache beim letzten Mal nicht vollständig behoben wurde. Zusätzlich beobachte ich heute:

1. Ein befreundeter EUserv-Kunde kann sich ebenfalls nicht per SSH auf seinen eigenen Server verbinden — das Problem scheint also nicht auf meinen Account beschränkt zu sein.
2. support.euserv.com selbst liefert ein fehlerhaftes SSL-Zertifikat (Port 80 funktioniert, Port 443 nicht): Der Browser zeigt `ERR_CERT_COMMON_NAME_INVALID`. Das ausgelieferte Zertifikat ist für `euserv.de` / `*.euserv.de` ausgestellt (Let's Encrypt, ausgestellt am 04.09.2026, gültig bis 04.12.2026 — also nicht abgelaufen), wird aber für die Domain `euserv.com` ausgeliefert. Das deutet für mich auf ein Fehlkonfigurationsproblem im Bereich SNI-Routing / Load-Balancer / Zertifikatszuordnung hin — nicht auf ein abgelaufenes Zertifikat.

Angesichts dieser gleichzeitig auftretenden Probleme (mein Server, der Server eines anderen Kunden, und die eigene Support-Website) vermute ich, dass es sich heute um ein größeres, netzwerk- oder infrastrukturweites Problem handelt und nicht um ein isoliertes Problem meines Accounts.

Könnte sich bitte jemand aus dem Netzwerk-Team die Routing-/Neighbor-Table-Einträge in der Nähe von `2a02:180:6:9::5` ansehen? Vollständige mtr-Ausgaben und weitere Traces stelle ich gerne auf Anfrage zur Verfügung.

Vielen Dank für Ihre Zeit,

Mitsu