Manche IPv6 Webseiten nicht erreichbar - Router im Verdacht

[norKoeri]

Oder Du machst auf der pfSense direkt einen Paket-Mitschnitt (für Wireshark) und schaust Dir den Unterschied an. Testseiten, die sich anbieten sind ipv4.icanhazip.com und ipv6.icanhazip.com.

 

[LieberNetterFlo]

@norKoeri da kommt gar nix an, wenn ich nach den IPs von handelsblatt.com filtere, 0 Pakete.

Ich habe aktuell mein Switch im verdacht: Zyxel XGS1930-28

 

[norKoeri]

Wenn Du meine Testseiten nimmst, hast Du es einfacher, auch weil das HTTP-Seiten sind. Siehst Du die DNS-Anfrage noch, siehst Du das TCP-SYN?

 

[LieberNetterFlo]

Es liegt nicht am Switch. Ich habe mal "dumme" Switches testweise genutzt und das Problem ist das gleiche.

Ergänzung (4. Januar 2026)

Wenn Du meine Testseiten nimmst, hast Du es einfacher, auch weil das HTTP-Seiten sind. Siehst Du die DNS-Anfrage noch, siehst Du das TCP-SYN?

ich hab keine Ahnung was ich da alles sehe ohne vernünftige Filter sind das viel zu viele Pakete die da die ganze Zeit laufen. Ich glaub ich muss mal Clients abknipsen um das zu verringern.

 

[norKoeri]

Du musst nur jene zwei Test-Webseiten aufrufen und währenddessen schauen, ob das klappt, also ein Filter auf dns || http. Ist das immer noch zuviel Verkehr, dann zusätzlich auf die Quell-Adresse filtern, also ip.addr == 192.168.178.20 && (dns || http).

 

[LieberNetterFlo]

@norKoeri bei mir scheint der Zugriff auf beide URLs über IPv6 zu laufen? als der DNS traffic geht komplett über IPv6 wie es scheint. Das ist die Kommunikation zwischen meinem PC und meiner pfSense und es ist auch nie http, sondern immer https

5    2.537986    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    98    Standard query 0x18aa HTTPS ipv4.icanhazip.com
6    2.538088    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    98    Standard query 0x49d1 AAAA ipv4.icanhazip.com
7    2.538213    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    160    Standard query response 0x49d1 AAAA ipv4.icanhazip.com SOA aragorn.ns.cloudflare.com
8    2.538249    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    98    Standard query 0x71fa A ipv4.icanhazip.com
9    2.573497    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    135    Standard query response 0x18aa HTTPS ipv4.icanhazip.com HTTPS
10    2.577109    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    130    Standard query response 0x71fa A ipv4.icanhazip.com A 104.16.185.241 A 104.16.184.241
11    2.580659    172.16.5.139    104.16.185.241    QUIC    1292    Initial, DCID=af2243e2976a5c1e, PKN: 1, CRYPTO, PING, CRYPTO, CRYPTO, PING, CRYPTO, CRYPTO, PADDING, CRYPTO, PADDING, CRYPTO, PADDING
12    2.580871    172.16.5.139    104.16.185.241    QUIC    1292    Initial, DCID=af2243e2976a5c1e, PKN: 2, CRYPTO, PING, CRYPTO, CRYPTO, PING, PING, PING, PING, PADDING, CRYPTO, CRYPTO, CRYPTO, PING, PADDING, CRYPTO, CRYPTO, PING, PING, CRYPTO, PADDING
17    2.592989    104.16.185.241    172.16.5.139    QUIC    1242    Initial, SCID=017ef576bc8cb4722e7e9176248cb4248428507f, PKN: 2, CRYPTO
18    2.593206    104.16.185.241    172.16.5.139    QUIC    1242    Protected Payload (KP0)




7    3.016563    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    98    Standard query 0x933e HTTPS ipv6.icanhazip.com
8    3.016685    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    98    Standard query 0xc8cb AAAA ipv6.icanhazip.com
9    3.016928    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    98    Standard query 0x4d21 A ipv6.icanhazip.com
10    3.017020    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    160    Standard query response 0x4d21 A ipv6.icanhazip.com SOA aragorn.ns.cloudflare.com
11    3.022803    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    96    Standard query 0xb070 A wpad.skynet.home
12    3.022888    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    171    Standard query response 0xb070 No such name A wpad.skynet.home SOA a.root-servers.net
13    3.050943    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    154    Standard query response 0xc8cb AAAA ipv6.icanhazip.com AAAA 2606:4700::6810:b9f1 AAAA 2606:4700::6810:b8f1
14    3.052767    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    159    Standard query response 0x933e HTTPS ipv6.icanhazip.com HTTPS
16    3.053996    2003:e5:b703:3800:871b:6148:fa5e:f384    2606:4700::6810:b9f1    QUIC    1292    Initial, DCID=47716e06ced4f304, PKN: 2, PADDING, PING, PADDING, PING, CRYPTO, CRYPTO, PING, PADDING, CRYPTO, PADDING
21    3.190789    2606:4700::6810:b9f1    2003:e5:b703:3800:871b:6148:fa5e:f384    QUIC    1262    Initial, SCID=0144fc6e43a441129c452b6f38a4469693eb6ba6, PKN: 2, CRYPTO
22    3.190796    2606:4700::6810:b9f1    2003:e5:b703:3800:871b:6148:fa5e:f384    QUIC    1262    Protected Payload (KP0)
50    6.661707    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    96    Standard query 0x7d20 A wpad.skynet.home
51    6.661879    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    171    Standard query response 0x7d20 No such name A wpad.skynet.home SOA a.root-servers.net

bei handelsblatt.com scheint irgendwas kaputt zu gehen? Ich weiß nicht, kanns nicht deuten

1    0.000000    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    100    Standard query 0x29ef HTTPS www.handelsblatt.com
2    0.000153    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    100    Standard query 0x1f39 AAAA www.handelsblatt.com
3    0.000362    2003:e5:b703:3800:871b:6148:fa5e:f384    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    DNS    100    Standard query 0x651a A www.handelsblatt.com
4    0.036324    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    315    Standard query response 0x29ef HTTPS www.handelsblatt.com CNAME pbhmg-cow-hb-cdn-endpoint-aaf4b5gxg0bkedh4.z01.azurefd.net CNAME mr-z01.tm-azurefd.net CNAME shed.dual-low.part-0017.t-0009.t-msedge.net SOA ns1.t-msedge.net
5    0.105534    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    304    Standard query response 0x651a A www.handelsblatt.com CNAME pbhmg-cow-hb-cdn-endpoint-aaf4b5gxg0bkedh4.z01.azurefd.net CNAME mr-z01.tm-azurefd.net CNAME shed.dual-low.part-0017.t-0009.t-msedge.net CNAME part-0017.t-0009.t-msedge.net A 13.107.246.45 A 13.107.213.45
6    0.113649    2003:e5:b703:3800:2287:56ff:fe6e:cdd8    2003:e5:b703:3800:871b:6148:fa5e:f384    DNS    328    Standard query response 0x1f39 AAAA www.handelsblatt.com CNAME pbhmg-cow-hb-cdn-endpoint-aaf4b5gxg0bkedh4.z01.azurefd.net CNAME mr-z01.tm-azurefd.net CNAME shed.dual-low.part-0017.t-0009.t-msedge.net CNAME part-0017.t-0009.t-msedge.net AAAA 2620:1ec:bdf::45 AAAA 2620:1ec:46::45
10    0.128878    2003:e5:b703:3800:871b:6148:fa5e:f384    2620:1ec:bdf::45    TCP    1474    52952 → 443 [ACK] Seq=1 Ack=1 Win=65280 Len=1400 [TCP PDU reassembled in 11]
11    0.128911    2003:e5:b703:3800:871b:6148:fa5e:f384    2620:1ec:bdf::45    TLSv1.3    436    Client Hello (SNI=www.handelsblatt.com)
13    0.141792    2620:1ec:bdf::45    2003:e5:b703:3800:871b:6148:fa5e:f384    TLSv1.3    173    Hello Retry Request, Change Cipher Spec
14    0.142523    2003:e5:b703:3800:871b:6148:fa5e:f384    2620:1ec:bdf::45    TLSv1.3    650    Change Cipher Spec, Client Hello (SNI=www.handelsblatt.com)
15    0.155244    2620:1ec:bdf::45    2003:e5:b703:3800:871b:6148:fa5e:f384    TLSv1.3    1290    [TCP Previous segment not captured] , Continuation Data
17    0.155671    2620:1ec:bdf::45    2003:e5:b703:3800:871b:6148:fa5e:f384    TLSv1.3    260    [TCP Previous segment not captured] , Continuation Data

Aber sieht auch so aus als würde er über IPv6 zugreifen wollen, und nicht über IPv4?

 

[norKoeri]

der DNS traffic geht komplett über IPv6 wie es scheint

Das ist normal. Das kannst Du im Router probeweise abschalten … müsste bei pfSense ähnlich sein, weiß ich dort jetzt nicht auswendig.

es ist auch nie http, sondern immer https

Dann hat Dein Web-Browser automatisch hoch-ge-grade-det. Welchen nutzt Du? Kann man dort auch ausschalten, braucht jetzt nach dem einmaligen Kontakt aber ein neues Benutzer-Profil.

bei handelsblatt.com scheint irgendwas kaputt zu gehen?

Jetzt habe ich den Überblick verloren: Klappen beide meiner Testseiten oder klappt die IPv4-Variante nicht?

 

[LieberNetterFlo]

alle Testseiten funktionieren, handelsblatt.com / netze-bw.de funktionieren nicht

 

[norKoeri]

Puh. Auch dann nicht, wenn Du IPv6 im Heimnetz komplett abschaltest, also z. B. am Computer? Aber wenn Du bereits den Switch als Ursache identifiziert hast, bleibt nicht mehr viel, also Firmware-Update auf die neuste Version, danach Zurücksetzen auf Werkseinstellungen und dann Abstoßen und was anderes kaufen. Brauchst Du eine Kaufberatung, also wirklich einen 1-Gbit-Switch-mit-10-Gbit-Uplink(s)?

 

[LieberNetterFlo]

Switches sind nicht Schuld, ich habe sie gegen "dumme" Switche ausgetauscht (so Standard Netgear 8 Port Zeugs) und das Problem bleibt bestehen. Das schlaue Zyxel habe ich bereits auf Werkseinstellung gesetzt.

Wenn ich IPv6 komplett deaktiviere zB in den Einstellungen von Windows, dann gehen alle IPv4 Seiten, auch handelsblatt.com und netze-bw.de

Aber ich bin schon weiter. Hab in pfSense noch zwei Dinge mal verändert: alle Patches deaktiviert und PPPoE das Modul gewechselt.

Jetzt scheint es erstmal zu gehen. Wenn das so bleibt könnte ich mal schauen welche Einstellung/welcher Patch das genau verursacht.

 

[norKoeri]

Switches sind nicht Schuld, ich habe sie gegen "dumme" Switche ausgetauscht (so Standard Netgear 8 Port Zeugs) und das Problem bleibt bestehen. Das schlaue Zyxel habe ich bereits auf Werkseinstellung gesetzt.

Naja, manch dumme Switche sind in Wirklichkeit blöde Switche, also Switche mit Diensten an Bord – smarte Switche – aber keinerlei Web-Oberfläche die zu aktualisieren – also nur nicht konfigurierbar.

Wenn ich mit dem selben Laptop oder einem zweiten Laptop direkt via LAN an den LAN port der pfSense hänge habe ich das Problem nicht.

Hab in pfSense noch zwei Dinge mal verändert: alle Patches deaktiviert und PPPoE das Modul gewechselt.

Mhm. Merkwürdig. Also direkt LAN ging. Aber Switch dazwischen ging nicht. IPv4-only geht. Und etwas in pfSense umschalten geht ebenfalls? Klingt für mich eher so, als hättest Du Probleme mit dem DNSv6. Was für eine Adress-Bereich ist der selbst, also die Adresse Deines lokalen DNSv6-Servers: GUA, ULA oder LLA?

Laut Deinem Mitschnitt oben ist es eine GUA. Das bitte nicht verwenden, wenn Du kein statisches sondern (wie in Deutschland leider üblich) dynamisches IPv6-Präfix hast. Dort eine ULA oder LLA oder DNSv6 gleich ganz in der pfSense abschalten.

Gegentest: Ziehe an der pfSense den WAN-Stecker, warte mal eine Stunde und dann wieder WAN ran. Während dessen den Computer die ganze Zeit laufen lassen. Kannst Du jetzt (noch) auf Deine problematischen Webseiten?

 

[LieberNetterFlo]

Ne, das Switch ist echt dumm was immer funktioniert hat, war: Direkte verbindung zu einem Laptop und Ein Laptop über ein dummes Switch an die pfSense.

Die Probleme haben angefangen wenn ich das "schlaue" Switch zu nutzen oder einen zweiten Client am dummen Switch. (oder halt das schlaue Switch, denn ich vermute das verhält sich wie ein Client, sei es LKaptop, PC, oder Handy, ein Gerät das Traffic verursacht)

Bzgl. DNS: Ich habe da groß nichts konfiguriert extra, die IPv6 meiner pfSense LAN Schnittstelle wird autoamtisch zum DNS von unbound (genau so wie die IPv4 der LAN Schnittstelle). Der stand schon immer auf "All" (also alle Interfaces)

So ne Stunden-Test kann ich erst wieder nach den Feiertagen machen, sonst meckert die Familie

Aber nochmal kurz: mit den oben genannten Einstellungen geht es ja jetzt, ich vermute dass die ganze Netzwerkinfrastruktur gar nichts damit zu tun hat, sondern auf der pfSense einfach mit einem dieser Patches was durcheinander kommt.

 

[norKoeri]

Bzgl. DNS: Ich habe da groß nichts konfiguriert extra, die IPv6 meiner pfSense LAN Schnittstelle wird autoamtisch zum DNS von unbound (genau so wie die IPv4 der LAN Schnittstelle). Der stand schon immer auf "All" (also alle Interfaces)

Manche Router-Software nutzt als Standard-Einstellung eine GUA. Das funktioniert aber bei dynamischen IPv6-Präfixen nicht, die es eben nur in einige Ländern gibt. oder anders formuliert: Wenn der Derjenige zuständig für die Standard-Einstellung im falschen Land wohnt, weiß der gar nichts von dem Problem.