17
Websitefehler bei HTTPS-Seiten
Hallo Zusammen,
ich habe ein merkwürdiges Problem bei dem ich nicht wirklich weiter komme.
Einer meiner Kunden, hat ein Problem mit div. HTTPS-Seiten.
Versucht er zum Beispiel https://portal.rundfunkbeitrag.de/portal/ aufzurufen, bekommt er folgenden Fehler:
Fehler: Gesicherte Verbindung fehlgeschlagen
Fehlercode: PR_CONNECT_RESET_ERROR
--> siehe Screenshot
ähnlich verhält es sich, wenn er eine E-Mail mit einem secure-email.html Anhang empfängt, den er dann öffnet -> es dauert ca. 20-30 Sekunden, bis sich die Seite des Versenders für die Anzeige der SecureMail sich öffnet. Manchmal wird die Seite dann auch noch grafisch nicht fertig gerändert.
Der Kunde hat ein einfaches Netzwerk mit drei PCs, einer NAS, einem Switch und einer FritzBox 7590. Keine Firewall oder ähnliches.
Alle drei PCs verhalten sich gleich. Virensoftware kann ausgeschlossen werden, da hier die Deinstallation schon getestet wurde.
Außerdem verhält sich mein eigenes Notebook gleich, sobald ich es vor Ort mit dem WLAN den Kunden verbinde.
In meinem eigenen Netzwerk oder über LTE kann ich mit meinem Notebook die Seiten ohne Verzögerung öffnen.
Fehler muss also an der Internetleitung des Kunden liegen.
Interessanterweise betrifft es wohl nur Windows-Geräte, denn wenn man die besagten Seiten vom iPhone öffnen will, funktioniert es ebenfalls sofort und ohne Verzögerungen (im WLAN des besagten Kunden mit deaktivierten mobilen Daten, damit das iPhone auch wirklich über das lokale Netzwerk nach draußen geht).
Hat von euch einer ne Idee?
Mein Ansatz wäre es nun mit MNET Kontakt aufzunehmen (ISP des Kunden) - habe jedoch die Befürchtung, dass mir da niemand weiterhelfen kann (1st Level Support und so....)
Danke für eure Antworten
ich habe ein merkwürdiges Problem bei dem ich nicht wirklich weiter komme.
Einer meiner Kunden, hat ein Problem mit div. HTTPS-Seiten.
Versucht er zum Beispiel https://portal.rundfunkbeitrag.de/portal/ aufzurufen, bekommt er folgenden Fehler:
Fehler: Gesicherte Verbindung fehlgeschlagen
Fehlercode: PR_CONNECT_RESET_ERROR
--> siehe Screenshot
ähnlich verhält es sich, wenn er eine E-Mail mit einem secure-email.html Anhang empfängt, den er dann öffnet -> es dauert ca. 20-30 Sekunden, bis sich die Seite des Versenders für die Anzeige der SecureMail sich öffnet. Manchmal wird die Seite dann auch noch grafisch nicht fertig gerändert.
Der Kunde hat ein einfaches Netzwerk mit drei PCs, einer NAS, einem Switch und einer FritzBox 7590. Keine Firewall oder ähnliches.
Alle drei PCs verhalten sich gleich. Virensoftware kann ausgeschlossen werden, da hier die Deinstallation schon getestet wurde.
Außerdem verhält sich mein eigenes Notebook gleich, sobald ich es vor Ort mit dem WLAN den Kunden verbinde.
In meinem eigenen Netzwerk oder über LTE kann ich mit meinem Notebook die Seiten ohne Verzögerung öffnen.
Fehler muss also an der Internetleitung des Kunden liegen.
Interessanterweise betrifft es wohl nur Windows-Geräte, denn wenn man die besagten Seiten vom iPhone öffnen will, funktioniert es ebenfalls sofort und ohne Verzögerungen (im WLAN des besagten Kunden mit deaktivierten mobilen Daten, damit das iPhone auch wirklich über das lokale Netzwerk nach draußen geht).
Hat von euch einer ne Idee?
Mein Ansatz wäre es nun mit MNET Kontakt aufzunehmen (ISP des Kunden) - habe jedoch die Befürchtung, dass mir da niemand weiterhelfen kann (1st Level Support und so....)
Danke für eure Antworten
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6792145636
Url: https://administrator.de/contentid/6792145636
Printed on: April 27, 2024 at 13:04 o'clock
17 Comments
Latest comment
Mein erster Gedanke wäre ein Kundenseitiger Proxy, etc gewesen - aber das dürf mit deinen Tests ausgeschlossen sein...
Bleibt erstmal die Frage, welcher DNS-Server im Kundennetz genutzt wird ...
... ggf. hier mal einen manuell setzen (1.1.1.1.1, 8.8.8.8, 9.9.9.9 oder MNet DNS-Adressen, etc) .... diese vei DHCP ggf. in der Fritze setzen ...
Bleibt erstmal die Frage, welcher DNS-Server im Kundennetz genutzt wird ...
... ggf. hier mal einen manuell setzen (1.1.1.1.1, 8.8.8.8, 9.9.9.9 oder MNet DNS-Adressen, etc) .... diese vei DHCP ggf. in der Fritze setzen ...
Für mich sieht das nach abgelaufenen Zertifikaten aus. Da es aber ziemlich unwahrscheinlich ist, dass die Webseiten von voneinander unabhängigen Firmen/Einrichtungen gleichzeitig veraltete Zertifikate haben würde ich an der Stelle zuerst einmal die Systemzeit des Clients überprüfen.
Außerdem kannst du natürlich auch mal anzeigen lassen wie lange die jeweiligen Zertifikate gültig sind.
Manuel
Außerdem kannst du natürlich auch mal anzeigen lassen wie lange die jeweiligen Zertifikate gültig sind.
Manuel
Mir kommen da zwei Gedanken in den Sinn:
Hat der Kunde an der Fritzbox irgendwelche Filter aktiviert? Kinderschutz oder sowas?
Hat der Kunde einen DS-Lite-Anschluss und nur mit IPv4-Seiten Probleme? Aber Sachen über IPv6 werden problemlos ausgeliefert? Dann könnte das ein Problem beim CGNAT von M-Net sein oder eine zu große MTU in der Fritzbox für den Anschluss.
Die Fehlermeldungen der Browser deuten auf ein Verbindungsproblem hin, DNS würde ich ausschließen (da würden die Fehlercodes alle mit "DNS_" beginnen), Probleme mit den Zertifikaten kann man auch ausschließen, dann hättest du entsprechende TLS-Alerts.
Hat der Kunde an der Fritzbox irgendwelche Filter aktiviert? Kinderschutz oder sowas?
Hat der Kunde einen DS-Lite-Anschluss und nur mit IPv4-Seiten Probleme? Aber Sachen über IPv6 werden problemlos ausgeliefert? Dann könnte das ein Problem beim CGNAT von M-Net sein oder eine zu große MTU in der Fritzbox für den Anschluss.
Die Fehlermeldungen der Browser deuten auf ein Verbindungsproblem hin, DNS würde ich ausschließen (da würden die Fehlercodes alle mit "DNS_" beginnen), Probleme mit den Zertifikaten kann man auch ausschließen, dann hättest du entsprechende TLS-Alerts.
1
Mach mal ein nslookup auf die URL:
Name: portal.rundfunkbeitrag.de
Und nun versuche einmal die URL mit der IP aufzurufen (testweise mit http & mit).
Müsste gehen aber mit Fehlermeldung im Browser, was aber jetzt nicht wichtig ist (Zertifikat).
Starte mal die Fritzbox neu, auf dem PC ipconfig /flushdns ausführen! Dann nochmal testen!
Name: portal.rundfunkbeitrag.de
Und nun versuche einmal die URL mit der IP aufzurufen (testweise mit http & mit).
Müsste gehen aber mit Fehlermeldung im Browser, was aber jetzt nicht wichtig ist (Zertifikat).
Starte mal die Fritzbox neu, auf dem PC ipconfig /flushdns ausführen! Dann nochmal testen!
Wie sieht es denn mit denn mit dem Fehlern in der DSL Information aus ? Sind dort (viele) nicht behebbare Fehler ?
Ich hatte dasselbe Problem bei jemandem. Dort waren auch manche Seiten von einigen Geräten nicht aufrufbar, von anderen aber problemlos. Ursache war eine Störung auf der Internetleitung
Grüße
Ich hatte dasselbe Problem bei jemandem. Dort waren auch manche Seiten von einigen Geräten nicht aufrufbar, von anderen aber problemlos. Ursache war eine Störung auf der Internetleitung
Grüße
super, vielen Dank für die vielen Antworten, versuche die Vorschläge kommende Woche dann gleich mal
Zitat von @Clark465:
ich habe ein merkwürdiges Problem bei dem ich nicht wirklich weiter komme.
Einer meiner Kunden, hat ein Problem mit div. HTTPS-Seiten.
Versucht er zum Beispiel https://portal.rundfunkbeitrag.de/portal/ aufzurufen, bekommt er folgenden Fehler:
Fehler: Gesicherte Verbindung fehlgeschlagen
Fehlercode: PR_CONNECT_RESET_ERROR
--> siehe Screenshot
Einer meiner Kunden, hat ein Problem mit div. HTTPS-Seiten.
Versucht er zum Beispiel https://portal.rundfunkbeitrag.de/portal/ aufzurufen, bekommt er folgenden Fehler:
Fehler: Gesicherte Verbindung fehlgeschlagen
Fehlercode: PR_CONNECT_RESET_ERROR
--> siehe Screenshot
Stimmen Datum und Uhrzeit auf den Client?
Warum ignorieren eigentlich so viele Leute hier die Fehlercodes, die der Browser ausgibt?
Wir haben von Firefox den Feherlcode "PR_CONNECT_RESET_ERROR" bekommen. Laut Dokumentation wird dieser Code geworfen, wenn "The (TCP) connection has been reset by the peer".
Die TCP-Verbindung zum Server wurde also von der Gegenstelle zurückgesetzt. Und das ganze muss, wir denken ans OSI-Modell, auf Schicht 4 aufgetreten sein, denn nur da gibt es TCP-Reset.
Wir wissen damit also auch, dass kein TLS-Handshake stattgefunden haben kann, denn damit dieser (Schicht 6) funktioniert müssen die darunterliegenden Schichten ja funktionieren.
Einen Fehler im Zusammenhang mit TLS und den Zertifikaten können wir daher also sicher ausschließen.
Das ist eher ein Problem mit der Internetverbindung selbst, dem Zielserver oder einer Firewall bzw. Middleware zwischen dem Browser und dem Server.
Der Fehlercode, wenn das Systemdatum nicht korrekt ist (oder das Zertifikat wirklich abgelaufen ist) wäre übrigens laut der SSL-Dokumentation vielmehr "SEC_ERROR_EXPIRED_CERTIFICATE".
Im Übrigen können wir fast sicher auch DNS-Probleme ausschließen, denn wenn wir schon beim Verbindungsaufbau zum Server sind, der dummerweise fehlgeschlagen ist, müssen wir ja schon DNS aufgelöst haben. Es schadet sicherlich nicht, über "about:networking#dns" nachzuprüfen, ob die DNS-Auflösung korrekt verlaufen ist und nicht eventuell eine unerwartete IP-Adresse zurückkam - aber wir wissen, dass DNS grundsätzlich funktioniert.
Jedoch: Das reflexartige Ausrufen von "Probier mal andere DNS-Server" ist also auch eher eine Fehlersuche nach Schrotflinten-Prinzip.
Ehrlich Leute, diese Fehlercodes sind da, um uns auf die richtige Spur zu führen, werden aber trotzdem erstaunlich beharrlich ignoriert.
Versteht mich nicht falsch, aber manchmal habe ich einfach das Gefühl, dass hier Ziel- und Planlos drauflosgeraten wird und "Hausmittelchen" empfohlen werden anstatt sich an den gelieferten Fakten zu orientieren.
Vielleicht bin ich auch zu sehr in meiner Blase gefangen und habe verzerrte Vorstellungen davon, dass OSI-Schichten zum Basiswissen gehören, da lasse ich mich gerne belehren.
1
Vielen Dank für die vielen Antworten. Ich seh das Problem auch bei MNET. Was mich allerdings etwas verwirrt ist die Tatsache, dass ich das Problem am selben Internetanschluss mit einem Handy nicht habe. Hier gehen die Seiten ohne Verzögerung auf.
An den PCs kann es wiederum aber nicht liegen, da ich es ja mit meinem eigenen Notebook auch ausprobiert habe, und an besagtem Internetanschluss dann das selbe Problem habe...
An den PCs kann es wiederum aber nicht liegen, da ich es ja mit meinem eigenen Notebook auch ausprobiert habe, und an besagtem Internetanschluss dann das selbe Problem habe...
Welche Netzwerkeinstellungen (IP-Adressen, DNS, Gateway) werden denn vom Telefon bezogen und welche vom Laptop? Vielleicht lässt sich darüber ein Unterschied finden.
Nachtrag: Bei Windows wäre im speziellen die Ausgabe von "ipconfig /all" interessant und ein Traceroute zu portal.rundfunkbeitrag.de.
Beim Telefon müsste man dafür wohl entsprechende Apps installieren, ich verwende da ganz gerne "Net Analyzer" unter Android, weil das im Gegensatz zu vielen anderen Apps Traceroutes per ICMP durchführt.
Nachtrag: Bei Windows wäre im speziellen die Ausgabe von "ipconfig /all" interessant und ein Traceroute zu portal.rundfunkbeitrag.de.
Beim Telefon müsste man dafür wohl entsprechende Apps installieren, ich verwende da ganz gerne "Net Analyzer" unter Android, weil das im Gegensatz zu vielen anderen Apps Traceroutes per ICMP durchführt.
Schönen guten Morgen,
habe jetzt mal ein paar Tests gemacht.
Getestet wurden zwei Seiten:
https://securemail.scheidle.eu/web.app
und
https://portal.rundfunkbeitrag.de/portal/
bei beiden Seiten fällt folgendes auf:
entweder die Seite braucht sehr lange zum öffnen > 20 Sekunden ODER die Seite öffnet gar nicht mit dem oben gezeigten Fehlercode ODER die Seite öffnet sich, wird aber fehlerhaft gerendert und dargestellt...
Anbei noch die Tracert und ipconfig /all:
tracert securemail.scheidle.eu
Routenverfolgung zu securemail.scheidle.eu [62.245.202.201]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms fritz.box [192.168.254.1]
2 11 ms 10 ms 11 ms ac1.agb3.m-online.net [212.18.6.30]
3 10 ms 9 ms 9 ms ae1.r2.agb1.m-online.net [82.135.16.121]
4 17 ms * 11 ms host-212-114-243-51.customer.m-online.net [212.114.243.51]
5 11 ms 10 ms 10 ms host-62-245-202-201.customer.m-online.net [62.245.202.201]
Ablaufverfolgung beendet.
tracert portal.rundfunkbeitrag.de
Routenverfolgung zu portal.rundfunkbeitrag.de [193.189.157.154]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms fritz.box [192.168.254.1]
2 10 ms 9 ms 11 ms ac1.agb3.m-online.net [212.18.6.30]
3 15 ms 13 ms 13 ms ae2.rt-decix-3.m-online.net [212.18.6.241]
4 14 ms 16 ms 14 ms stp-fftm-ir-tu01.ardstern.net [80.81.195.199]
5 20 ms 19 ms 18 ms 185.17.244.153
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
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.
ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : DESKTOP-3M58GIE
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : fritz.box
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix: fritz.box
Beschreibung. . . . . . . . . . . : Realtek Gaming GbE Family Controller
Physische Adresse . . . . . . . . : B4-2E-99-0C-03-B9
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : 2001:a61:517d:bb01:aec8:b143:60bb:4ca0(Bevorzugt)
Temporäre IPv6-Adresse. . . . . . : 2001:a61:517d:bb01:6cfa:f179:f9a1:9e21(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::b222:51b7:4ced:4a8a%14(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.254.58(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Dienstag, 18. April 2023 17:33:55
Lease läuft ab. . . . . . . . . . : Samstag, 29. April 2023 08:55:33
Standardgateway . . . . . . . . . : fe80::2e3a:fdff:fe8e:bfd5%14
192.168.254.1
DHCP-Server . . . . . . . . . . . : 192.168.254.1
DHCPv6-IAID . . . . . . . . . . . : 112471705
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-25-09-0F-C8-B4-2E-99-0C-03-B9
DNS-Server . . . . . . . . . . . : fd00::2e3a:fdff:fe8e:bfd5
2001:a61:517d:bb01:2e3a:fdff:fe8e:bfd5
192.168.254.1
fd00::2e3a:fdff:fe8e:bfd5
2001:a61:517d:bb01:2e3a:fdff:fe8e:bfd5
NetBIOS über TCP/IP . . . . . . . : Aktiviert
habe jetzt mal ein paar Tests gemacht.
Getestet wurden zwei Seiten:
https://securemail.scheidle.eu/web.app
und
https://portal.rundfunkbeitrag.de/portal/
bei beiden Seiten fällt folgendes auf:
entweder die Seite braucht sehr lange zum öffnen > 20 Sekunden ODER die Seite öffnet gar nicht mit dem oben gezeigten Fehlercode ODER die Seite öffnet sich, wird aber fehlerhaft gerendert und dargestellt...
Anbei noch die Tracert und ipconfig /all:
tracert securemail.scheidle.eu
Routenverfolgung zu securemail.scheidle.eu [62.245.202.201]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms fritz.box [192.168.254.1]
2 11 ms 10 ms 11 ms ac1.agb3.m-online.net [212.18.6.30]
3 10 ms 9 ms 9 ms ae1.r2.agb1.m-online.net [82.135.16.121]
4 17 ms * 11 ms host-212-114-243-51.customer.m-online.net [212.114.243.51]
5 11 ms 10 ms 10 ms host-62-245-202-201.customer.m-online.net [62.245.202.201]
Ablaufverfolgung beendet.
tracert portal.rundfunkbeitrag.de
Routenverfolgung zu portal.rundfunkbeitrag.de [193.189.157.154]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms fritz.box [192.168.254.1]
2 10 ms 9 ms 11 ms ac1.agb3.m-online.net [212.18.6.30]
3 15 ms 13 ms 13 ms ae2.rt-decix-3.m-online.net [212.18.6.241]
4 14 ms 16 ms 14 ms stp-fftm-ir-tu01.ardstern.net [80.81.195.199]
5 20 ms 19 ms 18 ms 185.17.244.153
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
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.
ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : DESKTOP-3M58GIE
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : fritz.box
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix: fritz.box
Beschreibung. . . . . . . . . . . : Realtek Gaming GbE Family Controller
Physische Adresse . . . . . . . . : B4-2E-99-0C-03-B9
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : 2001:a61:517d:bb01:aec8:b143:60bb:4ca0(Bevorzugt)
Temporäre IPv6-Adresse. . . . . . : 2001:a61:517d:bb01:6cfa:f179:f9a1:9e21(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::b222:51b7:4ced:4a8a%14(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.254.58(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Dienstag, 18. April 2023 17:33:55
Lease läuft ab. . . . . . . . . . : Samstag, 29. April 2023 08:55:33
Standardgateway . . . . . . . . . : fe80::2e3a:fdff:fe8e:bfd5%14
192.168.254.1
DHCP-Server . . . . . . . . . . . : 192.168.254.1
DHCPv6-IAID . . . . . . . . . . . : 112471705
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-25-09-0F-C8-B4-2E-99-0C-03-B9
DNS-Server . . . . . . . . . . . : fd00::2e3a:fdff:fe8e:bfd5
2001:a61:517d:bb01:2e3a:fdff:fe8e:bfd5
192.168.254.1
fd00::2e3a:fdff:fe8e:bfd5
2001:a61:517d:bb01:2e3a:fdff:fe8e:bfd5
NetBIOS über TCP/IP . . . . . . . : Aktiviert
@LordGurke : TOP, das du so firm in der Sache bist. Wir anderen haben halt versucht mit unserem Basiswissen eine schnelle Hilfe zu liefern und geben entsprechend Tipps, die wir zuerst probieren würden ...
... aber TOP, das es letztlich in fast allen Bereichen hier Spezialisten gibt (Y)
... aber TOP, das es letztlich in fast allen Bereichen hier Spezialisten gibt (Y)
Sorry, war bei mir etwas stressig die letzten Tage.
Aus den Daten ist leider kein offensichtlicher Fehler erkennbar, das sieht alles soweit korrekt aus.
Wenn wir davon ausgehen, dass der Router in Ordnung ist (es scheint ja scheinbar nur bei bestimmten Seiten zu passieren?) müssen wir mal mit Wireshark nachsehen.
Dafür musst du einen Versuch aufzeichnen, eine der problematischen Webseiten zu laden. Währenddessen solltest du möglichst wenig anderen Traffic haben, also z.B. das Mailprogramm schließen.
Die Aufzeichnung solltest du laufen lassen, bis der Browser mit Fehler abbricht.
In der Aufzeichnung wählst du dann eines der Pakete aus, die zur Verbindung mit der jeweiligen Webseite gehören - das erkennst du an der IP-Adresse.
Dann filtern wir uns diese Verbindung, dafür klickst du rechts auf eines dieser Pakete, wählst dann "Verbindungsfilter" -> "IPv4":
Dann scrolle durch diese Verbindung. Solltest du rot angezeigte Pakete sehen, sind das Fehler wie z.B. verloren gegangene Pakete (dann bekommen wir eine Retransmission oder Duplicate ACK) - hier mal beispielhaft an einer anderen Verbindung gezeigt:
Wenn du viele Retransmissions siehst, die du zum Server sendest, könnte das ein MTU-Problem sein.
Schaue dazu mal in der FritzBox, welche MTU für den Internetzugang eingestellt ist. Falls das ein DSL-Anschluss ist, sind normale Werte irgendwo zwischen 1492 und 1480 Bytes. Um das einfach mal zu testen, setze die MTU auf 1300 Bytes herunter und schaue, ob dann alle problematischen Seiten laden. Dann kann man in der Hinsicht weiter forschen.
Wenn du viele Duplicate ACKs siehst oder Retransmissions vom Server zu dir, könnte das auf Packetloss oder defekte Pakete hindeuten. Defekte Pakete können durch alles mögliche verursacht werden, hier solltest du auf jeden Fall dann mal die FritzBox testweise durch ein Gerät tauschen von dem du weißt, dass es funktioniert.
Wenn das Problem damit weg ist, ist die aktuelle Fritzbox defekt. Wenn das Problem bestehen bleibt, wende dich an M-Net und lass den DSL-Port überprüfen. Ich habe schon defekte DSL-Ports gesehen, die Pakete kaputtgemacht haben.
Solltest du ein TCP-Reset bekommen (das ist ja, was Firefox bemängelt), findest du diesen ganz unten in deiner gefilterten Liste. Prüfe hier, wer Absender und wer Empfänger des ersten Reset-Pakets ist.
Wenn du der Empfänger des Pakets bist, ist speziell interessant, mit welcher TTL du dieses Paket bekommst. Klicke dazu doppelt auf das Reset-Paket und schaue dir den Abschnitt "Internet Protocol" an und suche dort nach "Time To Live" oder "Hoplimit".
Merke dir den Wert und wähle ein anderes Paket in der Liste davor aus, welches du empfangen hast und vergleiche dessen Wert.
Die TTL bzw. das Hoplimit muss eigentlich identisch sein, wenn du TTL des Reset-Pakets größer ist, sitzt irgendwas in der Leitung und schließt deine Verbindung. Das kann eine Firewall(-Software) sein oder eine Funktion der FritzBox oder irgendwas bei deinem Provider. Das können wir mit der TTL dann verfolgen
Aus den Daten ist leider kein offensichtlicher Fehler erkennbar, das sieht alles soweit korrekt aus.
Wenn wir davon ausgehen, dass der Router in Ordnung ist (es scheint ja scheinbar nur bei bestimmten Seiten zu passieren?) müssen wir mal mit Wireshark nachsehen.
Dafür musst du einen Versuch aufzeichnen, eine der problematischen Webseiten zu laden. Währenddessen solltest du möglichst wenig anderen Traffic haben, also z.B. das Mailprogramm schließen.
Die Aufzeichnung solltest du laufen lassen, bis der Browser mit Fehler abbricht.
In der Aufzeichnung wählst du dann eines der Pakete aus, die zur Verbindung mit der jeweiligen Webseite gehören - das erkennst du an der IP-Adresse.
Dann filtern wir uns diese Verbindung, dafür klickst du rechts auf eines dieser Pakete, wählst dann "Verbindungsfilter" -> "IPv4":
Dann scrolle durch diese Verbindung. Solltest du rot angezeigte Pakete sehen, sind das Fehler wie z.B. verloren gegangene Pakete (dann bekommen wir eine Retransmission oder Duplicate ACK) - hier mal beispielhaft an einer anderen Verbindung gezeigt:
Wenn du viele Retransmissions siehst, die du zum Server sendest, könnte das ein MTU-Problem sein.
Schaue dazu mal in der FritzBox, welche MTU für den Internetzugang eingestellt ist. Falls das ein DSL-Anschluss ist, sind normale Werte irgendwo zwischen 1492 und 1480 Bytes. Um das einfach mal zu testen, setze die MTU auf 1300 Bytes herunter und schaue, ob dann alle problematischen Seiten laden. Dann kann man in der Hinsicht weiter forschen.
Wenn du viele Duplicate ACKs siehst oder Retransmissions vom Server zu dir, könnte das auf Packetloss oder defekte Pakete hindeuten. Defekte Pakete können durch alles mögliche verursacht werden, hier solltest du auf jeden Fall dann mal die FritzBox testweise durch ein Gerät tauschen von dem du weißt, dass es funktioniert.
Wenn das Problem damit weg ist, ist die aktuelle Fritzbox defekt. Wenn das Problem bestehen bleibt, wende dich an M-Net und lass den DSL-Port überprüfen. Ich habe schon defekte DSL-Ports gesehen, die Pakete kaputtgemacht haben.
Solltest du ein TCP-Reset bekommen (das ist ja, was Firefox bemängelt), findest du diesen ganz unten in deiner gefilterten Liste. Prüfe hier, wer Absender und wer Empfänger des ersten Reset-Pakets ist.
Wenn du der Empfänger des Pakets bist, ist speziell interessant, mit welcher TTL du dieses Paket bekommst. Klicke dazu doppelt auf das Reset-Paket und schaue dir den Abschnitt "Internet Protocol" an und suche dort nach "Time To Live" oder "Hoplimit".
Merke dir den Wert und wähle ein anderes Paket in der Liste davor aus, welches du empfangen hast und vergleiche dessen Wert.
Die TTL bzw. das Hoplimit muss eigentlich identisch sein, wenn du TTL des Reset-Pakets größer ist, sitzt irgendwas in der Leitung und schließt deine Verbindung. Das kann eine Firewall(-Software) sein oder eine Funktion der FritzBox oder irgendwas bei deinem Provider. Das können wir mit der TTL dann verfolgen
@LordGurke ich wollte hier kein neues Thema anfangen, da es bereits eröffnet wurde. Ich habe 2 verschiedene Fehlermeldungen:
Wenn ich meine Fritz7590 aufrufen will kommt:
Fehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Website könnte vorübergehend nicht erreichbar sein, versuchen Sie es bitte später nochmals.
Wenn Sie auch keine andere Website aufrufen können, überprüfen Sie bitte die Netzwerk-/Internetverbindung.
Wenn Ihr Computer oder Netzwerk von einer Firewall oder einem Proxy geschützt wird, stellen Sie bitte sicher, dass Firefox auf das Internet zugreifen darf.
Rufe ich egal welche andere URL auf, kommt die Fehlermeldung "PR_CONNECT_RESET_ERROR", die oben schon diskutiert wurde.
Das passierte sozusagen über Nacht. Abends PC runtergefahren, alles o.K.
Morgens wieder eingeschaltet: Firefox "tot".
Alle anderen Browser (Chrome, Edge, Opera) getestet, alles einwandfrei!
FF im Modus ohne Erweiterungen gestartet. Keine Änderung. Aktualisiert auf 124.02, keine Änderung
Unter HTTP Netzwerkverbindungen sehen alle Urls von mozilla so aus:
Hostname Port HTTP-Version SSL Aktiv Untätig
content-signature-2.cdn.mozilla.net 443 HTTP <= 1.1 true 0 0
bis auf die Fritzbox. Dort steht nicht true sondern false
192.168.178.1 80 HTTP <= 1.1 false 0 0
Das einzige, was ich noch nicht gemacht habe, ist FF komplett deinstallieren und neu einspielen. Wenn ich das mache sollte ich da sicherheitshalber mein Profil in einem anderen Ordner sichern?
Jetzt bin ich mit meinem Latein am Ende. Leider brauche ich den FF, weil da sehr viele Sites mit Passworten gespeichert sind. Oder kann ich das FF-Profil in einen anderen Browser komplett exportieren.
Vergessen zu sagen: Auf die Einstellungen von FF kann ich noch zugreifen, weil die wohl Offline abrufbar sind!?
Ich habe übrigens WIN 10 und Glasfaser über WAN an der 7590.
Ich hoffe ich kann mein Problem plausibel rüberbringen und ich danke schon mal für eine Antwort.
Wenn ich meine Fritz7590 aufrufen will kommt:
Fehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Website könnte vorübergehend nicht erreichbar sein, versuchen Sie es bitte später nochmals.
Wenn Sie auch keine andere Website aufrufen können, überprüfen Sie bitte die Netzwerk-/Internetverbindung.
Wenn Ihr Computer oder Netzwerk von einer Firewall oder einem Proxy geschützt wird, stellen Sie bitte sicher, dass Firefox auf das Internet zugreifen darf.
Rufe ich egal welche andere URL auf, kommt die Fehlermeldung "PR_CONNECT_RESET_ERROR", die oben schon diskutiert wurde.
Das passierte sozusagen über Nacht. Abends PC runtergefahren, alles o.K.
Morgens wieder eingeschaltet: Firefox "tot".
Alle anderen Browser (Chrome, Edge, Opera) getestet, alles einwandfrei!
FF im Modus ohne Erweiterungen gestartet. Keine Änderung. Aktualisiert auf 124.02, keine Änderung
Unter HTTP Netzwerkverbindungen sehen alle Urls von mozilla so aus:
Hostname Port HTTP-Version SSL Aktiv Untätig
content-signature-2.cdn.mozilla.net 443 HTTP <= 1.1 true 0 0
bis auf die Fritzbox. Dort steht nicht true sondern false
192.168.178.1 80 HTTP <= 1.1 false 0 0
Das einzige, was ich noch nicht gemacht habe, ist FF komplett deinstallieren und neu einspielen. Wenn ich das mache sollte ich da sicherheitshalber mein Profil in einem anderen Ordner sichern?
Jetzt bin ich mit meinem Latein am Ende. Leider brauche ich den FF, weil da sehr viele Sites mit Passworten gespeichert sind. Oder kann ich das FF-Profil in einen anderen Browser komplett exportieren.
Vergessen zu sagen: Auf die Einstellungen von FF kann ich noch zugreifen, weil die wohl Offline abrufbar sind!?
Ich habe übrigens WIN 10 und Glasfaser über WAN an der 7590.
Ich hoffe ich kann mein Problem plausibel rüberbringen und ich danke schon mal für eine Antwort.
Ich habe noch mal geprüft. Bei https kommt diese spezielle Fehlermeldung. Bei http kommt nur die "normale" Fehlermeldung wie beim Aufruf der Fritzbox!
Auch habe ich ich Firefox komplett gelöscht und neu installiert ohne altem Profil. Trotzdem identische Fehlermeldung!
Könnte es auch an "Deutsche Glasfaser" liegen? Glasfaser habe ich erst seit 4 Wochen.
Auch habe ich ich Firefox komplett gelöscht und neu installiert ohne altem Profil. Trotzdem identische Fehlermeldung!
Könnte es auch an "Deutsche Glasfaser" liegen? Glasfaser habe ich erst seit 4 Wochen.
Bei einem ähnlichen Problem war es bei damals die Fritzbox OS Version - diese hatte einen bekannten Bug und konnte deshalb bestimmte Websites nicht mehr öffnen (oder nur extrem zeitverzögert).
Habe dann ein Downgrade der Firmware auf der Fritzbox gemacht, automatische Updates an der Box deaktiviert und alles hat wieder wie gewohnt funktioniert.
Habe dann ein Downgrade der Firmware auf der Fritzbox gemacht, automatische Updates an der Box deaktiviert und alles hat wieder wie gewohnt funktioniert.
Es geht ja mit allen anderen Browsern, nur nicht mit Firefox. Und die Fritzbox hatte ihr update schon Tage vorher.