O2 DSL IPv6 : Immer wieder TCP Verbindungsreset bei Zugriff auf Cloudflare IPv6 Adressen.

Hallo @Dirac-Impuls 

Willkommen zurück in unserer o2 Community hier. Long time no see und dann gleich mit so einem knackigen Thema 😄

Ich gebe zu, ich habe nur die Hälfte verstanden. Falls deine Herausforderungen noch aktuell sind suchen wir gerne mal jemanden im Unternehmen, die da vielleicht etwas mehr zu sagen können.

@pufferueberlauf0 Du steckst doch auch so krass tief in der Materie drin, das könnte auch ein Thema für dich und deine beeindruckenden Skillz sein 😊

VG Matze 

Ich kann das Problem bei meinem Anschluss nicht nachstellen, die problematische IPv6 Adresse funktioniert bei mir wie erwartet. Ich habe auch keine echte Idee was da passiert, tut mir leid.

Moin,

hier gibt es auch keine Probleme.

@schluej 

So a lá ...”Gehen sie weiter hier, gibt es nichts zu sehen?

Gut, das sind mir die liebsten Fälle, danke 😁

VG Matze 

Das gleiche Problem existiert hier weiterhin unverändert:

wget --progress=dot  -O/dev/null -6 https://understandingwar.org
--2023-08-07 13:47:42--  https://understandingwar.org/
Resolving understandingwar.org (understandingwar.org)... 2606:4700:10::6816:4f94, 2606:4700:10::ac43:1963, 2606:4700:10::6816:4e94
Connecting to understandingwar.org (understandingwar.org)|2606:4700:10::6816:4f94|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

(und auch auf anderen Webseiten)

Falls das bei euch nicht  mit dem obigen Kommando reproduzierbar ist, weil der je nach Region eine andere IPv6 Adresse (also einen anderen Cloudflare Server) benutzt: bei curl kann man explizit eine bestimmte IPv6 Adresse angeben, vielleicht lässt sich damit das Problem nachsstellen?

curl -v --resolve understandingwar.org:443:[2606:4700:10::ac43:1963] -6 https://understandingwar.org > /dev/null

Im Fehlerfall sieht das hier so aus:

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* OpenSSL SSL_connect: Connection reset by peer in connection to understandingwar.org:443 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to understandingwar.org:443 

Der Fehler tritt hier derzeit bei ca 50% der Versuche auf.  Ist ein VDSL Bitstream Internet Zugang mit einem Vigor PPPoE modem, im PPPoE Betrieb an einem Linux Rechner.  Der ganze IP stack läuft also hier auf meinem Linux Rechner auf einem Linux Kernel v6.1.  Kann mir deshalb nicht vorstellen, dass das Problem auf meiner Seite der Verbindung liegt.

Mmmh, das funktioniert so wie es soll, also keine resets (unter Ubuntu 22 LTS, x86_64, Kernel 5.15.0). Allerdings habe ich wie mnn sieht:

user@1234-12345:/usr/bin$ curl --version
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.15
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

OpenSSL in Verwendung statt GnuTLS...

@Dirac-Impuls Da du ja -so scheint es- ein manuell erstelltes und in Eigenregie betriebenes Setup benutzt, wäre es da nicht denkbar, dass der Fehler vielleicht nicht auf unserer Seite entsteht? 

Wie machen sich die Einschränkungen denn im Daily Business genau bemerkbar? Vielleicht magst du das noch kurz erklären (wenn möglich bitte so, dass man da keinen Master in Informatik braucht, ich muss dem ganzen auch folgen können 😄).

Ganz lieben Dank.

VG Matze 

Ich hoffe Mal, ich darf diesen Beitrag wiederbeleben :D

Nach langem Suchen habe ich endlich diesen Beitrag gefunden - ich habe ein sehr ähnliches bzw. vermutlich identisches Problem mit meinem DSL Anschluss. Mit dem obigen MRE kann ich das auch teilweise reproduzieren - ich habe das Problem ebenso nur teilweise:

pierre@macbookair ~ % curl -v --resolve 'understandingwar.org:443:[2606:4700:10::ac43:1963]' -6 https://understandingwar.org > /dev/null
* Added understandingwar.org:443:[2606:4700:10::ac43:1963] to DNS cache
* Hostname understandingwar.org was found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [2606:4700:10::ac43:1963]:443...
* Connected to understandingwar.org (2606:4700:10::ac43:1963) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [325 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) Recv failure: Connection reset by peer




pierre@macbookair ~ % curl -v --resolve 'understandingwar.org:443:[2606:4700:10::ac43:1963]' -6 https://understandingwar.org > /dev/null
* Added understandingwar.org:443:[2606:4700:10::ac43:1963] to DNS cache
* Hostname understandingwar.org was found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [2606:4700:10::ac43:1963]:443...
* Connected to understandingwar.org (2606:4700:10::ac43:1963) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [325 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [4182 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=understandingwar.org
*  start date: Sep  3 07:23:56 2023 GMT
*  expire date: Dec  2 07:23:55 2023 GMT
*  subjectAltName: host "understandingwar.org" matched cert's "understandingwar.org"
*  issuer: C=US; O=Let's Encrypt; CN=E1
*  SSL certificate verify ok.
* using HTTP/2
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: understandingwar.org]
* h2 [:path: /]
* h2 [user-agent: curl/8.1.2]
* h2 [accept: */*]
* Using Stream ID: 1 (easy handle 0x159812e00)
> GET / HTTP/2
> Host: understandingwar.org
> User-Agent: curl/8.1.2
> Accept: */*
> 
< HTTP/2 200 
< date: Fri, 29 Sep 2023 21:00:14 GMT
< content-type: text/html; charset=utf-8
< x-content-type-options: nosniff
< x-powered-by: PHP/7.4.21
< x-drupal-cache: HIT
< cache-control: public, max-age=60
< content-language: en
< x-frame-options: SAMEORIGIN
< permissions-policy: interest-cohort=()
< x-generator: Drupal 7 (http://drupal.org)
< last-modified: Fri, 29 Sep 2023 20:58:00 GMT
< expires: Sun, 19 Nov 1978 05:00:00 GMT
< vary: Cookie,Accept-Encoding
< x-varnish: 311605325 309347596
< age: 12
< via: 1.1 varnish (Varnish/6.0)
< cf-cache-status: DYNAMIC
< server: cloudflare
< cf-ray: 80e7278c4e2cbbfe-FRA
< 
{ [41575 bytes data]
100 49006    0 49006    0     0   104k      0 --:--:-- --:--:-- --:--:--  104k
* Connection #0 to host understandingwar.org left intact

Ich konnte nach einigen Tests auch feststellen, sobald ich in den Netzwerkeinstellungen meines Macbook Airs die IPv6 auf Link-Local beschränke treten die Probleme nicht mehr auf. In meiner Fritz!Box bekomme ich auch IPv6 Adressen von Telefonica - daher kann ich mir das Problem auf meiner Seite ebenso schwer erklären. 

Beste Grüße

Ah, und um den zweiten Absatz zu beantworten - macht sich ziemlich stark bemerkbar. IPv6 ist nicht nutzbar, da jeder dritte Website-Aufruf an Cloudflare fehlschlägt. Merkbar direkt in Safari / Firefox / anderer Browser deiner Wahl, wenn man den Tab 10x neu laden muss bis zumindest ein Teil der Seite lädt. Ansonsten Desktopanwendungen welche Anfragen an die Server der Apps machen um bspw. Updates oder Inhalte herunterzuladen → App muss teilweise 10x neu gestartet werden bis man in die App hereinkommt.

Aber mir scheint auch, dass es ein Cloudflare-spezifisches Problem zu sein scheint. Basierend auf einem anderen Beitrag und einer Antwort eines O2 Mitarbeiters habe ich in der FritzBox die IPv6-Anbindung auf “Native IPv6-Anbindung verwenden” gestellt. Als DNS verwende ich nicht die O2 DNS Server (ich möchte ungern 10 Sekunden auf eine DNS-Antwort warten - und der DNS ist ja offensichtlich nicht das Problem, die Adressen werden ja problemlos aufgelöst. Passiert ja erst beim TLS Handshake):

@PierreIsHere, das würde mich auch ziemlich nerven, wenn jede dritte Website an Cloudlflare fehlschlägt. Oder jeden Tab 10x neu laden muss, bis dieser mal ordnungsgemäß geöffnet werden kann.

Hat hier aus der Community noch jemand, vielleicht ähnliche Herausforderungen und kann noch unterstützen?

LG Steffen

Abend,

Mich betrifft das Problem auch. Etwa 20-30% aller HTTP Requests zu Cloudflare (AS13335) oder Neocities (AS395409) werden direkt nach den Request Headers mit einen RST gekillt.

tcpdump (IP gekürzt, checksummen stimmen nur scheinbar nicht wegen checksum offloading):

17:10:26.767312 IP6 (flowlabel 0xc171b, hlim 255, next-header TCP (6) payload length: 549) 2a01:c23:6020:{schnipp}.51244 > 2620:2:6000::a:1.443: Flags [P.], cksum 0xa808 (incorrect -> 0x4fdb), seq 1:518, ack 1, win 504, options [nop,nop,TS val 1455959587 ecr 218038680], length 517
17:10:26.805084 IP6 (flowlabel 0x93cc1, hlim 52, next-header TCP (6) payload length: 20) 2620:2:6000::a:1.443 > 2a01:c23:6020:{schnapp}.51244: Flags [R], cksum 0xda28 (correct), seq 53043914, win 0, length 0

Scheint aber nur IPv6 zu betreffen. IPv6 ausschalten ist bei mir aber keine Option.

Hier müsste mal geprüft werden, ob das RST von Telefonica oder von Cloudflare kommt.

LG

Ich habe das gleiche Problem.
Etwa 25% der Verbindungen zu Seiten, die bei Cloudflare liegen, können nicht hergestellt werden. In wireshark sieht man in diesen Fällen immer die gleichen 5 Pakete:

• 0.000s [> ausgehend] SYN
• 0.025s [< eingehend] SYN, ACK
• 0.025s [> ausgehend] ACK
• 0.027s [> ausgehend] Client Hello
• 0.052s [< eingehend] RST

Bei einem Ping von 25ms zum betreffenden Server wird deutlich, dass RST eine Antwort auf das Client Hello ist. In Fällen, in denen der Verbindungsaufbau klappt (mit einem quasi-identischen Client Hello Paket), empfange ich statt des RST ein ACK + Server Hello.

Die Probleme habe ich nur mit IPv6 und treten bei diversen Seiten seit einigen Wochen verstärkt auf. Zum Nachstellen konnte ich gut openstreetmap.org nutzen. IPv6 zu deaktivieren ist bei mir auch keine Option.

Ich nutze eine Fritz!Box 7490 mit aktuellem Fritz!OS. Betroffen sind im Netzwerk alle Geräte, die über IPv6 eine Verbindung aufbauen wollen: ein Handy mit Android 9 und zwei Laptops mit Linux (Fedora 40).

Hallo @nokiaaxdontcry und @derp_96883, willkommen hier in unserer o2 Community :-)

Ein spannendes Thema, was ihr mitgebracht habt. Ich habe mal auf die Schnell ein wenig herum probiert, natürlich klappt bei mir alles, Trace auf IPv6 und IPv4 läuft ohne Einschränkungen mit rund 10ms durch, Cloudflare lässt sich einwandfrei wiederholt laden (und die Seite wurde auch via IPv6 aufgerufen), zumindest bei mir sieht also alles so aus, wie es soll.

Zumindest von meiner Seite aus kann ich das so erst einmal nicht nachvollziehen, es ist also schon einmal nichts, das pauschal auftritt.

Falls es auch weiterhin zu dieser Einschränkung kommen sollte, stellt bitte sicher, dass da nicht eventuell eine VPN-Verbindung dazwischen funken könnte und führt gerne einmal einen Trace auf den Server durch, wo ihr aktuell diese Einschränkungen habt und postet diesen Trace dann hier.

So lassen sich unter Umständen da schon einmal Gemeinsamkeiten ableiten oder eventuell wird dort auch schon eine mögliche Ursache eingegrenzt.

Gruß,

Lars

Hallo @o2_Lars ,

ich freue mich, dass wir diesen Thread gefunden haben, da wir das gleiche Problem bei unseren Kunden, die O2 in Berlin nutzen, feststellen. Viele unserer Kunden haben sich beschwert, dass unsere iOS-Anwendung bei ihnen nicht funktioniert. Wir haben herausgefunden, dass 99 % dieser Probleme mit dem SSL-Handshake zusammenhängen, bei dem der Server ein RST sendet, wie in dem obigen Thread beschrieben. Unsere Daten zeigen, dass die Mehrheit der betroffenen Anfragen von Benutzern aus Berlin stammt, die O2 verwenden.

Kürzlich konnten wir das Problem mit einem unserer Kollegen reproduzieren, der O2 und FritzBox auf seinem iPhone nutzt. Interessanterweise tritt dieses Problem nur auf dem iPhone auf, und wir beobachten dasselbe Verhalten bei mehreren iPhone-Anwendungen, die versuchen, eine Verbindung zu Servern herzustellen, die hinter Cloudflare gehostet werden.

Bei unserem Kollegen tritt das Problem nur bei einer Teilmenge der zugewiesenen IP-Adressen auf. Wenn er seinen Router neu verbindet, wird eine neue IP-Adresse zugewiesen, und einige IP-Adressen scheinen überhaupt nicht betroffen zu sein.

Wir sind gerne bereit, weitere Informationen bereitzustellen oder bei der Fehlersuche zu helfen, da dies derzeit viele unserer Kunden betrifft.

In der Zwischenzeit haben wir einen Fall bei Cloudflare eröffnet, um zu sehen, ob von deren Seite aus etwas unternommen werden kann, und wir warten auf eine Antwort. Wir werden diesen Thread auch in dem Cloudflare-Fall erwähnen.

Viele Grüße

Martin Hlavac

Hallo @mhlavac und willkommen hier in unserer o2 Community :-)

Spannende Sache und gleich schon auf einen Großraum eingegrenzt, das nenne ich mal einen netten Einstieg hier bei uns :-)

Danke, dass du dich und den Anschluss deines Kollegen zur Verfügung stellst, ich bin da guter Dinge, dass uns das ein paar interessante Daten liefern wird :-)

Schick wäre es, wenn du beziehungsweise dein Kollege einmal einen Traceroute durchführen könnte einmal, wenn alles funktioniert und dann einmal, wenn es nicht funktioniert.

Vielleicht lässt sich da schon eine mögliche Ursache weiter eingrenzen.

Ich schreib dir gleich noch eine Privatnachricht, die findest du dann bei dir im Posteingang, für den Fall, dass du die Traces nicht öffentlich posten möchtest.

Gruß,

Lars

Hallo @o2_Lars,
danke für deine Nachfragen! Ich sitze mit meinem DSL-Anschluss übrigens auch in Berlin.

Es liegt aber nicht direkt am TLS-Handshake. Bei einem HTTP-Zugriff wird ebenfalls das erste Paket nach dem ACK mit einem RST beantwortet. Bei TLS ist es das “Client Hello”, ohne TLS die HTTP-Anfrage (z.B. “GET / HTTP/1.1 ...”).

Da ich sowohl mit OpenStreetMap, als auch mit “understandingwar.org” (aus dem ersten Post) das Verhalten nachstellen kann, hier die Traceroutes (mit 8 statt 3 Queries pro Hop) zu beiden Domains:

traceroute to www.openstreetmap.org (2606:4700:3034::6815:5842), 30 hops max, 80 byte packets
 1  [fritz.box]  3.931 ms  4.151 ms  4.674 ms  4.926 ms  5.749 ms  5.728 ms * *
 2  2a02:3001::124  18.485 ms  19.104 ms  19.988 ms  20.687 ms  20.970 ms  22.130 ms  22.418 ms  22.405 ms
 3  * * 2a02:3001::1ca  18.986 ms  20.781 ms * * * *
 4  ::ffff:62.52.192.168  23.931 ms * *  28.503 ms * * *  25.475 ms
 5  ::ffff:62.52.192.234  29.042 ms  27.271 ms  26.503 ms * * * ::ffff:62.52.193.55  25.237 ms ::ffff:62.52.192.234  26.481 ms
 6  2a02:3001::3f  24.108 ms 2a02:3001::6b  27.101 ms 2a02:3001::3f  27.340 ms 2a02:3001::26a  24.492 ms 2a02:3001::3f  24.094 ms 2a02:3001::26b  25.108 ms  24.369 ms 2a02:3001::3f  22.824 ms
 7  * * * * 2001:7f8:2c:1000:0:1a95:0:1  23.777 ms * * *
 8  2400:cb00:100:1024::ac44:6d58  24.165 ms 2001:7f8:8:20:0:3417:0:1  24.496 ms  24.031 ms 2400:cb00:472:3::  23.611 ms 2001:7f8:8:20:0:3417:0:1  23.958 ms 2400:cb00:100:1024::ac44:6d1e  28.909 ms 2400:cb00:100:1024::ac44:6d65  25.263 ms 2001:7f8:8:20:0:3417:0:1  23.210 ms

traceroute to understandingwar.org (2606:4700:10::6816:4e94), 30 hops max, 80 byte packets
 1  [fritz.box]  3.947 ms  4.142 ms  4.678 ms  5.277 ms  5.797 ms  5.781 ms * *
 2  2a02:3001::124  18.186 ms  18.431 ms  21.779 ms  22.036 ms  22.824 ms  33.397 ms  33.656 ms  33.898 ms
 3  2a02:3001::1ca  30.141 ms *  29.331 ms  28.734 ms *  28.122 ms  19.819 ms *
 4  * * * ::ffff:62.52.192.168  36.556 ms  34.428 ms  24.020 ms *  28.559 ms
 5  * ::ffff:62.52.192.234  26.785 ms * *  27.922 ms * *  22.754 ms
 6  2a02:3001::2d9  26.823 ms  25.890 ms 2a02:3001::2da  26.276 ms 2a02:3001::26a  24.152 ms 2a02:3001::2da  26.394 ms 2a02:3001::26b  24.123 ms 2a02:3001::26a  24.071 ms 2a02:3001::2da  26.473 ms
 7  2a02:3001::13e  21.574 ms *  25.483 ms  25.387 ms *  26.033 ms * *
 8  2001:7f8:8:20:0:3417:0:1  33.324 ms 2001:7f8:2c:1000:0:3417:0:1  29.544 ms 2400:cb00:609:3::  22.545 ms 2001:7f8:8:20:0:3417:0:1  30.354 ms 2001:7f8:2c:1000:0:3417:0:1  29.966 ms 2001:7f8:8:20:0:3417:0:1  24.406 ms  28.353 ms 2400:cb00:471:3::  24.513 ms
 9  2400:cb00:609:1024::ac47:f926  25.130 ms 2400:cb00:696:3::  25.669 ms 2400:cb00:471:3::  27.185 ms 2400:cb00:472:3::  28.805 ms 2400:cb00:100:1024::ac44:6d1e  27.879 ms 2400:cb00:71:3::  22.909 ms 2400:cb00:470:1024::ac46:f1c5  22.785 ms 2400:cb00:472:3::  24.054 ms

Interessant ist dabei, dass beide Server mir über die Kopfzeilen (curl -I [url]) mitteilen, dass sie in München oder Frankfurt stehen:
CF-RAY: [hash]-MUC
bzw.
CF-RAY: [hash]-FRA

Bei andere Seiten, die über Cloudflare laufen, aber keine Probleme machen, habe ich FRA oder MUC nie gesehen. OpenAI.com antwortet bspw. immer aus Warschau (CF-RAY: [hash]-WAW) mit folgendem traceroute:

traceroute to www.openai.com (2606:4700::6812:849), 30 hops max, 80 byte packets
 1  [fritz.box]  4.327 ms * * * * * * *
 2  2a02:3001::124  49.209 ms  49.503 ms  50.476 ms  51.086 ms  51.708 ms  51.983 ms  51.957 ms  51.928 ms
 3  2a02:3001::1ca  17.162 ms  12.981 ms * * * * * *
 4  2a02:3001::216  10.451 ms  18.557 ms  10.437 ms  10.771 ms  11.494 ms  11.109 ms  11.307 ms  11.418 ms
 5  2001:7f8:19:1::3417:1  14.874 ms  14.525 ms  14.403 ms  14.629 ms  15.274 ms  14.210 ms  11.737 ms  12.548 ms
 6  2400:cb00:67:1024::a29e:7051  12.420 ms 2400:cb00:67:1024::a29e:7050  13.181 ms 2400:cb00:67:1024::a29e:7056  12.540 ms 2400:cb00:67:1024::a29e:7053  12.565 ms 2400:cb00:67:1024::a29e:706d  12.654 ms 2400:cb00:67:1024::a29e:7056  12.898 ms 2400:cb00:67:1024::a29e:7054  13.144 ms 2400:cb00:67:1024::a29e:7055  13.398 ms

Gruß

Danke dir, @derp_96883 :-)

Damit lässt sich doch schon mal was anfangen und einen ersten Verdacht habe ich da auch schon.

Auch, wenn wir selbst da nicht eingreifen können, kennen wir da doch den einen und anderen Menschen, der sich das gerne mal anschaut. Mit den Traces sollte sich da bestimmt etwas heraus bekommen lassen.

Auf jeden Fall auch spannend zu sehen, dass deine Fritzbox genau das gleiche Verhalten an den Tag legt wie meine, wenn da mal mehr als ein Trace parallel laufen, meine lässt da auch gerne mal ein paar Pakete unter den Tisch fallen ^^

Also, ich geb das direkt mal intern weiter, spätestens sobald es dazu etwas neues geben sollte, melde ich mich hier  :-)

Gruß,

Lars

Eine kurze Info in die Runde: Das ganze ist intern adressiert, wenn ihr im Großraum Berlin ebenfalls Herausforderungen mit Cloudflare-Diensten haben solltet, lasst uns gerne einen Trace zu den jeweiligen Adressen da, das werde ich dann zu den bereits bestehenden dazu packen. Ich bin guter Dinge, dass wir das hinbekommen werden :-)

Gruß,

Lars

Hallo allerseits, es gibt frische Neuigkeiten :-)

Es gab auf einigen Netzelementen ein paar Herausforderungen, dies konnte behoben werden.

Bitte prüft einmal, ob es auch weiterhin zu Einschränkungen mit Cloudflare-Diensten kommt. Ich klopfe auf Holz, dass jetzt alles so läuft, wie es laufen soll :-)

Gruß,

Lars

Moin @o2_Lars, ich hab einen DSL-Anschluss in Berlin und bei mir treten die Probleme weiterhin auf:

$ curl -v  --resolve 'understandingwar.org:443:2606:4700:10::6816:4f94' -6 https://understandingwar.org  > /dev/null
* Added understandingwar.org:443:2606:4700:10::6816:4f94 to DNS cache
* Hostname understandingwar.org was found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying [2606:4700:10::6816:4f94]:443...
* Connected to understandingwar.org (2606:4700:10::6816:4f94) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to understandingwar.org:443
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* closing connection #0
curl: (35) Recv failure: Connection reset by peer

$ curl -I --resolve 'understandingwar.org:443:2606:4700:10::6816:4f94' -6 https://understandingwar.org
HTTP/2 200
date: Fri, 06 Sep 2024 10:38:37 GMT
content-type: text/html; charset=utf-8
x-content-type-options: nosniff
x-powered-by: PHP/7.4.21
x-drupal-cache: HIT
cache-control: public, max-age=60
content-language: en
x-frame-options: SAMEORIGIN
x-generator: Drupal 7 (http://drupal.org)
last-modified: Fri, 06 Sep 2024 10:15:49 GMT
expires: Sun, 19 Nov 1978 05:00:00 GMT
vary: Cookie,Accept-Encoding
x-varnish: 509759854 510045107
age: 60
via: 1.1 varnish (Varnish/6.0)
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 8bedd49b28b79286-MUC

$ traceroute -6 'understandingwar.org'
traceroute to understandingwar.org (2606:4700:10::6816:4f94), 30 hops max, 80 byte packets
 1  dynamic-2a01-0c22-acd4-0000-2e91-abff-febe-6b2b.c22.pool.telefonica.de (2a01:c22:acd4:0:2e91:abff:febe:6b2b)  0.365 ms  0.571 ms  0.728 ms
 2  2a02:3001::125 (2a02:3001::125)  28.889 ms  29.475 ms  29.465 ms
 3  * * *
 4  * * *
 5  loopback0.0006.corx.01.muc.de.net.telefonica.de (::ffff:62.52.192.234)  21.683 ms lo0.02.rl2t.99.gut.de.net.telefonica.de (::ffff:62.52.193.55)  19.901 ms *
 6  2a02:3001::6b (2a02:3001::6b)  20.457 ms 2a02:3001::26b (2a02:3001::26b)  20.345 ms  20.316 ms
 7  * * *
 8  2001:7f8:8:20:0:3417:0:1 (2001:7f8:8:20:0:3417:0:1)  17.265 ms 2400:cb00:100:1024::ac44:6d3e (2400:cb00:100:1024::ac44:6d3e)  15.844 ms 2001:7f8:8:20:0:3417:0:1 (2001:7f8:8:20:0:3417:0:1)  17.570 ms

$ curl -Ss -I -6 https://kagi.com | grep HTTP
HTTP/2 302
$ curl -Ss -I -6 https://kagi.com | grep HTTP
curl: (35) Recv failure: Connection reset by peer
$ traceroute -6 kagi.com
traceroute to kagi.com (2600:1901:0:daa1::), 30 hops max, 80 byte packets
 1  dynamic-2a01-0c22-acd4-0000-2e91-abff-febe-6b2b.c22.pool.telefonica.de (2a01:c22:acd4:0:2e91:abff:febe:6b2b)  0.389 ms  0.515 ms  0.660 ms
 2  2a02:3001::125 (2a02:3001::125)  30.966 ms  31.337 ms  31.326 ms
 3  * 2a02:3001::1ca (2a02:3001::1ca)  9.493 ms  9.599 ms
 4  * * loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168)  18.169 ms
 5  * lo0.02.rl2t.99.gut.de.net.telefonica.de (::ffff:62.52.193.55)  20.743 ms loopback0.0003.corx.01.ham.de.net.telefonica.de (::ffff:62.52.192.179)  18.136 ms
 6  2a02:3001::22d (2a02:3001::22d)  20.094 ms 2a02:3001::1b8 (2a02:3001::1b8)  13.191 ms  11.330 ms
 7  * * *
 8  2001:4860:1:1::56a (2001:4860:1:1::56a)  18.017 ms 2001:4860:0:1::591b (2001:4860:0:1::591b)  17.139 ms 2001:4860:0:1::8123 (2001:4860:0:1::8123)  13.022 ms
 9  2001:4860:0:1::591d (2001:4860:0:1::591d)  18.640 ms 2001:4860:0:1::8123 (2001:4860:0:1::8123)  13.386 ms 2001:4860:0:1::531f (2001:4860:0:1::531f)  14.043 ms
10  2600:1901:0:daa1:: (2600:1901:0:daa1::)  13.577 ms 2001:4860:0:1::1c5d (2001:4860:0:1::1c5d)  14.790 ms 2600:1901:0:daa1:: (2600:1901:0:daa1::)  14.793 ms

$ curl -Ss -I -6 --resolve 'www.openstreetmap.org:443:2606:4700:3034::6815:5842' https://www.openstreetmap.org | grep HTTP
curl: (35) Recv failure: Connection reset by peer
$ curl -Ss -I -6 --resolve 'www.openstreetmap.org:443:2606:4700:3034::6815:5842' https://www.openstreetmap.org | grep HTTP
HTTP/2 200
$ traceroute -6 www.openstreetmap.org
traceroute to www.openstreetmap.org (2606:4700:3034::6815:5842), 30 hops max, 80 byte packets
 1  dynamic-2a01-0c22-acd4-0000-2e91-abff-febe-6b2b.c22.pool.telefonica.de (2a01:c22:acd4:0:2e91:abff:febe:6b2b)  0.367 ms  0.465 ms  0.592 ms
 2  2a02:3001::125 (2a02:3001::125)  46.619 ms  46.774 ms  46.788 ms
 3  2a02:3001::1ca (2a02:3001::1ca)  9.441 ms  9.326 ms *
 4  * loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168)  20.270 ms  19.732 ms
 5  * * *
 6  2a02:3001::6b (2a02:3001::6b)  18.794 ms  19.844 ms 2a02:3001::26a (2a02:3001::26a)  18.477 ms
 7  * * *
 8  2400:cb00:100:1024::ac44:6d0c (2400:cb00:100:1024::ac44:6d0c)  15.059 ms 2400:cb00:928:3:: (2400:cb00:928:3::)  17.211 ms 2001:7f8:8:20:0:3417:0:1 (2001:7f8:8:20:0:3417:0:1)  18.521 ms

Beste Grüße

Hm. Weniger schön…

Willkommen auf jeden Fall in unserer Community, @j m.

Ich geb das intern direkt mal weiter, damit da mal Blicke drauf geworfen werden. Danke dir auf jeden Fall für die mitgeschickten Infos!

Gruß,

Lars

Seid ihr hier in irgend einer Form weiter gekommen? Ich hab das Problem seit einiger Zeit “etwa genauso”. Kann es sowohl mit Arch Linux (als auch mit Windows 10/11, hier mittels git) auslösen.

Gleiches System, anderer Anschluss+Anbieter hat keine Probleme. Bei mir ist es allerdings auch nicht dauerhaft. Mindestens 50% der Anfragen gehen ohne Problem durch und die anderen 50% bekommen einen Connection reset.

Hallo in die Runde.  Auch bei mir besteht das Problem nach über einem Jahr nach wie vor. Ist übrigens auch bei mir ein Berliner O2-VDSL Anschluss (Bitstream über die Telekom, soweit ich weiß).

Ein Jahr lang ohne stabile IP-Konnektivität, irgendwie war das damals mit analogen Modems über Telefonleitung alles stabiler. Und offenbar sind wir Nutzer seitdem sehr genügsam geworden, dass wir uns mit solchen Zuständen arrangieren :)

Ich bin inzwischen darauf konditioniert, Ctrl+R zu drücken, wenn eine Webseiten nicht lädt. Und hab die Hoffnung aufgegeben, dass mit IPv6 jetzt alles besser wird.

@mhlavac : super, dass das inzwischen sogar server-seitig auffällt, dass eine vielzahl von clients aus dem O2 netz nicht mehr durchkommen.  Bin gespannt, ob vielleicht cloudflare selbst was rausfindet.

Bin übrigens gerade wieder über das Problem gestolpert hier.  Nichtmal xkcd kann man auf Anhieb laden:

$ https_proxy= curl -v -6 https://xkcd.com > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2a04:4e42::67:443...
* Connected to xkcd.com (2a04:4e42::67) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443

zugehöriger Traceroute:

$ traceroute -6 2a04:4e42::67
traceroute to 2a04:4e42::67 (2a04:4e42::67), 30 hops max, 80 byte packets
 1  2a02:3001::23f (2a02:3001::23f)  12.070 ms  12.236 ms  12.438 ms
 2  * * *
 3  loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168)  21.969 ms *  23.010 ms
 4  * * *
 5  2a02:3001::26b (2a02:3001::26b)  23.738 ms  22.832 ms 2a02:3001::280 (2a02:3001::280)  21.895 ms
 6  2a02:3001::1a2 (2a02:3001::1a2)  21.318 ms 2a02:3001::6d (2a02:3001::6d)  21.771 ms 2a02:3001::1a2 (2a02:3001::1a2)  21.597 ms
 7  * * *

[..]

30  * * *

xkcd.com ist nicht Cloudflare, sondern Fastly (AS54113).  Das Problme ist also größer, und nicht nur auf cloudflare beschränkt!  Wie geht es denn den anderen Berlinern hier im Thread beim Zugriff auf xkcd.com?

Laut server headern (wget -S)

X-Served-By: cache-fra-etou8220052-FRA

wird in diesem Fall die Anfrage in einem Datenzentrum in Frankfurt beantwortet.