9
Internetseiten Auruf dauert ewig lange - checksum Fehler?!
Guten Morgen Zusammen,
ich habe hier ein ständiges Problem mit dem Aufruf von Internetseiten (z.b. Bild.de, adobe.com, amazon.com, etc.). Merkwürdigerweise ist es auch Zeitabhänig.
Anhand von dem Beispiel bild.de: Bei dem Aurufen um die Mittagszeit (so bis 15Uhr) werden keine Bilder mehr auf der Seite geladen. Text und so weiter ist alles da.
Bei Adobe wird keine Kommunikation zu dem Server wwwimages.adobe.com aufgebaut (dort liegen wohl Bilder Stylesheets, etc). Nach langer Ezit läd die Seite dann aber ohne Bilder, ohne Stylesheets, etc. So richtig Oldschool nut mit Text und blauen links ;) Selbe ist bei Amazon, wenn man z.b. "Mein Konto" aufruft.
Nun hab ich mal Wireshark angeschmissen und das einzigste was mir beim Verbindungsaufbau aufgefallen ist, ist das (kommt bei fast jeder http anfrage (SYN, ACK, etc.):
2838 17.375529 SRC_IP DEST_IP TCP 54 49763 > http [FIN, ACK] Seq=2035 Ack=4583 Win=66024 Len=0
Header checksum: 0x0000 [incorrect, should be 0x456e (maybe caused by "IP checksum offload"?)]
Bad: True
Expert Info (Error/Checksum): Bad checksum
Message: Bad checksum
Severity level: Error
Oder hat das damit Überhaupt nichts zu tun?
Da dies das das gesamte Netzwerk betrifft, also nicht Geräte Abhänig ist, habe ich irgendwie unsere ASA in Verdacht .
Hätte jemand eine Idee? Mir sind sie nämlich ausgegangen.
Gruß
ich habe hier ein ständiges Problem mit dem Aufruf von Internetseiten (z.b. Bild.de, adobe.com, amazon.com, etc.). Merkwürdigerweise ist es auch Zeitabhänig.
Anhand von dem Beispiel bild.de: Bei dem Aurufen um die Mittagszeit (so bis 15Uhr) werden keine Bilder mehr auf der Seite geladen. Text und so weiter ist alles da.
Bei Adobe wird keine Kommunikation zu dem Server wwwimages.adobe.com aufgebaut (dort liegen wohl Bilder Stylesheets, etc). Nach langer Ezit läd die Seite dann aber ohne Bilder, ohne Stylesheets, etc. So richtig Oldschool nut mit Text und blauen links ;) Selbe ist bei Amazon, wenn man z.b. "Mein Konto" aufruft.
Nun hab ich mal Wireshark angeschmissen und das einzigste was mir beim Verbindungsaufbau aufgefallen ist, ist das (kommt bei fast jeder http anfrage (SYN, ACK, etc.):
2838 17.375529 SRC_IP DEST_IP TCP 54 49763 > http [FIN, ACK] Seq=2035 Ack=4583 Win=66024 Len=0
Header checksum: 0x0000 [incorrect, should be 0x456e (maybe caused by "IP checksum offload"?)]
Bad: True
Expert Info (Error/Checksum): Bad checksum
Message: Bad checksum
Severity level: Error
Oder hat das damit Überhaupt nichts zu tun?
Da dies das das gesamte Netzwerk betrifft, also nicht Geräte Abhänig ist, habe ich irgendwie unsere ASA in Verdacht .
Hätte jemand eine Idee? Mir sind sie nämlich ausgegangen.
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 174434
Url: https://administrator.de/contentid/174434
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
9 Kommentare
Neuester Kommentar
Wireshark sagt dazu folgendes: Turn off the checksum offloading in the network driver, if this option is available.
Die andere Aussage wäre diese Checksum-Überprüfung allgemein für TCP-Protokolle abzuschalten. Wo und wie das gehen soll, kann ich dir aber nicht sagen. Vielleicht hilft dir das schon.
Die andere Aussage wäre diese Checksum-Überprüfung allgemein für TCP-Protokolle abzuschalten. Wo und wie das gehen soll, kann ich dir aber nicht sagen. Vielleicht hilft dir das schon.
ja das hab ich auch gefunden. Scheint als wäre dieser Fehler kein Fehler. WAs mich aber kein bisschen weiter bringt, mit meinem eigentlichen Problem, dass die Webseiten sich nicht aufbauen.
Scheint als wäre dieser Fehler kein Fehler.
Das ist auch kein Fehler, sondern ein Feature von Netzwerkkarten um höheren Durchsatz zu erreichen.
Aber diese Prüfung sagt doch aus, dass die Pakete nicht richtig ankommen. Gibt es vielleicht einen IP-Adresskonflikt, eine falsche NAT-Konfiguration? Wie kommen denn die Rechner ins Netz?
Als Gateway dient eine ASA 5510.
IP Adress Konflikt ist mir nicht bekannt, da wir feste IPs haben (nach drausssen). Die IP, nach außen, erscheint in der Konfig auch nur einmal:
IP Adress Konflikt ist mir nicht bekannt, da wir feste IPs haben (nach drausssen). Die IP, nach außen, erscheint in der Konfig auch nur einmal:
Was mir noch auffällt, es scheint immer in Zusammenhang mit Bildern zus tehen. Bei adobe war es, wie geschrieben, wwwimages.adobe.com. Bei amazon ist es ssl-images-amazon.com.
Bei Facebook werden z.b. auch keine Profilbilder geladen.
Bei einem Versuch mit einer "Tunnel" Webseite, wird alles ordentlich geladen...hmpf...
Bei Facebook werden z.b. auch keine Profilbilder geladen.
Bei einem Versuch mit einer "Tunnel" Webseite, wird alles ordentlich geladen...hmpf...
Ich glaube nicht, dass das von dir beschriebene Verhalten des Windows TCP/IP-Stacks die Ursache deines eigentlichen Problems ist.
Zuerst einmal würde ich einen Capture am WAN-Interface der ASA anschmeißen und diesen analysieren, um auch wirklich alles sehen zu können.
Weiterhin:
- Tritt dieses Verhalten evtl. nur bei verschlüsselten Seitenaufrufen auf?
- Blockt die ASA relevanten Traffic?
- Sind im Log Einträge bzgl. NAT zu sehen?
Zuerst einmal würde ich einen Capture am WAN-Interface der ASA anschmeißen und diesen analysieren, um auch wirklich alles sehen zu können.
Weiterhin:
- Tritt dieses Verhalten evtl. nur bei verschlüsselten Seitenaufrufen auf?
- Blockt die ASA relevanten Traffic?
- Sind im Log Einträge bzgl. NAT zu sehen?
Hi, habe heut noch bissi rum geschaut.
Dieser Fehler tritt nur, bei Inhalten auf, die von der Firma akamai gehostet werden. (dazu zählen Teile (z.b. Bilder) von: adobe, facebook, audi, ebay, amazon, bild, etc.).
Auf der Firewall habe ich nur gesehen, dass bei den Seiten Aufrufen dann nur Timeouts zurück kommen.
Dieser Fehler tritt nur, bei Inhalten auf, die von der Firma akamai gehostet werden. (dazu zählen Teile (z.b. Bilder) von: adobe, facebook, audi, ebay, amazon, bild, etc.).
Auf der Firewall habe ich nur gesehen, dass bei den Seiten Aufrufen dann nur Timeouts zurück kommen.
So Thema gelöst. Es war ein DNS Problem mit den DNS Servern unseres Providers. Die haben jetzt irgendwelche Konfigurationsänderungen durchgeführt und jetzt geht alles wieder.
