OPNsense Forum
International Forums => German - Deutsch => Topic started by: Lumpy on October 11, 2017, 10:05:41 am
-
Hallo Leute, ich kämpfe aktuell mit einem sehr kuriosen Problem. Ich muss dafür etwas weiter ausholen und hoffe, dass wir gemeinsam zu einer Lösung kommen.
Mein VDSL-Anschluss ist ein ein stinknormaler Privatkundenanschluss der Telekom, als Modem vorgeschaltet ist ein ZyXEL VMG1312-B30A mit aktueller Telekom-Firmware. Die Telekom fährt den Anschluss im Dual Stack Betrieb, ich bekomme eine IPv4-Adresse und mein eigenes IPv6-Subnet. Aus meinem LAN habe ich somit Zugriff auf alles was IPv4 und IPv6 ist. So klar so einfach.
Der Test von test-ipv6.com sagt 10/10, der von ipv6-test.com sagt 18/20 wegen geblocktem ICMP. Stellt aber eigentlich kein Problem dar.
Ich habe aber dennoch das Problem, dass ich die Seite webmail.tu-clausthal.de nicht aufrufen kann, solange Dual Stack aktiv ist. Die Seite lädt einfach "unendlich" und bleibt weiß, es kommt keine Fehlermeldung etc im Browser. Sobald ich mich nur via IPv4 bewege, funktioniert alles. Das kuriose ist, dass es via Dual Stack aus dem Mobilfunknetz der Telekom z.B. funktioniert.
Ich stehe mit dem Admin der TU in Kontakt, ist ein Bekannter von mir, aber er sagt auch, die haben zu Hause nen Anschluss von Kabel Deutschland, der macht auch Dual Stack und da funktioniert der Zugriff einwandfrei. Ich muss ganz klar sagen, dass ich mit IPv6 nicht so fit bin wie mit IPv4, schließe einen Fehler meinerseits also absolut nicht aus, habe aktuell aber noch keinen Ansatz, wie ich das ganze jetzt weiter verfolgen sollte...
Ich kann bei Bedarf traceroute-logs, pings, nslookup etc. liefern, bin jetzt aber auf eure Expertise angewiesen. :)
-
Wenn du 18/20 hast, sollte dein Client auch eine gültige v6 haben korrekt? Hat die Sense auch sauber eine auf der LAN Seite? Track Interface etc. konfiguriert? DNS etc. alles per v6 auch in den Regeln erlaubt?
-
Alle Clients im LAN haben eine gültige IPv6 aus dem mir zugewiesenen Subnet der Telekom. Auch die OPNsense hat sowohl WAN- als auch LAN-seitig eine IPv6.
"Track Interface" meinst du WAN-seitig? Das muss für einen Telekom-Anschluss doch auf DHCPv6 stehen, wenn mich nicht alles täuscht. Hab das jedenfalls hier aus dem Forum (https://forum.opnsense.org/index.php?topic=5069.msg22321#msg22321), die Konfiguration. LAN-seitig ist "Track Interface" für IPv6 aktiv, als IPv6 Interafce ist "WAN" ausgewählt, IPv6 Prefix ID ist 1.
Zu den Firewall-Regeln (das ist tatsächlich eine große Unbekannte für mich), welche benötige ich für korrektes IPv6 denn genau? Dachte Outbound wäre eh standardmäßig alles erlaubt? Könnte aber sein, dass da schon der Hase im Pfeffer liegt... Eine Outbound IPv6 ANY Regel habe ich aber, habe die IPv4 Regel geclont und nur die Protocolversion von IPv4 auf IPv6 geändert.
Muss dem Unbound DNS noch etwas mitgegeben werden?
-
Bei mir lädt die Seite auch unendlich. Ich hab aber keine Zeit mir das jetzt näher anzugucken.
VDSL 100 mit Vectoring von DTAG, Dualstack mit IPv4 und IPv6 bis an die Clients, Modem ist ein Vigor 130, OPNsense ist aktuell. ICMPv6 hab ich händisch freigegeben. Bei deinem Test bekomme ich auch 10/10. six.heise.de klappt auch.
-
Also zumindest kein Einzelfall...
-
Läd bei mir auch nicht, HE Tunnel 17/20 sowie 10/10.
Ich probier das morgen noch aus dem Office mit nativem IPv6.
Grüsse
Franco
-
Bei uns aus dem Office mit nativem DualStack geroutet klappts. Sehr merkwürdig.
-
Haben wir ne Chance einzugrenzen, woran das liegt? Eher OPNsense oder eher der Serverbetrieber? Oder vll die Telekom?
-
meine 5-cent...
Test mit Firefox und Edge von Windows 10: kommt nix
Test mit iPhone7: kein problem
iPhone über WLAN und gleiches Netz wie der Windows Rechner.
ISP Titan-Networks also nicht Telekom...
Scheint mir ein Problem an der UNI zu sein... ( GeoBlocking ? )
-
Was uns allen aber gemein ist, ist die OPNsense, sehe ich das richtig?
€dit: Ich glaube ich hab eine Idee. Ich nehme an, wir nutzen alle LibreSSL? Der Firefox hängt beim TLS-Handshake, das spuckt die Statusleiste inzwischen aus. Kann es sein, dass der LibreSSL-Library etwas fehlt, bzw. der Uni-Server noch veraltete Protokolle einsetzt, die aus LibreSSL rausgeflogen sind?
-
GeoBlocking / Blocking von IPv6 Tunneln tönt plausibler.
Ich prüfe es gleich noch aus dem Büro... brb
Grüsse
Franco
-
Also OpenSSL oder LibreSSL macht in der Tat keinen Unterschied. :( Schade, das hätte gut gepasst ^^
Hängt auch da bei "TLS-Handshake mit webmail.tu-clausthal.de wird durchgeführt..."
-
Scheint sich beim Aushandeln der TLS Verschlüsselung "auf zu hängen".
Hab es auch auf eine Win7 Kiste versucht, kommt über ipv4 problemlos durch aber ipv6 hängt.
Denk aber nicht dass dies ein OPNSense Problem ist, wieso sollte dann mein iPhone gehen?
-
Im Dual-Stack von Vodafone die Website erreichbar. Am besten mit dem Betreiber sprechen.
Grüsse
Franco
-
Hm, anderer Ansatz. Wie müsste eine korrekte ICMP Regel für IPv6 ins LAN aussehen, damit der ipv6-test.com 20/20 ausspuckt?
Sonst gehen mir erstmal wieder die Ideen aus, was ich noch ausprobieren könnte...
-
Auf dem WAN ICMPv6 Echo Request anmachen von Source any nach Ziel v6 Prefix des LANs.
-
So?
€dit: Passt, die Windows Firewall funkte erst dazwischen. Problem mit dem Zugriff auf webmail.tu-clausthal.de bleibt aber dennoch bestehen. :(
-
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:
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:
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
-
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.
-
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?
-
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.
-
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
-
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.
-
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.
-
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...
-
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.
-
> 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: 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.
-
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.