[GELÖST]bestimmte Website lädt nicht - IPv4 OK, Dual-Stack n. OK

[JeGr]

Auf dem WAN ICMPv6 Echo Request anmachen von Source any nach Ziel v6 Prefix des LANs.

[Lumpy]

So?

€dit: Passt, die Windows Firewall funkte erst dazwischen. Problem mit dem Zugriff auf webmail.tu-clausthal.de bleibt aber dennoch bestehen. :(

[Woi]

Ich hab noch eine Seite gefunden mit der das gleiche Verhalten auftritt:
http://kamelopedia.net/ bzw. http://kamelopedia.net/wiki/Kamelopedia:Hauptseite, denn Ersteres bringt einen Redirect auf Letzteres und der Redirect funktioniert sowohl mit IPv6 als auch IPv4. Das Problem tritt erst danach auf:

Code Select Expand


curl -6 -v -o /dev/null  http://kamelopedia.net/wiki/Kamelopedia:Hauptseite
...
* TCP_NODELAY set
* Connected to kamelopedia.net (2a01:238:42ea:d900:e5d3:890d:85f6:9f7c) port 80 (#0)
> GET /wiki/Kamelopedia:Hauptseite HTTP/1.1
> Host: kamelopedia.net
> User-Agent: curl/7.53.1
> Accept: */*
>
> [hängt ewig]


IPv4 dagegen klappt:

Code Select Expand


curl -4 -v -o /dev/null  http://kamelopedia.net/wiki/Kamelopedia:Hauptseite
...
* TCP_NODELAY set
* Connected to kamelopedia.net (85.214.108.33) port 80 (#0)
> GET /wiki/Kamelopedia:Hauptseite HTTP/1.1
> Host: kamelopedia.net
> User-Agent: curl/7.53.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.26
< X-Content-Type-Options: nosniff
< Content-language: de
< Vary: Accept-Encoding,Cookie
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Date: Fri, 20 Oct 2017 19:27:30 GMT
< X-Varnish: 391412772 391407572
< Age: 4470
< Via: 1.1 varnish
< Connection: keep-alive
<
{ [955 bytes data]
...
* Connection #0 to host kamelopedia.net left intact


Vielleicht hilfts ja bei der Fehlersuche

Grüße
Woi

[Helge]

Das gleich Verhalten hatte ich auch bei PFSense. Ändere zum Test mal deinen MTU Wert vom LAN Interface auf den gleichen Wert wie du ihn unter dem WAN Interface eingetragen hast. Normalerweise bleibt dieses Feld frei und damit hat das LAN den Standard MTU Wert von 1500.

[Lumpy]

Das MTU-Feld bei WAN ist leer, unten drunter steht als "calculated ppp mtu: 1492". Wenn ich dort 1492 eintrage, wird die calculated ppp mtu: 1484. Sollte ich da etwas festen einstellen oder das Feld unter WAN leer lassen und bei LAN 1492 einstellen?

€dit: Habe bei LAN jetzt einfach mal 1492 eingestellt, es sieht tatsächlich so aus, als würde das das Problem lösen.

€dit 2: Ich fasse es nicht, das klappt tatsächlich. :) :) Mehrmals neugestartet, Firewall selbst, wie auch einen angeschlossenen PC und es macht jetzt genau das, was es soll. DANKE, Helge!

Ist das ein Bug in FreeBSD bzw. im Intel-Netzwerktreiber? Kann oder sollte man das irgendwo melden?

[Helge]

Hi Lumpy, freut mich das es bei dir auch so funktioniert :).

Ich habe das mit verschiedener Hardware unter OpnSense / PFSense getestet, überall das gleiche Verhalten.
Auch eine Anfrage im PFSense Forum blieb dazu unbeantwortet. Daher gehe ich von einem Bug in FreeBSD aus. Mich wundert es nur, dass es bisher kaum einer bemerkt hat. Diesen Bug beobachte ich schon seit FreeBSD 10 und ist auch in der aktuellen Version 11 vorhanden.

[JeGr]

Ahoi zusammen,

> Privatkundenanschluss der Telekom
> Daher gehe ich von einem Bug in FreeBSD aus.

Das glaube ich erstmal nicht - sondern gehe an der Stelle von einem typischen Telekom DSL/MTU Problem aus. PPPoE bei der Telekom arbeitet nun ja auch schon mit "reduzierter" MTU durch den Overhead bei PPPoE. Gäbe es hier einen konkreten Fehler/Bug in FreeBSD oder im Netzwerkstack, wären ja auch alle anderen betroffen. Hier scheint es aber nur die DSL User zu treffen, wie auch schon bei Einführung von PPPoE damals mit der Umsetzung von MTU 1500 von LAN auf 1492 - oder in Ausnahmefällen sogar bis herunter auf 1442 - die eingestellt werden müssen.

Daher auch der Wert "calculcated ppp MTU": Bei 1500 werden die 8 Byte im Frame für den PPP Overhead benötigt und sollten/müssen deshalb gesetzt werden, damit die Pakete auf dem WAN entsprechend umgebaut und gesplittet werden können. (dadurch auch das 1484 - der calculated value zieht da einfach die 8 Byte vom Wert im Feld ab).

Was man durchaus als "Bug" sehen könnte ist die Tatsache, dass ihr - sofern ich das recht verstanden habe - das LAN ändern musstet damit das rund läuft. Normalerweise sollte es genügen, wenn das WAN entsprechend konfiguriert ist und die Pakete dann entsprechend neu gesplittet werden. Aber vielleicht kann da ja einer der Entwickler was dazu anmerken, wenn man das als Bug bzw. Nachfrage aufmacht :)
Warum ich nicht von Bug per se ausgehe ist, dass es hier wohl nur bei PPP Verbindungen auftritt, nicht bei anderen Varianten wie Kabel, Ethernet etc.

Grüße

[Helge]

Hi JeGr,

es geht ausschließlich um Dual Stack Verbindungen, die eine Änderung des MTU Wertes am WAN Interfaces erfordern. Das betrifft alle Internet Anbieter, die einen abweichenden Standard MTU Wert von 1500 benötigen, wie es z.B. bei einer PPPoE Einwahl der Fall ist. Dieser WAN MTU Wert muss zwingend auch am LAN Interface (abweichend vom Standard 1500 MTU Wert) eingetragen werden, da sonst einige Webseiten nicht mehr erreichbar sind, wenn IPv6 Vorrang hat.

Das wurde mit verschiedener Hardware, OpnSense / PFSense und Providern getestet und ist immer reproduzierbar.

Der Workaround funktioniert, ist aber nicht korrekt und muss m.M.n. ein Bug in FreeBSD sein.

[Lumpy]

Nochmal ein bisschen was gelesen und IPv6 unterstützt dieses Packet-Splitting nicht bzw. anders als das noch bei IPv4 der Fall war.

https://de.wikipedia.org/wiki/Path_MTU_Discovery

Irgendwo auf dem Weg werden vll die ICMPv6-Typ-2-Pakete geblockt/verworfen.

[Droppie391]

Meine 5 Cent: wir haben den LAN-MTU auf 1500, der vom WAN auf 1470 (Calculated > 1462) und ein Floating-Rule welche auf alle LAN und WAN Schnitstellen IPV6-ICMP in beide Richtungen erlaubt.
Reultat ist, dass falls ein LAN Rechner ein zu großes Paket verschickt, der Gegenstelle dies als Packet to Big meldet und da diese Meldung wieder zurück kommt beim LAN Rechner, kann dieser seine Pakete verkleinern. Funzt soweit alles prima. Alles mit Wireshark getestet (mit filter icmpv6).

Meiner Meinung nach ist es also KEIN OS oder OPNsense problem und ist hier auch kein Bedarf etwas zu ändern.
Klar kann man auf alle Schnittstellen den MTU auf den gleichen (tiefen) Wert setzen. Damit vermeidet man dan die Packet to Big Verhandlungen. Ob dies aber im LAN erwünscht ist...

[Helge]

Hi Droppie391,

IPV6 ICMP Pakete sind in beiden Richtungen in der Firewall erlaubt. Der "Fehler" tritt nur bei sehr wenigen Webseiten auf, deswegen wird es vermutlich nicht bemerkt. Es kann natürlich auch an einer Fehlkonfiguration am Webserver der Gegenstelle liegen, der das zurücksenden von IPV6 ICMP Pakete verhindert. Sowas müsste man mal mit Wireshark prüfen.

[JeGr]

> Ob dies aber im LAN erwünscht ist...

Droppie hat das schon richtig angesprochen, auf dem LAN will ich das eigentlich nicht ändern müssen als Netzwerker, denn damit beschränke ich auch den Paketfluß intra-LAN oder VLAN wenn ich mehrere Netze auf der Sense terminiere. Sprich man setzt auch den Durchsatz im LAN zu bspw. anderen VLANs/DMZ herunter. Mag für manche nicht spürbar sein, für andere dann schon.

Ich vermute aber an der Stelle tatsächlich auch eher ein Problem in der v6 Kommunikation. Vielleicht auch wirklich auf der Seite des Servers, dass deren Provider da noch ganz Old-School ICMP blockt oder nur Ping etc. durch lässt und sowas wie Packet-too-big etc. wegschluckt. Wäre interessant.

@Helge: Ist hier wirklich IPv6 ICMP mit allen Submodi vollständig an und vom LAN erlaubt? Oder nur einzelne Submodi wie echo-reply etc.? Nur interessehalber :)

[Helge]

@Helge: Ist hier wirklich IPv6 ICMP mit allen Submodi vollständig an und vom LAN erlaubt? Oder nur einzelne Submodi wie echo-reply etc.? Nur interessehalber :)

Ja,  IPV6 ICMP ist komplett in beiden Richtungen erlaubt.

Da es nur wenige Webseiten betrifft, würde ich doch von einer Fehlkonfiguration der Gegenstelle ausgehen.  Vermutlich werden da die IPV6 ICMP vollständig, oder zum Teil blockiert.

Nachtrag
Eine Webseite die nicht funktionierte und ich noch in Erinnerung hatte, funktioniert jetzt auch ohne Veränderung des MTU Standard Wertes am LAN Interface. Scheint also doch an einer Fehlkonfiguration der Gegenstelle gelegen zu haben.

Ich sollte wohl Fehler nicht immer bei mir selbst suchen ;).

Bei der von Lumpy genannten Webseite webmail.tu-clausthal.de besteht das Problem weiterhin. Wenn jemand Lust und Zeit hat, kann ja mal mit Wireshark schauen, ob der Webserver auf IPV6 ICMP Pakete korrekt antwortet.

[JeGr]

Interessant! Na das wird ja lustig, als wäre die Einführung von IPv6 nicht schon schwer genug, jetzt pfuschen potentiell auch noch die Kollegen die es besser wissen sollten *seufz*

Dann müssen wir wohl einfach mal am Ball bleiben und weitersehen.