Login über Kabel-Netz scheitert

[ThomasB7]

Hallo Community!
Hoffe mir kann jemand einen Tipp geben. Habe Problem mit Kabel-Netz für ING-Online-Banking Anmeldung. Den Fehler habe ich heute bemerkt, vielleicht besteht das Problem schon länger, aber ich benutze zusätzlich auch die ING-Smart-Phone App (die weiterhin geht, aber nicht im WLAN). Hat alles hat vor einiger Zeit (ca. 8 Wochen?) definitiv funktioniert.

Beschreibung: Start ING-Hauptseite (https://www.ing.de/), dann Login-Button.
Der Button schickt einen GET-Request zu https://banking.ing.de/app/obligo.

Der Request bricht laut Firefox-Netzwerk-Trace nach ca. 3 Minuten mit  NS_ERROR_NET_RESET ab.
Keine Verbindung also und kein TLS-Handshake Start.

Beobachtungen und ein paar Tests:
1. Das Problem tritt auf allen Rechnern in meinem Heimnetz auf (3x Windows 11, 1x Linux).
2. Problem tritt bei allen verfügbaren Browsern auf (Firefox, Chrome, Edge, Chromium), daher denke ich dass kein Browser-Problem vorliegt
3. Die ING App funktioniert über Mobilfunk (4G) problemlos, aber nicht über WLAN. Das 4G-Netz hat halt nichts mit dem Kabelnetz zu tun. Daher denke ich mal nicht an einen Fehler bei ING.
4. Andere Webseiten funktionieren normal. Daher kein generelles Problem.
5. Ein Neustart von Router und Kabelmodem (5 Minuten stromlos jeweils) hat keine Änderung gebracht. Mir wurde wieder die selbe WAN-IP zugeordnet (scheint sehr lange Lease-Zeit zu haben). Aber würde es etwas bringen hier deutlich länger zu warten? Und wie lange wäre deutlich länger?
6. Test: curl -v https://banking.ing.de 

curl -v https://banking.ing.de
* Host banking.ing.de:443 was resolved.
* IPv6: (none)
* IPv4: 185.142.178.1
* Trying 185.142.178.1:443...
* connect to 185.142.178.1 port 443 from 0.0.0.0 port 46246 failed: Timed out
* Failed to connect to banking.ing.de port 443 after 21052 ms: Could not connect to server
* closing connection #0
curl: (28) Failed to connect to banking.ing.de port 443 after 21052 ms: Could not connect to server

Danke für jeden hilfreichen Input.

[ThomasB7]

Hier im Vodafon Forum gibt es übrigens schonmal so ein Problem: hier 

Die Lösung war dort: Einfach über Nacht den Router ausschalten und am nächsten Tag gab es eine neue IP. Das hat dann das Problem gelöst. Aber offen gesagt: Das ist keine gut Lösung, denn was ist, wenn es 3 Wochen dauert bis man eine neue IP erhält?

[emily2505]

Hi @ThomasB7 

Wir verstehen Deinen Unmut. Teste trotzdem gerne einmal aus, ob der Tipp zu einer Lösung führt. 
Wir sind gespannt auf Deine Rückmeldung. 

Schönen Sonntag und LG Emily❤️

[ThomasB7]

Ich habe es nunmal mit der vorgeschlagenen einfachsten aller Lösungen probiert: Vodafon-Router (also das Modem) stromlos, eine Nacht warten (und hoffen).

Heute morgen einschalten und siehe da, ich habe die selbe WAN-IP. Der Zugriff auf die ING-Seite funktioniert natürlich damit auch nicht.Ist also alles beim Alten geblieben.

Diese Lösung taugt allgemein also nichts bzw. wenn sie funktioniert ist es zufällig. Ich denke ohne einen Vodafon-Admin-Eingriff wird das nicht mehr funktionieren und das auf sehr lange Zeit. Alles sehr frustrierend.

[ThomasB7]

Ich habe mal die Route zu der ING-Login-Seite getraced auf einem Windows Rechner.

tracert banking.ing.de

Routenverfolgung zu banking.ing.de [185.142.178.1] über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  ASUS-Router [192.168.1.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    11 ms    12 ms    11 ms  ip-081-210-145-120.um21.pools.vodafone-ip.de [81.210.145.120]
  4    16 ms    16 ms    14 ms  145.253.48.28
  5    19 ms    17 ms    14 ms  145.254.1.230
  6    17 ms    16 ms    15 ms  f-ed13-i.F.DE.NET.DTAG.DE [217.5.118.230]
  7    16 ms    15 ms    15 ms  80.157.205.250
  8  80.157.205.250  meldet: Zielnetz nicht erreichbar.

Ablaufverfolgung beendet.

Interpretation:Der DNS-Name "banking.ing.de" wird an meinem Anschluss korrekt in die IPv4-Adresse 185.142.178.1 aufgelöst.

Hop 1 ist mein lokaler ASUS-Router unter 192.168.1.1.

Hop 2 antwortet nicht auf die für tracert benötigten ICMP-Meldungen. Das ist vermutlich eine bewusste Filterung per Konfiguration im Zugangsnetz. Die fehlende Antwort heißt nicht, dass es einen Routingfehler an dieser Stelle gibt.

Hop 3 gehört anhand des Reverse-DNS-Namens zum Vodafone-Netz.

Hop 4 und Hop 5 sind weitere Router auf der Route bei Vodafone. Für diese Adressen wird kein Hostname aufgelöst (braucht es auch nicht).

Hop 6 und Hop 7 sieht nach Übergang in das Netz der Deutschen Telekom aus (DTAG=Deutsche Telekom AG).

Bei Hop 8 meldet 80.157.205.250: „Zielnetz nicht erreichbar“. Der Router, der diese Meldung erzeugt, kann die Pakete auf diesem Pfad nicht weiter in Richtung 185.142.178.1 vermitteln. Die IP 80.157.205.250 ist definitiv ein Telekom-Knoten (siehe hier).

Insgesamt: Ich habe keine Chance mit irgendeinem Setup bei mir bei diesem Problem weiter zu kommen!

Es scheint so zu sein, dass es aus dem Vodafone-Netz keine funktionierende Route gibt, um das Ziel (also den ING-Bank -Login hinter dem "Akamei"-CDN) zu erreichen.

@Moderator:
Wäre es möglich der Vodafone-Technik den Hinweis weiterzuleiten, den Routing- und Transit-/ Peeringpfad zum Zielnetz 185.142.178.0/24 zu prüfen? Die Route endet bei 80.157.205.250 (ein Telekom-Netzknoten), der für das Ziel 185.142.178.1 "Zielnetz nicht erreichbar" meldet.
Da Vodafone den ausgehenden Transit-/Peeringpfad auswählt, könnte dort ein Routing- oder Übergabeproblem vorliegen.

[ThomasB7]

Wegen eines Triggers für meinen Post.

@emily2505 Schau bitte mal in den vorherigen Post. Danke! 😊

[RobertP]

es gibt kein Routing Problem, die Seite ist aus dem Vodafone Kabel Netz erreichbar (gerade gestetet)

[ThomasB7]

@emily2505 

Eine Sache fällt mir gerade noch ein. Vodafone hat Wartungsarbeiten vom 29.07. bis 30.07. im Netz in userer Gegend ausgeführt.
Ankündigung per Mail und es war auch tatsächlich ein Netz-Ausfall.

Ich kann leider nicht exakt zeitlich zuordnen, ob mein ING-Verbindungsfehler auf diese Wartung zurückgeführt werden kann (dieser Termin fällt einfach nur in den Zeitraum von vorher "geht alles" zum heutigen Stand "geht nicht mehr").

[RobertP]

verwende mal testweise ein VPN

[ThomasB7]

Wenn ich VPN nutzen würde, dann sieht Akamai eine andere IP (war ja auch mit dem Tor-Browser schon der Fall). Der VPN-Provider nutzt einen anderen Peering-Partner, also genau so wie der Tor-Browser verschiedene Exit-Nodes nutzt.
VPN kommt mir wie ein Workaround vor. Ich vermute, dass ein VPN erfolgreich sein wird (wie ja auch der Tor-Browser erfolgreich war).

Aber ich will nochmal auf meine Trace kommen:
Bei Hop 8 steht "Zielnetz nicht erreichbar". Das ist ein harter Routing-Fehler!

Dass es bei Dir geht heißt nur, dass dein Segment einen funktionierenden Pfad zu einem anderen Akamai-Edge und damit zur ING-Bank erhält. Das heißt nicht, dass der Pfad in meinem Segment korrekt ist bzw. dass das Routing bei Vodafone generell korrekt ist (es gibt ja schließlich meinen Fall in dem es nicht geht). Diese Störung betrifft halt nicht alle Segmente, Routingfehler können regional sein.

Wie sieht dein Netzwerk-Trace aus?

Wenn dein Segment einen anderen Akamai Edge erhält (sollte ja im Trace gelistet sein), müsste insgesamt dein Traceroute einen anderen Pfad zeigen. Das wäre wichtig, um zu sehen, dass der Routingfehlers regional begrenzt ist.

[ThomasB7]

Der ING-Bank Zugriff geht seit heute morgen wieder völlig regulär von einem Windows Rechner aus.

Weil es ging war der erster Check: Habe ich eine neue WAN-IP bekommen?
Nein, das ist nicht der Fall, die WAN-IP ist die selbe.

Dann eben einen Netzwerk-Trace nun für den Erfolgsfall.

tracert banking.ing.de

Routenverfolgung zu banking.ing.de [185.142.178.1] über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  RT-AC68U-Router [192.168.1.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    15 ms    13 ms    10 ms  ip-081-210-145-120.um21.pools.vodafone-ip.de [81.210.145.120]
  4    43 ms    18 ms    15 ms  145.253.48.28
  5    20 ms    18 ms    20 ms  145.254.1.230
  6    17 ms    22 ms    21 ms  f-ed13-i.F.DE.NET.DTAG.DE [217.5.118.230]
  7    17 ms    22 ms    16 ms  80.157.205.250
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16     *        *        *     Zeitüberschreitung der Anforderung.
 17     *        *        *     Zeitüberschreitung der Anforderung.
 18     *        *        *     Zeitüberschreitung der Anforderung.
 19     *        *        *     Zeitüberschreitung der Anforderung.
 20     *        *        *     Zeitüberschreitung der Anforderung.
 21     *        *        *     Zeitüberschreitung der Anforderung.
 22     *        *        *     Zeitüberschreitung der Anforderung.
 23     *        *        *     Zeitüberschreitung der Anforderung.
 24     *        *        *     Zeitüberschreitung der Anforderung.
 25     *        *        *     Zeitüberschreitung der Anforderung.
 26     *        *        *     Zeitüberschreitung der Anforderung.
 27     *        *        *     Zeitüberschreitung der Anforderung.
 28     *        *        *     Zeitüberschreitung der Anforderung.
 29     *        *        *     Zeitüberschreitung der Anforderung.
 30     *        *        *     Zeitüberschreitung der Anforderung.

Ablaufverfolgung beendet.

Der Routingfehler in Hop 8 im letzten Netzwerk-Trace ist jetzt weg.

Der Netzwerkpfad wurde evtl. umgeroutet oder die Störung wurde auf dem Netzwerk-Pfad behoben.

Die "*" Antworten sind per se kein Fehler. Die Geräte auf diesem Pfad-Abschnitt antworten einfach nicht auf ICMP-Requests. Die Weiterleitung des Requests findet trotzdem statt.

Insgesamt ist zwar (scheinbar) mein Problem erstmal gelöst. Leider ist das aber nur eine Beobachtung als Aussenstehender. Was hier wirklich geändert wurde im Vodafone-Netzwerk-Setup ist unbekannt. Werde das wohl auch nie erfahren, denn falls die Vodafone-Technik eine Änderung vorgenommen hat, dann wird diese Info nie dieses Forum erreichen.

Danke für allen Input für diesen Thread.