Peering/Transit zu Cogent: SSL-VPN (TCP/443) seit 20.01. morgens nicht nutzbar – PLZ 93197 – Vodafone ok, Telekom fest+mobil nicht
vor 27 Tagen
Hallo zusammen,
ich vermute ein Routing/ Peering /Transit-Problem (ggf. am Übergang Richtung Cogent) und hoffe auf eine technische Einordnung bzw. Zuordnung zu einer bekannten Störung.
Ausgangslage / Zeitraum
Anschluss: MagentaZuhause Glasfaser, Bayern PLZ 93197
Bis Mo, 19.01.2026 ca. 23:00 Uhr war alles ok (ich habe gearbeitet).
Seit Di, 20.01.2026 morgens kann ich mich nicht mehr verbinden: SSL- VPN (FortiClient) → Timeout (Verbindungsaufbau klappt nicht).
Gegenprobe / Provider-Vergleich
Über Telekom Glasfaser: VPN geht gar nicht (Timeout)
Über Telekom Mobilfunk (Handy/Hotspot): ebenfalls geht nicht
Über Vodafone (GigaCube): VPN funktioniert sofort
Zusätzlich hatte eine Nachbarin (ebenfalls Telekom-Glasfaser) seit gestern auch VPN -Probleme/Abbrüche (anderes VPN , nicht Fortinet).
Messungen (Ziel anonymisiert, Details kann ich bei Bedarf privat liefern)
tracertaus dem Telekom-Netz erreicht das Zielnetz und zeigt den Weg über DTAG /ipconnect und danach über Cogent (cogentco.com). Das Ziel ist erreichbar, einzelne Zwischenhops antworten nicht auf ICMP (Request timed out), aber der Trace läuft durch.Test-NetConnection <ziel> -Port 443liefert bei Telekom TcpTestSucceeded: True.
Trotzdem scheitert der SSL- VPN -Aufbau weiter mit Timeout.
Kontakt mit Telekom Support
Ich habe es parallel über den Telekom WhatsApp Support versucht. Nach längerer Wartezeit kam die Rückmeldung sinngemäß: „Allgemeines Problem, wird bearbeitet“ – anschließend: „können wir im Service nicht bearbeiten und können daher keine Aussagen treffen“. Eine Ticket-/Störungsnummer habe ich dort nicht bekommen.
Fragen an Telekom (Moderation/Team):
Gibt es aktuell eine bekannte Störung / ein Incident, der Transit/ Peering Richtung Cogent betrifft (ggf. regional/bayernweit)?
Kann jemand meinen Anschluss (PLZ 93197) einer bestehenden Störung zuordnen oder ein Ticket erstellen und mir eine Vorgangs-/Störungsnummer nennen?
Welche Messwerte sind aus eurer Sicht am hilfreichsten (z. B.
pathping, MTR, Zeitfenster), um Packetloss/Instabilität am Übergang zu belegen?
Vielen Dank!
Viele Grüße


Screenshots anbei: tracert (Ziel anonymisiert) zeigt DTAG /ipconnect → Cogent, Trace läuft durch. Test-NetConnection -Port 443 ist True. Trotzdem SSL- VPN Timeout seit 20.01. morgens.
206
0
11
Das könnte Ihnen auch weiterhelfen
568
0
4
393
0
2
4517
0
2
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.

Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.

vor 27 Tagen
Das sieht jedoch mehr als nen Problem deiner Gegenstelle aus.
Deine Pakete verlassen ja das Telekom Netz.
0
vor 27 Tagen
Sorry, falsch gelesen0
0
vor 27 Tagen
Gibt es aktuell eine bekannte Störung / ein Incident, der Transit/ Peering Richtung Cogent betrifft (ggf. regional/bayernweit)?
Hallo zusammen,
ich vermute ein Routing/ Peering /Transit-Problem (ggf. am Übergang Richtung Cogent) und hoffe auf eine technische Einordnung bzw. Zuordnung zu einer bekannten Störung.
Ausgangslage / Zeitraum
Anschluss: MagentaZuhause Glasfaser, Bayern PLZ 93197
Bis Mo, 19.01.2026 ca. 23:00 Uhr war alles ok (ich habe gearbeitet).
Seit Di, 20.01.2026 morgens kann ich mich nicht mehr verbinden: SSL- VPN (FortiClient) → Timeout (Verbindungsaufbau klappt nicht).
Gegenprobe / Provider-Vergleich
Über Telekom Glasfaser: VPN geht gar nicht (Timeout)
Über Telekom Mobilfunk (Handy/Hotspot): ebenfalls geht nicht
Über Vodafone (GigaCube): VPN funktioniert sofort
Zusätzlich hatte eine Nachbarin (ebenfalls Telekom-Glasfaser) seit gestern auch VPN -Probleme/Abbrüche (anderes VPN , nicht Fortinet).
Messungen (Ziel anonymisiert, Details kann ich bei Bedarf privat liefern)
tracertaus dem Telekom-Netz erreicht das Zielnetz und zeigt den Weg über DTAG /ipconnect und danach über Cogent (cogentco.com). Das Ziel ist erreichbar, einzelne Zwischenhops antworten nicht auf ICMP (Request timed out), aber der Trace läuft durch.Test-NetConnection <ziel> -Port 443liefert bei Telekom TcpTestSucceeded: True.Trotzdem scheitert der SSL- VPN -Aufbau weiter mit Timeout.
Kontakt mit Telekom Support
Ich habe es parallel über den Telekom WhatsApp Support versucht. Nach längerer Wartezeit kam die Rückmeldung sinngemäß: „Allgemeines Problem, wird bearbeitet“ – anschließend: „können wir im Service nicht bearbeiten und können daher keine Aussagen treffen“. Eine Ticket-/Störungsnummer habe ich dort nicht bekommen.
Fragen an Telekom (Moderation/Team):
Gibt es aktuell eine bekannte Störung / ein Incident, der Transit/ Peering Richtung Cogent betrifft (ggf. regional/bayernweit)?
Kann jemand meinen Anschluss (PLZ 93197) einer bestehenden Störung zuordnen oder ein Ticket erstellen und mir eine Vorgangs-/Störungsnummer nennen?
Welche Messwerte sind aus eurer Sicht am hilfreichsten (z. B.
pathping, MTR, Zeitfenster), um Packetloss/Instabilität am Übergang zu belegen?Vielen Dank!
Viele Grüße
Screenshots anbei:
tracert(Ziel anonymisiert) zeigt DTAG /ipconnect → Cogent, Trace läuft durch.Test-NetConnection -Port 443ist True. Trotzdem SSL- VPN Timeout seit 20.01. morgens.Du hast kein Peering Problem. Auch blockiert die Telekom keine Ports. Du solltest dich an den Betreiber wenden, die können schließlich auch sehen, warum die SSL Verbindung blockiert wird.
0
vor 27 Tagen
Guten Abend ukohnke,
ich danke für die Nachricht in der Telekom hilft Community.
Wie hier schon geschrieben wurde, verlassen die Pakete das Telekomnetz. Hoffentlich kann dir der Anbieter hier mit den tracert mehr Infos geben, warum es aktuell blockiert wird.
Viele Grüße
Natalie
0
7
von
vor 26 Tagen
Du brauchst von denen mal eine Aussage, an welchen Server sie deine Anfrage weiterleiten und dir die Adresse geben.
Ohne diese kannst du es nicht nachvollziehen.
Die schicken deinen Login intern also noch zu irgendeinen Server - und deine Anfrage kommt dort nicht an.
Evtl. haben sie bei diesen 2. Server teile des Telekom IP Ranges geblockt oder irgendeine andere Config drin.
Zu deinen Fragen - 2 & 3 da kommst du bei der Telekom nicht weit.
Die haben damit ja nichts zutun. Da bringen auch Eskalationen bei der Telekom nix.
Bsp:
Eine Seite von mir ist für Anfragen aus dem Ausland geblockt. Bei anderen Seiten erlaube ich nur spezielle Refs + Token vom Loadbalancer - fehlt was, bekommst vom Ziel keinen Content. Da kann der Kunde der T-Mobile US noch so extrem bei seinem Anbieter eskalieren und Störungen melden - die T-Mobile US kann da nichts tun.
von
vor 26 Tagen
Danke, ich glaube ich verstehe: Mit MFA hängt es vermutlich nicht am VPN -Gateway selbst, sondern am zusätzlichen MFA/SAML-Webdienst („zweiter Server“), den das Gateway während des Logins aufruft. Wenn dieser Dienst Telekom-IP-Ranges blockt/drosselt, kann Telekom das nicht direkt „reparieren“.
Ich werde beim Kunden erfragen, welche konkrete SAML/FortiToken-Cloud-URL betroffen ist und dann Tests (Telekom vs Vodafone) auf genau diese Domain machen (
Test-NetConnection,curl, ggf.pathping). Damit kann man besser eingrenzen, ob es Block/Throttling auf der Zielseite oder Instabilität im Netzweg ist.von
vor 3 Tagen
Hallo @ukohnke,
danke für die tollen Gespräche. Ich würde jetzt aktuell erstmal einen Haken hinter diesen Fall machen, da es ja aktuell keine weiteren genaueren Beispiel gab.
Viele Grüße ^Daniel Wi.
0
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von