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)

  • tracert aus 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 443 liefert 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):

  1. Gibt es aktuell eine bekannte Störung / ein Incident, der Transit/ Peering Richtung Cogent betrifft (ggf. regional/bayernweit)?

  2. Kann jemand meinen Anschluss (PLZ 93197) einer bestehenden Störung zuordnen oder ein Ticket erstellen und mir eine Vorgangs-/Störungsnummer nennen?

  3. 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.

Letzte Aktivität

vor 3 Tagen

von

Gelöschter Nutzer

206

0

11

    • 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 gelesen

      0

      0

    • vor 27 Tagen

      ukohnke

      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)

      • tracert aus 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 443 liefert 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):

      1. Gibt es aktuell eine bekannte Störung / ein Incident, der Transit/ Peering Richtung Cogent betrifft (ggf. regional/bayernweit)?

      2. Kann jemand meinen Anschluss (PLZ 93197) einer bestehenden Störung zuordnen oder ein Ticket erstellen und mir eine Vorgangs-/Störungsnummer nennen?

      3. 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.

      ukohnke

      Gibt es aktuell eine bekannte Störung / ein Incident, der Transit/ Peering Richtung Cogent betrifft (ggf. regional/bayernweit)?

      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

    Beliebte Tags letzte 7 Tage

    Loading...Loading...Loading...Loading...Loading...Loading...Loading...Loading...Loading...Loading...