IPv6 und HTTPS... Kann manche Seiten aufrufen, andere hingegen nicht?!


  • Hallo Forum,

    ich bin wiedermal am verzweifeln. Ich habe nun einen zweiten Anlauf genommen meine pfsense auf IPv6 umzustellen. Soweit so gut. Nun kommt es zu dem Problem, dass ich alle Hosts im Internet anpingen kann, sprich IPv4 und IPv6 Hosts:

    ping.png

    Aufrufen dieser drei Internseiten funktioniert aber nur bei www.welt.de und bei www.hna.de.

    www.heise.de funktioniert nicht. Hier bekomme ich einen Timeout. Ebenso ist das bei forum.netgate.com der Fall.

    Das bringt mich noch um den Verstand ;)

    Hier mal meine Konfigurationen...

    ipconfig /all
    ipconfig_all.png

    WAN-Settings
    wan_settings.png

    DHCP
    dhcp_settings2.png
    dhcp_settings.png

    WAN-Status
    wan_status.png

    Übersicht
    uebersicht.jpg

    Könnt ihr da vielleicht irgendwas erkennen was fehlerhaft ist? Mich macht der IPv6-Gateway auf meinem Laptop stutzig... Ist der normal so? Weil der Gateway unter WAN-Status ja ein ganz anderer ist?!

    Ich hoffe ihr könnt mir helfen.

    Vielen Dank!


  • Wieso hast du keinen IPv6 DNS Server, sondern nur einen IPv4 (192.168.20.1)?


  • Gute Frage.

    Wie bekomme ich den? Hätte jetzt erwartet, dass der automatisch gesetzt wird. Dann wundert mich wiederum wieso die IPv6-Hostadressen (www.welt.de und www.heise.de) korrekt aufgelöst werden?


  • Du hast DHCPv6 aktiviert, aber unter Router Werbung "Nicht verwaltet..." eingestellt. Das muss dann "Verwaltet..." sein. Ohne DHCPv6 wäre es "Nicht verwaltet...".

  • LAYER 8 Moderator

    Werde mir das gleich nochmal im Detail durchlesen aber:

    Ich muss zwischendurch mal kurz den Kopf gegen die Wand schlagen!

    "Router Werbung" - ist wieder einmal das beste Beispiel, warum man die UI einfach nicht auf Deutsch umstellen sollte und eine deutsche Übersetzung durch die Community zwar nett ist, aber ohne technical lead / Übersicht der die Übersetzung bewertet einfach nur murks ist. Das ist mit der Grund, warum ich den Leuten empfehle die Begriffe auf englisch zu lernen und zu verstehen, damit sie sinnvolle Hilfe bekommen. Kann mir schon vorstellen wie ein Supporter schaut, wenn man am Telefon sagt "ich hab die Router Werbung auf Verwaltung gestellt!" - Dafuq?!

    Geht gleich wieder...

    Witzig ist, dass deine Pings zum Teil gehen. Was sagt denn ein nslookup der Adressen? Und wie wird die Adresse aufgerufen? Und welcher Browser und macht der Browser vielleicht verkorkstes DoH (firefox)? Dein Ping auf HNA war IPv4, trotzdem sagst du die Seite geht nicht. Da frage ich mich, ob das nur ein IP6 Problem ist oder was anderes schief liegt?


  • Habe es etwas komisch geschrieben, aber die einzige Seite die oben in den Beispielen nicht funktioniert ist www.heise.de.

    www.hna.de und www.welt.de funktionieren!

    Ich rufe die Seiten mit Google Chrome auf.

    So, hab jetzt die "Router Werbung" :D auf managed gestellt:

    ipconfig_all_neu.png

    Wie man sieht steht da jetzt auch ein IPv6 DNS-Server.

    wan_status_neu.png

    Hier aber nicht?

    Ergebnis ist leider immer noch so, dass ich auf diese bestimmten Seiten nicht komme, obwohl anpingbar.

    Das hin und her von IPv4<-->IPv6 ist immer ein ziemlicher Krampf. Um hier Posten zu können muss ich dann jedesmal die Schnittstellen wieder von IPv6 "säubern" bevor ich wieder richtig online komme. Hierbei ist mir aufgefallen, dass es am Ende nur per Neustart funktioniert. Sonst bekomme ich keine IPv4 Adresse mehr. Ist wahrscheinlich korrekt so?

  • LAYER 8 Moderator

    @enJOyIT said in IPv6 ... Kann manche Seiten anpingen und aufrufen, andere hingegen nicht?!:

    Hier aber nicht?

    Naja das sind nur die, die du unter System/General eingestellt hast. Wenn du da nur die beiden IP4 DNSe von Google hinterlegt hast, dann können magisch auf dem WAN auch keine anderen aufploppen ^^
    Du kannst da problemlos auch die beiden v6 Google DNSe eintragen und dann mal sehen, ob du sie aus dem WebUI der pfSense anpingen kannst.

    Frage ist aber: nutzt du überhaupt DNS Forwarding oder den DNS Resolver im normalen resolving Mode? Dann ist es völlig egal, was da auf dem WAN eingetragen ist, das hat dann nur Auswirkung auf die pfSense selbst. Ist der DNS6 den du am Client bekommst die LAN IF v6 der pfSense? Nochmals: was wird per NSLOOKUP dem Client zurückgeliefert bei heise.de, hna.de o.ä.? Kommen da v6 Antworten? Dann ist es relativ egal ob irgendwo DNS6 eingetragen sind oder nicht, jeder DNS kann als Antwort A und AAAA Records zurückgeben. Die Frage ist nur, ob die bei deinem System ankommen und genutzt werden und ob es dann irgendwo ein Problem gibt.

    • Wie sieht die LAN Regel aus, die v6 erlaubt?
    • Mal versucht, die IP6 direkt zu öffnen im Browser (also DNS Problem ausschließen)
    • IP6Test aufgerufen?

    Hierbei ist mir aufgefallen, dass es am Ende nur per Neustart funktioniert. Sonst bekomme ich keine IPv4 Adresse mehr. Ist wahrscheinlich korrekt so?

    Nein, sollte nicht so sein. DHCP4/6 sollten immer gehen, auch ohne Neustart. ipconfig /release bzw. /renew sollten das Regeln. Ansonsten einfach die das IP6 im Interface Adapter abklemmen, dann geht eh nur IP4.
    fb9770a5-9051-4718-a75b-bd425006c57f-image.png


  • Bei dem Neustart meinte ich die pfsense.

    Probiere das gleich mit dem Adapter-Abklemmen :-)


  • Da bin ich wieder...

    Habe nslookup ausgeführt
    nslookup.png

    https://test-ipv6.com/ ausgeführt
    ipv6 test.png

    https://ipv6-test.com/ konnte ich gar nicht erst aufrufen

    Und das abklemmen des IPv6 Adapters klappt gut. Muss nur schauen, dass ich keine anderen Clients habe die, solange das nicht richtig läuft, Probleme bekommen.


  • Habe jetzt noch tracerts auf die Seiten gemacht.

    www.heise.de bekommt zwischendrin eine Zeitüberschreitung.
    tracert.png

    www.netgate.com - Da muss ich mich revidieren! Die Seite funktioniert! Aber nicht das Forum! Hier bekomme ich ebenfalls eine Zeitüberschreitung zwischendrin:
    tracert_forum.png

    https://ipv6-test.com/ mit am Client abgeschalteter IPv6 Schnittstelle
    ipv4_test_ipv6_abgeschaltet.png

  • LAYER 8 Moderator

    OK top to bottom was wir sehen/lernen.

    1. nslookups: du bist mit der sense via DNS6 verbunden. So weit so gut.
    2. Sie antwortet bei HNA nur mit v4 Adressen, bei Welt ists ein CDN. Heise hat normale v4/v6 Server.
    3. Test-IPv6 sagt, dass keine IP6 erkannt wird (ausgehend) - das heißt prinzipiell mal nix gutes.

    Dann der nächste Post:

    1. Zeitüberschreitung zwischendrin: ist gerne normal, die Systeme mögen dann kein ICMP o.ä. und melden sich nicht. Muss nichts schlimmes sein, solange der Endpunkt erreichbar ist.

    2. ip6test: Klar ohne v6 wird auch ohne v6 angezeigt ^^ - wichtiger wäre aber was MIT v6 angezeigt wird.

    Insgesamt denke ich da ist was mit dem Regelset im Argen und bei dir geht kein v6 raus - ODER - was auch sein könnte - aus irgendeinem Grund wird das IP6 Netz nicht von extern zu dir reindelegiert/geroutet. Daher die Frage, was in den Logs passiert.

    Also:

    • Wie sehen Firewallregeln auf LAN/WAN aus
    • Wird ausgehend v6 überhaupt korrekt erlaubt
    • Was ist eingehend erlaubt
    • Wie sehen die Interfaces der Sense aus auf v6 Seite (Status/Interfaces)?
    • Wie sieht es in den Firewall Logs aus: Ist dort überhaupt bspw. eingehend geblockter v6 Traffic zu sehen? Oder ausgehender?
    • Wenn du eine v6 Adresse am Client hast und versuchst eine Seite aufzurufen, die nicht geht: taucht deine IP6 in den State Tables auf? (Diagnostic / States?) Oder schwenkt der Browser einfach manchmal auf IP4 um wenn v6 nicht geht und bei anderen klappt es evtl nicht? Vielleicht geht bei dir am Client abgehend gar kein v6 über die Firewall und du merkst es nur nicht bei allen Adressen?

    Wenn du die IP6 der pfSense Interfaces WAN/LAN posten kannst (ansonsten gern auch als direkte Nachricht/Chat) kann ich gern mal von extern einen Ping6 versuchen. Du müsstest dann nur mal zum Testen IPv6-ICMP (echo request) von extern auf dem WAN erlauben. Aber dann sieht man, ob wenigstens der Request bis zum Routing durchgeht.


  • Hier die Informationen die ich momentan geben kann:

    fw_regeln_WAN.png
    fw_regeln_LAN.png
    status_interfaces.png

  • LAYER 8 Moderator

    OK also default auf LAN und ICMP6 offen auf WAN. Das ist zumindest ein Anfang :)

  • LAYER 8 Moderator

    OK für andere als Zwischenstand: haben uns das interessenhalber mal direkt auf dem System angesehen. SEHR seltsames Verhalten bei einem gebauten Testcase:

    Seiten gebaut via v4 und v6 erreichbar (NUR darüber, damit kein Fallback). Dann entsprechende Domains aufgerufen:

    • testv4-http -> geht
    • testv6-http -> geht
    • testv4-https -> geht
    • testv6-https -> surprise, geht NICHT.

    und das lustigerweise bei mehreren Versuchen und Domains. Bei großen CDNs scheint es gut zu gehen, die liefern aber gerne auch mehrere IP4/IP6 aus, so dass ich vermute, der Browser fällt dann auf IP4 zurück und macht round-robin. Wo aber nur eine v4/v6 Kombo da ist bzw. nur v6 geht HTTPS schief.
    Mit tcpdumps auf Sense und Servern ist auch klar zu sehen: der Zugriff per v6 klappt und Daten werden vom Host abgerufen - kommen aber aus irgendeinem Grund nie beim Browser so an, dass er sie verarbeitet. Proxy Settings waren aus, Adblock o.ä. ebenfalls auf der Sense lief am Ende auch nichts mehr wie Proxy o.ä.
    Sense selbst konnte sowohl von ihrer WAN als auch LAN Adresse (!) aber bspw. die Seiten aufrufen (und ausliefern/auslesen), die der Client dahinter nicht konnte. Obwohl die Daten am Client scheinbar ankamen.

    Ich hatte nun weder im Browser noch auf der Sense selbst irgendwas abgefahrenes dazu gesehen, deshalb -> ich würde da im LAN o.ä. nochmal suchen, ob da jemand doch noch Traffic filtert oder sonstwo noch in die Suppe spuckt.

    klingt aber schon sehr speziell :)


  • Kurze Zusatzinfo. Ich hatte danach meinen Laptop direkt und ohne Umwege an die pfSense gehangen, mit dem selben Ergebnis.

    Danach noch ein paar VMs probiert. Windows, Linux (Knoppix) mit exakt dem selben Verhalten.

    Habe nun auf der Knoppix-Maschine per Wireshark aufgezeichnet und JeGr zur Verfügung gestellt. Vielleicht kann er da was erkennen.

    Auch habe ich die pfSense in einer VM getestet. Genau das gleiche Problem!

    Was mir noch aufgefallen ist... wenn ich die Einstellungen an der WAN-Schnittstelle ändere, dann habe ich oft Probleme wieder online zu kommen. Er verliert die Verbindung und Disconnect/Connect bringt aber immer nur folgendes Bild
    loss.png
    loss2.png


  • Das Fehlerbild ist schon sehr ausgefallen. 😀 Ich habe das zwar nicht so in einer verschärfen Form, aber bei mir passiert das z.B. wenn ich Netflix nur über IPv6 per HTTPS aufrufe. Dann passiert einfach nichts, an einer IPv6 Ländersperre hängt das auch nicht. Das passiert auch sehr vereinzelt bei anderen Seiten. Die Seite oder die Apps werden einfach nicht über IPv6 / HTTPS und der pfSense geladen. Ohne pfSense ist es kein Problem. Es verhält sich so ähnlich wie wenn unter IPv4 der MTU Wert völlig daneben liegt. Dann Antworten die Seiten auch, können aber nicht geladen werden. Vielleicht findet der Jens was in deinen Wireshark Aufzeichnungen.

  • LAYER 8 Moderator

    Komme da momentan durch Arbeit nicht zu. Da aber vereinzelte Seiten gehen (vielleicht durch Fallback auf v4) UND die pfSense zumindest via Curl problemlos die Seiten abrufen kann, die der Client dahinter nicht kann - und das noch dazu wiederum nur bei https - ist schon sehr speziell und kann ich so nicht auf der Sense zuordnen.


  • @nonick Habe exakt das gleiche Fehlerbild mit Netflix über HTTPS (IPV6)...


  • @nowa-it Bei mir funktioniert Netflix mit der Sense und IPv6 leider auch nicht. In dem Netz wo sich die Streaming Geräte befinden, musste ich IPv6 deswegen abschalten. Scheinbar tritt das nur vereinzelt auf, deswegen kümmert sich keiner um diesen Fehler. Es hat irgendwas mit der pfSense Software zu tun, da es mit anderen Routern problemlos funktioniert.

    Kann dir da leider auch nicht weiterhelfen.


  • @nonick Hallo, ich wollte nochmal kurz Feedback geben. Ich hatte das Problem jetzt seit ca. 6 Tagen und habe lange gesucht. Mich wurde das Gefühl von einem MTU Problem nicht los... Ergo habe ich konkret nach gegoogelt. (Halbes Internet Quergelesen)
    Ich habe aktuell (stand jetzt) keine Probleme mehr (aktiv und getestet ca. 2. Stunden). Bei mir waren es die MTU / MSS Einstellung. Ich werde das ganze noch langfristig beobachten und nochmal Feedback geben falls gewünscht.
    Mein ISP (Telekom) hat einen MTU Wert von 1492.
    Geprüft mit ping www.google.com -f -l 1464 (wurde nicht fragmentiert)

    • die 28 (IP/ICMP) = 1492
      Die MSS Einstellung (IPV6 - 40 ) also 1452
      Ich bin über folgenden Reddit Thread drauf gestoßen:
      https://www.reddit.com/r/ipv6/comments/evv7r8/ipv6_and_netflix/
      Du kannst es ja mal mal prüfen, evtl. hilft es ja. Den MTU wert kann bei dir anders sein, je nachdem welchen ISP du hast. Ebenfalls kann es sein dass dein MSS Wert noch niedriger ist.
      Ich hoffe es hilft euch. Falls nicht, war es ein versuch wert.
      LG

  • @nowa-it Danke!
    Das mit dem MTU Wert war auch meine Vermutung, nur war dieser korrekt auf 1492 eingestellt (Telekom).
    Normalerweise wird dann der MSS Wert automatisch auf 1452 eingestellt, wenn man diesen nicht explizit angibt. Genau das scheint unter IPv6 nicht zu passieren, man muss tatsächlich diesen Wert dann mit angeben. Ich könnte mir vorstellen, dass das ein Bug ist, den so was ist mir bei andern Routern / Firewalls noch nie passiert.

    Jetzt scheint Netflix über IPv6 zu funktionieren, ich werde es weiter beobachten ☺.

  • LAYER 8 Moderator

    @nonick Und wo hast du MTU gesetzt? Auf dem WAN? Auf was?


  • @jegr Hi Jens, den MTU Wert von 1492 hatte ich schon immer auf dem WAN Interface gesetzt. Das ist ja bei PPPoE notwendig und bei mir auch der richtige ermittelte Wert. Zusätzlich musste ich jetzt noch den MMS Wert von 1452 auf dem WAN Interface eintragen. Das kenne ich so von anderen PPPoE Clients nicht, da wird der MSS Wert dann automatisch gesetzt (MTU-Wert - 40 Byte) wenn nicht explizit anderes angegeben. Bei IPv4 scheint das auch so auf der Sense zu funktionieren, nur nicht bei IPv6.

    Das alles betrifft natürlich nur das WAN Interface.

    Gruß Micha


  • Schön zu lesen, dass es hier weitergeht. Bevor ich jetzt wieder einen Versuch unternehme mein IPv6 zu konfigurieren könnte @JeGr das vielleicht nochmal verifizieren :-)

    Wo würde ich denn diese Einstellungen finden?

    Ich hab hier nur folgende:
    fd5704ef-6135-44e9-bff9-0f8212725c50-image.png


  • LAYER 8 Moderator

    @nonick Allerdings liest sich der Parameterwert bei MSS so, als müsste da 1492 rein, nicht 1452, denn dort steht ja, dass der Wert der dort eingetragen MINUS 40 genutzt wird. Somit wäre ja 1412 aktiv?


  • @jegr
    Diesen Satz habe ich auch schon ca. 18 mal gelesen und werde daraus nicht schlau, auch nicht aus dem Originaltext.

    Einzige vernünftige Erklärung für mich ist ein Schreibfehler. Es macht ja absolut keinen Sinn, dass MSS von MTU hergeleitet wird, falls ein MSS-Wert eingetragen ist. Das kann doch nur heißen sollen, falls kein Wert angegeben ist, wird MSS aus MTU minus 40 angenommen.

    Übrigens soweit ich weiß, sollte der bei IPv6 um 60 geringer sein als MTU.


  • @viragomann

    falls kein Wert angegeben ist, wird MSS aus MTU minus 40 angenommen

    Genau das ist gemeint. Das funktioniert auch unter IPv4, nur nicht unter IPv6. Da muss man den Wert händisch eintragen, damit dieser auch tatsächlich genutzt wird.


  • @viragomann
    Der Wert sollte tatsächlich um 60 geringer sein als MTU für IPV6. Da man bei der pfsense aber keine Einstellung für ipv6 treffen kann und das WAN interface, glaube ich sowohl für ipv4 als auch für ipv6 gilt, habe ich in dem Fall die MSS Größe von IPV4 eingetragen ( MTU - 40 ) angegeben.
    Für IPV6 wären aber MTU - 60 korrekt. Finde dafür aber keine Einstellungsmöglichkeiten.
    https://webcodr.io/2018/02/telekom-vdsl-mtu-und-mss-clamping-für-ipv4-und-ipv6/

    Da mein Fehlerbild dadurch behoben worden ist, gebe ich mich damit zufrieden. Viel Erfolg.


  • @nowa-it said in IPv6 und HTTPS... Kann manche Seiten aufrufen, andere hingegen nicht?!:

    Da mein Fehlerbild dadurch behoben worden ist, gebe ich mich damit zufrieden.

    Ist auch okay so, wenn es funkt.
    Habe es eingwandt für den Fall, dass es dennoch Probleme geben sollte.


  • @nowa-it said in IPv6 und HTTPS... Kann manche Seiten aufrufen, andere hingegen nicht?!:

    Für IPV6 wären aber MTU - 60 korrekt. Finde dafür aber keine Einstellungsmöglichkeiten.

    Das es nun nachgewiesen automatisch nicht bei der pfSense unter IPv6 funktioniert, sollte man vielleicht über eine Implementierung dieser Funktion nachdenken. Bei anderen Firewalls / Router gibt es ja auch die Möglichkeit, für IPv4 und IPv6 einen getrennten MSS Wert anzugeben.

    Das Argument ICMPv6 sollte genau das verhindern hilft eben auch nicht, wenn sich Anbieter nicht daran halten.

  • LAYER 8 Moderator

    Nur eine Frage: hat jemand statt direkt an MTU und MSS rumufingern ;) schonmal direkt im PPP(oE) Teil nachgeschaut und eine der Advanced Options ausprobiert?

    Vielleicht könnte einer, der die Probleme nachstellen kann, das ja mal testen, bevor man/wir da ein Fass aufmachen und die Lösung uns auf der Nase rumtanzt. Denn im PPPoE Setting unter Advanced gibts u.a. folgende Settings:

    6758eb33-59ad-42c2-b2b2-6ea86700f5d7-image.png

    Und gerade der Punkt TCPmssfix erscheint mir da interessant zu ohne gleich am MSS des Interfaces rumspielen zu müssen. :)


  • @jegr Ja. Der Punkt bewirkt leider gar nichts.
    Habe das Problem wie folgt reproduziert: MSS Wert unter dem WAN Interface entfernt. Netflix und einige Telekom Seiten hatten wieder Timeout.

    Anschließend TCPmssFix aktiviert. Geräte neugestartet, aber das Fehlerbild war weiter vorhanden. (Netflix wird nicht geladen.

    Ergo MSS wert von 1452 wieder rein. Siehe da alles wunderbar!


  • @nowa-it Das gleiche Verhalten konnte ich auch so nachstellen.

    Die Einstellung TCPmssFix ist Standardmäßig aktiviert und scheint schon was damit zu tun zu haben. Nur leider wirkt sich das nur auf IPv4 aus und nicht auf IPv6. Dort wird das entweder ignoriert, oder ein falscher Wert wird ausgewürfelt.