Quad9 TCP-Ports 443 und 853 nicht erreichbar

oli-h · 2025-01-15T23:27:32+00:00

Sunrise community - customers help other customers with topics related to television, Internet, telephone and mobile. Register now!

oli-h

Daniele_Sunrise Fehler erkannt und ist per gestern Abend nicht mehr vorhanden

Gibt es da einen Zusammenhang mit dem grossflächigen Problem im Sunrise-Netz: https://community.sunrise.ch/d/42133-seit-heute-22-uhr-funktioniert-internet-kaum-noch ?

Daniele_Sunrise

oli-h Ich denke nicht, da ihr das Feherbild bereits länger gemeldet habt. Da ich keinen Einfluss in die Behebung der DNS habe, melde ich jeweils euer Feedback weiter. Wie und wann wir die Ursache lösen werden, kann ich dir nicht mitteilen. Auf jeden Fall poste ich jeweils die erhaltenen Updates an euch.

Falls jemand der DNS Server wichtig ist, benutzt bitte bis zur Behebung einen anderen.

Liebe Grüsse
Daniele

Daniele_Sunrise

oli-h Ich habe diese Rückmeldung erhalten. Wieso es bei uns geht und bei dir nicht, kann ich dir nicht mitteilen:

I repeated the tests, and they were widely OK. DoT and DoH were working last week Thursday (with Oppo and Apple iPad) on HFC. Just on a Huawei P40 Pro DoT was failing. So there might even be mobile device specific issues around this.

Liebe Grüsse
Daniele

oli-h

Daniele_Sunrise Ich denke nicht, da ihr das Feherbild bereits länger gemeldet habt

Ich meine das umgekehrt:
Weil Sunrise an diesem Abend des 22. Januar versucht hat, das Problem mit Quad9 zu lösen, deswegen gab es einen grossflächigen Ausfall.

Wie gesagt: Hier geht es nicht. Ich habe es inzwischen noch an einem zweiten Ex-UPC-Anschluss getestet –> ebenfalls kein TCP mit 9.9.9.9 möglich.
Zudem sind da ja noch die Aussage von Quad9 selbst, dass sie das Routing-Problem mit euch bereits kennen.

oli-h Stellungnahme von Quad9

Und dann noch die Nachricht hier im Thread

Daniele_Sunrise wurde unsererseits der Fehler erkannt und ist per gestern Abend nicht mehr vorhanden. Heute / morgen erfolgen weitere Tests

Also leider keine Lösung seitens Sunrise.
In 6 Monaten baut die Swisscom hier dann FTTH. In 10 Monaten kann ich dann Fiber7 buchen. Die haben das Routing dann hoffentlich (und vermutlich) im Griff

oli-h

Ich hab’ eine neue Erkenntnis: Mit Reduzierung der MTU (https://en.wikipedia.org/wiki/Maximum_transmission_unit) vom (default) 1500 auf 1476 funktioniert “curl https://9.9.9.9” zuverlässig.

Was aber genau im Netzwerk bzw. bei den Switches/Routern passiert (also im Sunrise-Netz, am SwissIX-Exchange und/oder bei Quad9), das weiss ich natürlich nicht. Aber die “maximale Paketgrösse” spielt irgendwo eine entscheidende Rolle

Wenn ich jetzt hier im Forum nach “MTU” suche, dann finden sich diesbezüglich doch einige Threads. So 100% schlau werd’ ich aber nicht draus.

Nachtrag:

ping 9.9.9.9 -c 10 -M do -s 1472

Das sendet ICMP-Echo-Request mit der maximaler MTU (also 1500 Bytes). Hier bekomme ich kein “pong” (= ICMP-Echo-Reply).
Stufenweise Reduzierung um den Punkt zu finden, bei dem es dann klappt:

ping 9.9.9.9 -c 10 -M do -s 1470
ping 9.9.9.9 -c 10 -M do -s 1468
ping 9.9.9.9 -c 10 -M do -s 1466
... usw ...
ping 9.9.9.9 -c 10 -M do -s 1450
ping 9.9.9.9 -c 10 -M do -s 1448   <--  DER KLAPPT DANN !

Die maximale Paketgrösse von meiner IP zu 9.9.9.9 ist also 24 Bytes kleiner als sonst im Internet üblich.
Wenn ich das ganze via Swisscom-Mobile (Hotspot via Handy) mache, dann funktioniert MTU=1500.
Wenn ich andere IPs anpinge (z.B. 1.1.1.1), dann geht auch via Sunrise-Netz eine MTU=1500.

Also ich bleibe dabei: Das Routing vom Sunrise-Netz zu 9.9.9.9 ist irgendwo ‘kaputt’

Daniele_Sunrise

oli-h Vielen Dank für deine Feststellungen, welche ich soeben intern weitergeleitet habe.

Liebe Grüsse
Daniele

Daniele_Sunrise

oli-h Darf ich noch kurz fragen, wie dein Setup aussieht. also wie hast du alles Verbunden und danach den Test gemacht. Ich nehme an das Modem ist im Bridge Modus und angeschlossen ist dann ein Linux Rechner?

Liebe Grüsse
Daniele

oli-h

Daniele_Sunrise wie dein Setup aussieht

ConnectBox 2 HFC im Bridge-Mode
von da mit einem kurzen Ethernetkabel an einen Cisco-Switch (‘nur’ 1-Gigabit-Ethernet).
Der Port ist einen ‘VLAN xyz’ zugeordnet.
Vom Cisco-Switch geht es dann via Ethernetkabel zu einer OpnSense-Appliance - hier dann mit
‘Tagged VLAN xyz’
Die OpnSense-Box ist up-to-date, also OpnSense Version, also 24.7-Punkt-Irgendwas.
Maximal ein paar Tage ‘alt’
Die OpnSense-Box ist Firewall/Router ins “LAN 1”. LAN 1 geht dann ‘untagged’ über dasselbe Ethernetkabel zurück zum Cisco-Switch. Für Cisco ist notabene - per default - ‘untagged’ = ‘VLAN 1’
Der Linux-Rechner hängt (wieder untagged) an einem weiteren Port des Cisco-Switches

Die LAN-IP-Adresse des Linux-PC ist fix (also kein DHCP ab OpnSense o.ä.). Eine normale 1-GB-Ethernet-Buche auf einem typischen (älteren) ASUS-Mainboard. MTU ist ‘default’ - also 1500.

Ergänzend:

Ich hab natürlich das “curl https://9.9.9.9” auch einer Shell der OpnSense-Box ausgeführt –> selbes Problem

N.B: OpnSense basiert auf BSD, ist also kein Linux.
Durch den Test direkt auf OpnSense umgehe ich auch jegliches NAT-Routing. Die IP-Pakete gehen von direkt (zwar VLAN-getaggt - aber das ist transparent) über ein Ethernet-Interface der OpnSense-Appliance via Cisco-Switch zur ConnectBox.

oli-h

Und nochmal ein Nachtrag:

OpnSense (und vermutlich auch andere Firewalls/Router) bietet eine Funktion namens “MSS clamping”.
Dabei greift der Router bei einem (outgoing) TCP-Connect in den TCP-Header ein und manipuliert das MSS-Feld (https://en.wikipedia.org/wiki/Maximum_segment_size).

Im UI von OpnSense hab ich nun “1476” konfiguriert:

1476 Bytes - das sind genau die schon erwähnten “24 Bytes” weniger als die sonst übliche MTU 1500
Damit funktioniert nun “curl https://9.9.9.9” - vermutlich von allen Clients in meinem LAN.
Nachteil für mich nun: Es ist sämtlicher TCP-Traffic betroffen.
Die kleine MSS führt logischerweise zu mehr Datenpaketen (um z.B. 100 MB zu übertragen), damit zu mehr Overhead (wg. IP- und TCP-Header) und damit zu etwas weniger Bandbreite.
Ich vermute, dass die ConnectBox(en) im Router-Modus auch sowas machen - oder gleich per DHCP an die Clients im LAN eine kleine MTU (also maximal eben diese 1476) zuweisen.
Da ich meine ConnectBox nicht im Router-Mode betreibe kann ich das gerade nicht auf die Schnelle prüfen.
Jemand anders hier im Forum vielleicht?

Nach wie vor wäre ich also froh, wenn Sunrise das Peering mit Quad9 (bzw: mit allen) sauber hinkriegen würde.

GrandDixence

Das beschriebene Path-MTU-Problem ist an meinem Internetanschluss über das Fernsehkabelnetzwerk (EuroDOCSIS) von UPC/Sunrise, mit Bridge-Modus, nicht reproduzierbar:

$ ping -c 10 -M do -s 1472 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 1472(1500) Bytes Daten.
1480 Bytes von 9.9.9.9: icmp_seq=1 ttl=56 Zeit=18.1 ms
1480 Bytes von 9.9.9.9: icmp_seq=2 ttl=56 Zeit=20.8 ms
1480 Bytes von 9.9.9.9: icmp_seq=3 ttl=56 Zeit=18.1 ms
1480 Bytes von 9.9.9.9: icmp_seq=4 ttl=56 Zeit=19.6 ms
1480 Bytes von 9.9.9.9: icmp_seq=5 ttl=56 Zeit=17.0 ms
1480 Bytes von 9.9.9.9: icmp_seq=6 ttl=56 Zeit=16.5 ms
1480 Bytes von 9.9.9.9: icmp_seq=7 ttl=56 Zeit=25.0 ms
1480 Bytes von 9.9.9.9: icmp_seq=8 ttl=56 Zeit=16.0 ms
1480 Bytes von 9.9.9.9: icmp_seq=9 ttl=56 Zeit=20.3 ms
1480 Bytes von 9.9.9.9: icmp_seq=10 ttl=56 Zeit=18.3 ms

--- 9.9.9.9 ping-Statistik ---
10 Pakete übertragen, 10 empfangen, 0% Paketverlust, Zeit 9012ms
rtt min/avg/max/mdev = 15.971/18.952/25.034/2.511 ms

Offenbar sind die Path-MTU-Probleme hausgemacht, sprich im eigenen Heimnetzwerk zu suchen und die Fehlkonfiguration zu beheben.

Und an meinem Internetanschluss funktioniert die mit TLS-verschlüsselte Kommunikation auf die IP-Adresse 9.9.9.9 per Serverport TCP 443 (HTTPS):

$ openssl s_client -connect 9.9.9.9:443
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
verify return:1
depth=0 C = CH, ST = Zurich, L = Zurich, O = Quad9, CN = dns.quad9.net
verify return:1
---
Certificate chain
 0 s:C = CH, ST = Zurich, L = Zurich, O = Quad9, CN = dns.quad9.net
   i:C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Jul 17 00:00:00 2024 GMT; NotAfter: Jul 16 23:59:59 2025 GMT
 1 s:C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Apr 14 00:00:00 2021 GMT; NotAfter: Apr 13 23:59:59 2031 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
subject=C = CH, ST = Zurich, L = Zurich, O = Quad9, CN = dns.quad9.net
issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G3 TLS ECC SHA384 2020 CA1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3272 bytes and written 375 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: D0345610745AD00F62E45EA2BAA095C1E9F702CEF5874328CB1F63B575262ECF
    Session-ID-ctx: 
    Resumption PSK: 69A80B8C500BF15B5949D21807322335076F6C0B14A12BB93D8AF42A4DE55D9D240C5A945E4CFCA336EE6A1DFA3DF228
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 79 94 6a b2 0d 2c a5 67-f9 af 08 21 07 96 07 85   y.j..,.g...!....
    0010 - 30 dc fb 45 15 5b aa d9-5c 51 0f 41 a6 bc d0 77   0..E.[..\Q.A...w
    0020 - ed 55 fe dd 2c 85 de 6d-bd a2 8d a7 cf 74 28 f6   .U..,..m.....t(.
    0030 - 5e 11 75 04 77 3c b1 b0-c0 ce cc a3 46 59 12 44   ^.u.w<......FY.D
    0040 - 94 32 3b ea 63 d9 f7 ae-1e 0f 66 25 69 90 46 e7   .2;.c.....f%i.F.
    0050 - dd 56 6c 80 8a bb 16 41-62 7b 27 c4 30 2e 9a a9   .Vl....Ab{'.0...
    0060 - bc e9 ac b4 30 4e 7f 21-b9 02 5b 45 4d c7 f5 89   ....0N.!..[EM...
    0070 - fa d8 32 6e f2 65 4c ca-61 a9 08 26 f9 b6 8c a2   ..2n.eL.a..&....
    0080 - b0 31 9f 86 55 6d ee a1-8d 8d b5 27 71 a5 46 da   .1..Um.....'q.F.
    0090 - 0c eb ad d8 42 40 a4 2a-d1 c7 9b 96 6b 03 2f 10   ....B@.*....k./.
    00a0 - c5 41 d1 0c 0f d0 af 12-f1 0f 08 a0 a1 31 a3 fc   .A...........1..
    00b0 - 04 31 1a 06 fd f7 16 12-44 8d a2 99 3b 9e 1d a2   .1......D...;...

    Start Time: 1738267010
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: F7D2E5AAEA77AB961453B040FE7A700BE35D84CC01980C8F79B31415EEB691FB
    Session-ID-ctx: 
    Resumption PSK: 12DA273F752563C8F352118509BD93DFAEF8C157AA56DFD46539637FD8EB5141374E7AE6DADC982D415F51E5ACC2EEF2
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 79 94 6a b2 0d 2c a5 67-f9 af 08 21 07 96 07 85   y.j..,.g...!....
    0010 - 1d ca c4 50 bd 74 8a 89-b7 f0 04 b6 b4 65 bd 5f   ...P.t.......e._
    0020 - 76 17 f3 31 9a a6 b9 76-9f ab 63 37 f6 59 c2 36   v..1...v..c7.Y.6
    0030 - 15 e2 21 83 60 63 e5 2c-33 5f b3 83 39 62 bb e6   ..!.`c.,3_..9b..
    0040 - 1a 08 a3 c0 7f 94 04 34-83 57 8c 46 52 47 9e 6a   .......4.W.FRG.j
    0050 - d5 4f d3 b0 6d 46 9b ea-34 de 51 cd d2 c0 5c 5b   .O..mF..4.Q...\[
    0060 - 4e 55 f0 1c 4a 66 f0 9b-1d 28 8f da 51 92 4e c3   NU..Jf...(..Q.N.
    0070 - 37 ff e0 b8 aa 1b bc 02-4b e9 29 d6 f8 ca f2 c2   7.......K.).....
    0080 - 5a b4 2b 55 20 60 d7 fb-d9 e1 40 d7 a2 6a 20 80   Z.+U `....@..j .
    0090 - 78 7f 6a 46 8e c6 3a a2-e1 36 21 c0 45 ab e5 31   x.jF..:..6!.E..1
    00a0 - a8 24 86 ce a7 dd 63 f8-1a a7 2c 9d 48 cb 27 dd   .$....c...,.H.'.
    00b0 - 80 72 be 10 86 5a 02 20-8f d1 73 d4 fd 9f 9e 4a   .r...Z. ..s....J

    Start Time: 1738267010
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

oli-h

GrandDixence

Merci für den Kontrolltest.

Ich hab’ soeben auch nochmal getestet und muss sagen: Jetzt funktioniert es auch bei mir wieder
Aus meiner Sicht wurde tief im Sunrise-Netz etwas verändert. Ich wäre noch über eine ehrliche Kommunikation seitens Sunrise dankbar.

╰─$ ping -c 10 -M do -s 1472 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 1472(1500) bytes of data.
1480 bytes from 9.9.9.9: icmp_seq=1 ttl=56 time=22.9 ms
1480 bytes from 9.9.9.9: icmp_seq=2 ttl=56 time=16.2 ms
1480 bytes from 9.9.9.9: icmp_seq=3 ttl=56 time=15.4 ms
1480 bytes from 9.9.9.9: icmp_seq=4 ttl=56 time=15.6 ms
1480 bytes from 9.9.9.9: icmp_seq=5 ttl=56 time=16.2 ms
1480 bytes from 9.9.9.9: icmp_seq=6 ttl=56 time=15.5 ms
1480 bytes from 9.9.9.9: icmp_seq=7 ttl=56 time=13.7 ms
1480 bytes from 9.9.9.9: icmp_seq=8 ttl=56 time=16.0 ms
1480 bytes from 9.9.9.9: icmp_seq=9 ttl=56 time=15.2 ms
1480 bytes from 9.9.9.9: icmp_seq=10 ttl=56 time=15.4 ms

--- 9.9.9.9 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 13.656/16.206/22.945/2.348 ms

(mein Round-Trip ist sogar etwas besser als im Beispiel von @GrandDixence 😜)

N.B. gibt es bei “ping -c 10 -M do -s 1472 9.9.9.9” kein Path-MTU-Discovery. Faktisch ist ja genau dieser Ping der Versuch, die maximale MTU manuell zu ermitteln.
Da inzwischen weltweit viele (oder sogar die meisten) Router die für ein sauberes Path-MTU-Discovery nötigen ICMP-Pakete schlich nicht mehr (zurück)senden ist m.E. Path-MTU-Discovery ohnehin erfolglos. Es ist eigentlich auch nicht mehr nötig, da faktisch das gesamte Internet (inbesondere auch die Internet-Exchange-Nodes) mit Ethernet gebaut ist. Damit ist MTU=1500 auf dem ganzen Pfad möglich.

Also nochmal Bitte an Sunrise: Könnt ihr die Änderung “gestern auf heute” hier noch publizieren? Merci schonmal.

« Previous Page