Ich kriege IPv6 mit Prefix Deligation nicht zum laufen..
-
@nocling Entschuldige, dass hatte ich in meinem Post falsch und hab es korrigiert. Ich frage 59 an und bekomme diese auch.
Dann passt auch alles... -.-
2a02:908:4c7:7d40::/59wäre dann von2a02:908:4c7:7d40::1bis2a02:908:4c7:7d5f:ffff:ffff:ffff:ffffDann wiederum passt aber die IPv6 nicht, die meinem Desktop zugewiesen wird:
2a02:908:4c7:7f40::1a71
-
@m0nkey Das stimmt, hast Du wohl einen Fehler im DHCPv6 Server. Zum Testen diesen abschalten und RA auf Stateless DHCP oder Unmanaged stellen.
-
@bob-dig Ok, hab ich gemacht, pfSense und PC neugestartet. Die IPv6 liegt nun im Range. Dafür sind die IPv6 Test Ergebnisse anders, aber trotzdem noch nicht i.O.:
-
@m0nkey Geht denn ping noch vom Rechner und was geht von der Sense aus?
-
@bob-dig Ping funktioniert noch:
Auch von pfSense aus:
Was mich auch stutzig macht ist, dass die IPv6 der Sense auf dem WAN interface nicht im Range der zugewiesenen IPv6 Range liegt. Ist das richtig so?
-
@m0nkey said in Ich kriege IPv6 mit Prefix Deligation nicht zum laufen..:
Ist das richtig so?
Jo, das ist normal, weil der delegierte Prefix ist zum Verteilen durch die Sense, am WAN aber bekommt die Sense die Adresse direkt vom Modem/Router.
-
@bob-dig Wenn ich mal die Beschreibung von test-ipv6.com nehme:
Dann kann ich den Server
ipv6.fra.test-ipv6.compingen:
Aber die URL
https://ipv6.fra.test-ipv6.com/ip/?callback=?im Browser logischerweise nicht aufrufen. Das heißt ja wahrscheinlich, dass HTTP(S) Traffic für IPv6 nicht funktioniert. Wie komme ich dem Fehler weiter auf die Schliche? -
@m0nkey said in Ich kriege IPv6 mit Prefix Deligation nicht zum laufen..:
https://ipv6.fra.test-ipv6.com/ip/?callback=?
Ich kann die Site tatsächlich aufrufen.
Was hast Du denn unter Floating? Vielleicht liegt es wirklich an deinem PC, ein Smartphone alleine wäre mir nicht genug der Verifikation, ein zweiter PC muss her. -
@bob-dig Floating Rules in pfSense habe ich nicht konfiguriert. Mein Office-Notebook unter Manjaro zeigt die gleichen Symptome, nur dass er nicht in den Timeout läuft, sondern schon nach ca. 0,6 Sekunden einen Fehler feststellt. Mein Windows-Notebook zeigt ebenfalls das Gleiche. Das Pingen von IPv6 Adressen geht auf beiden Notebooks trotzdem.
-
@m0nkey Es liegt definitiv an meinen Firewall Rules:
Ich habe testweise mal eine zweite Regel "IPv6 LAN net to any" erstellt und nach ganz oben geschoben und schon funktioniert es (Im Bild ist sie deaktiviert).
Jetzt bleibt noch die Frage, welche Regel macht hier Probleme?
-
@m0nkey Konnte es noch weiter eingrenzen. Es ist diese Regel:
Hier wollte ich einfach einen Zugriff auf das IPMI Netzwerk ausschließen und habe die Regel so definiert:
Und genau das macht Probleme. Ich verstehe aber trotzdem nicht warum...
-
@m0nkey Deine Screenshots sind ja nicht ganz vollständig, aber wenn es so ist, wie es scheint, dann könnte das eine Art Bug sein. Dein IPMI net hat gar kein IPv6, daraus wird dann invertiert irgendwie alles. Schon witzig. Da aber geblockt wird, ist es zumindest kein Risiko.
Oder anders, da die Regel so nicht erstellt werden kann, wird sie einfach ignoriert. Vermutlich so gewollt.
-
Teile die auf in v4 und v6 und du wirst sehen, es wird nur der v4 Teil Hits sammeln.
Du musst bei dynamischen Prefixen mit den Net Objekten arbeiten und das mit einer Regel pro Interface die du blocken/rejecten oder allowen willst.
-
@bob-dig Der ursprüngliche Gedanke war ja, den Zugriff auf das IPMI Net aus dem LAN zu verbieten. Ich habe nicht die ganze Regel gepostet, weil das die Standard "LAN to any" Rule ist, nur eben mit dem invertierten Zusatz für die Destination.
Aber gut zu wissen, dass meine Logik nicht komplett falsch ist, nur wahrscheinlich unorthodox. Ich hab jetzt einfach das "! IPMI net" rausgenommen und löse das dann anders.
Sollte man bzw. ich denn mit einer Unmanaged Prefix Deligation arbeiten? So wie ich das verstehe, ist das ja "Stateless" und ist das wiederum nicht unsicher?
-
@nocling Auch in einzelnen Regeln für IPv4 und IPv6 aufgeteilt funktioniert es. Das Problem war das "! IPMI net" in der Destination.
Außerdem benutzt die Regel ja "LAN net", falls du das mit Net Objekten meinst.
-
Ok wenn das ein Net Objekt ist geht das, dachte das ist ein selbst erzeugter Alias, das würde nicht gehen.
Ipv6 benötigt ICMP, unteach, tobig, timeex, echo req.
Und das auch eingehend auf WAN, findet sich aber in der RFC. -
@m0nkey said in Ich kriege IPv6 mit Prefix Deligation nicht zum laufen..:
Sollte man bzw. ich denn mit einer Unmanaged Prefix Deligation arbeiten? So wie ich das verstehe, ist das ja "Stateless" und ist das wiederum nicht unsicher?
Nö, nur für Server wäre DHCPv6 interessanter, ansonsten ist es eher gleich, was Du verwendest.
Ich würde IPv6 eh nur da ausrollen, wo Du es auch wirklich brauchen kannst. Sprich, internes und IPMI etc. würde ich bei IPv4 only belassen, dann brauchst Du auch deine IPv6-Regel nicht. -
@bob-dig Vielen Dank, du hast mir sehr geholfen.
Intern macht IPv6 wirklich keinen Sinn, falls ich mal einen Dienst per IPv6 anbieten will, kann ich ja mich ja immer noch mit DHCPv6 beschäftigen und da gibt es ja sicherlich auch Mischformen zwischen Stateless und Statefull.
-
@m0nkey Absolut.
Ich selbst betreibe einen "öffentlichen" E-Mail-Server auch über IPv6, aber per NAT.
-
@m0nkey said in Ich kriege IPv6 mit Prefix Deligation nicht zum laufen..:
Aber gut zu wissen, dass meine Logik nicht komplett falsch ist, nur wahrscheinlich unorthodox. Ich hab jetzt einfach das "! IPMI net" rausgenommen und löse das dann anders.
Es ist eben Invertierungslogik. Wenn das IPMI net gar kein v6 hat, dann wird es schwer "nichts" zu intervieren ohne alles zu bekommen. Genau deshalb gehe ich solche Sachen mit Invertern nur höchst ungern an denn sobald es mehr als "IPMI net" wird, ist man transparenter, wenn man einfach jedes nicht gewünschte Netz rejected. Denn mehr als einmal !xy_net funktioniert nach dieser Logik eh nicht. Daher würde ich einfach von Invertierungen in der Logik mit NOTs absehen, das hat schon immer zu lustigen Fehlerbildern geführt :)
Cheers
