OPNsense an Deutsche Glasfaser Anschluss / IPv6

[meyergru]

Das bedeutet, dass der RADVD nichts liefert (oder nichts ankommt). Entweder ist er nicht gestartet, oder die Definitionen in  /var/etc/radvd.conf sind nicht richtig für das Interface.

Da müssten Einträge stehen, die in etwa so aussehen:

Code Select Expand


# Generated for DHCPv6 server lan
interface ax0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1492;
        AdvDefaultPreference medium;
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        prefix 2001:1a61:340e:3310::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
};


Außerdem muss das Interface selbst (hier ax0) eine Adresse aus dem 'prefix'-Bereich haben (ifconfig ax0). Das kann z.B. schiefgehen, wenn man dort zusätzlich noch VIPs eingetragen hat.

Theoretisch könnten auch Firewall-Regeln greifen, sollte aber nicht sein.

[mczocker32]

Ich werde dem nochmal nachgehen. Gestern hatte ich nochmal einen neustart gemacht und OPNsense komplett neu installiert, sowie die FRITZ!Box so konfiguriert, dass ich die OPNsense dahinter packen kann. Dann auch WAN und LAN Einstellungen genaus so wie hier gepostet konfiguriert.

Das hat dann funktioniert und mein Client hatte, angeschlossen an der OPNsense, mehere IPv6-Adressen und auch das Gateway wurde, wie auch bei der FRITZ!Box ausgefüllt. Somit weiß ich schonmal, dass es eigentlich gehen sollte. Track Interface und RA klappte scheinbar.

Ich denke wenn es jetzt so funktioniert hat, sollte es eigentlich auch am echten WAN funktionieren ohne zusätzliche Firewall Konfigurationen oder ähnliches. Ansonsten habe ich mal testweise unter Tunables "net.inet6.ip6.use_tempaddr" auf 1 gesetzt, wenn das denn überhaupt richtig ist. Es hat nicht schlechter funktioniert, daher habe ich es mal so gelassen. In der radvd-Config sah ich auch den Präfix. Wie es am DG-Anschluss ist muss ich dann mal schauen.

[mueller]

... bei mir hat sich die Situation nicht verändert.
Leider komme ich auch nicht weiter, weil ich hier meine Grenzen erreiche.
Ich hoffe mal auf ein nächstes Update.
Falls das nicht hilft, muss ich mich leider nach einer anderen Lösung umsehen, da ich auf IPv6 angewiesen bin.
Wahrscheinlich aktiviere ich dann wieder meine FritzBox, OPNsense ist für mich so zu komplex :-)

[mczocker32]

Ich habe es nun nochmal versucht und es hat endlich geklappt. Erst ging es nicht, da ich duch die Tests gestern bei einem Präfix mit /57 gelandet bin, was mir dank der radvd.conf aufgefallen ist und nachdem ich es zurück auf /56 gestellt habe ging es dann. https://test-ipv6.com/ sagt 10/10.

Jetzt noch alles umziehen und dann habe ich es endlich.

Vielen vielen dank für die ganze Hilfe.  ;D

[mueller]

Hallo,

ein kurzer Nachtrag:

Seit heute erhalte ich wieder eine IPv6-Adresse - ohne an der Konfiguration (s.o.) etwas zu ändern.
Der "Fehler" lag eindeutig beim ISP.

Nachdem ich den WAN Port Stecker gezogen hatte und dann das Packet Capturing mit Filter auf UDP geschaltet habe, hat sich gezeigt, dass die firewall sich tadellos verhalten hat. Erst nachdem ich dem "support" eine E-Mail mit der gesicherten .pcap Datei geschickt hatte und mehrmals telefonisch genervt habe, haben die reagiert.
Naja, einige Nerven gelassen, aber auch wieder was dazu gelernt ... :-)

[komarov]

Moin,
ich komme momentan von einer "normalen" Fritzbox der als reiner Router gearbeitet hat nun zu OPNSense.
Einrichtung hat eigtl sehr gut funktioniert, jedoch bekomme ich wie meine Vorredner auch ums verrecken keine IPv6 am WAN. Habe etliche Konfigurationen probiert, ohne Erfolg. Da ich von der Fritzbox kam, habe ich auch mein Glasfasermodem resettet um eine neue v6 IP zu bekommen. Reset war erfolgreich, jedoch immernoch nur eine v4 IP am WAN.
Einzig wenn ich im WAN Interface den Haken bei "Request only an IPv6 prefix" setze, habe ich eine IPv6, jedoch dann beim DHCPv6 im LAN keine Available Range "No available address range for configured interface subnet size."

Kleine Anmerkung: OPNSense Router hängt quasi direkt am ONT, wobei ich erwähnen muss das dazwischen ein Devolo Giga Set ist womit ich das Signal vom Modem im Keller über die Telefonleitung nach oben durchschleife (Hat mit der Fritzbox oben in der Wohnung problemlos funktioniert ohne Leistungseinbußen)

[tiermutter]

"normale" Fritzbox bedeutet also, dass es eine eigene Fritte war und nicht eine von DG gestellte?!

[tiermutter]

Oder mit anderen Worten: Der Anschluss wurde "mit eigenem Router" bestellt?

[komarov]

Also es geht jetzt tatsächlich von jetzt auf gleich warum auch immer mit der Option "Request only an IPv6 prefix".
Hatte das schon mehrmals probiert keine Ahnung warum das jetzt auf einmal geht ;D
IPv6 Test auch 10/10

Hatte direkt bei Bestellung angegeben das ich einen Kundeneigenen Router benutze.
Naja trotzdem danke erstmal für die schnelle Antwort !

[Ghostie91]

Nur der IPv6-Teil. Der IPv4 Alias ist für die Funktion unnötig und lässt ggf. den Zugriff auf den ONT zu (mit NAT!) - funktioniert aber nur, wenn kein Sync anliegt. Die Präfix ID kann man frei wählen (muss nur pro Interface unterschiedlich sein und in 8 Bit passen. Und wie gesagt, DHVPv6-Server ist aus, würde aber auch gehen.

Mit diesen Einstellungen bekommt WAN keine routebare IPv6 - ist aber auch nicht notwendig. LAN bekommt eine und die Clients per SLAAC auch.

Guten Tag zusammen, ich muss das Thema hier leider nochmal hochholen.

Ich hab alle Einstellungen wie im Beitrag oben gesetzt.

Anbieter: Deutsche Glasfaser - Opnsense direkt hinter dem ONT (kundeneigener Router - Anschlussmodell FibreTwist (NT) )
Der Anschluss ist ca 1 Monat alt. Glasfaser 1000Mbit Down 500Mbit up
Alle Einstellungen wie oben gesetzt. (Hab ich 10 mal gemacht und jedes mal auch wieder geprüft)
Den ONT hab ich auch neu gestartet nach den Einstellungen.

Opnsense sagt dann folgendes:

WAN (wan)    ixl0        dhcp   
Ipv4: 100.102.xxx.xx/20
Ipv6: fe80::ae1f:xxxx:xxxx:xxxx/64
Ipv4 Gateway: 100.102.xx.1
Ipv6 Gateway: fe80::xx
Routes: 100.102.xx.0/20

LAN (lan)    vtnet0        static   
Ipv4: 192.168.3.1/24
Ipv6: 2a00:6020:8fc0:xxxx:xxxx:xxxx:xxxx:xxxx/64
Ipv6: fe80::xxxx:xxxx:xxxx:xxxx/64

Routes:192.168.3.0/24
Routes: 2a00:6020:8fc0:xxxx::/64

Die Clients im Lan erhalten auch eine Ipv6 im richtigen 2a00: Bereich.

Nun zu den Problemen: Kein Client kann Ipv6 pingen, DNS Auflösung klappt aber kein Ping.
Auch kein ping ipv6 auf google.com oder ipv6.google.com über opnsense.

2a00:6020:xxxx --> 2a00:1450:4001:80b::200e
--- ipv6.l.google.com ping statistics ---
78 packets transmitted, 0 packets received, 100.0% packet loss


Wenn ich die public ipv6 welche das opnsense Lan interface erhalten hat, versuche zu erreichen  (Portfreigabe richtig gemacht - Firewall - Rule - WAN -> Port -> LAN Ip + Port)
klappt auch nicht. Also ist keine der IP Adressen aus dem Bereich den ich von DG erhalten habe von außen erreichbar. Ich hab wirklich alles schon versucht.

Hab Firewall Logs geprüft und auch Packet Capture -> Es kommt die Anfragen von außen nicht an.

Aktuell hab ich bei WAN Interface - Request prefix only - deaktieviert.

Somit erhält das WAN eine 2a00:xxxx/128 Adresse. Diese ist dann auch von außen Erreichbar und mein Portforwarding funktioniert entsprechend.
Ein ping ipv6 auf google.com aus opnsense ist dann auch möglich.

So kann ich aber von keinem meiner Clients per Ipv6 nach außen...

Hoffe ihr könnt mir weiterhelfen. (Muss ich bei DG Anfragen oder von denen was im Vertrag ändern lassen?)

Wenn ihr noch irgendwas bestimmtes braucht, lasst es mich wissen.

Vielen lieben Dank

[meyergru]

Die IPs sehen soweit richtig aus. Dass der Zugriff von außen nicht möglich ist, ist klar, wenn Du keine Firewall-Regeln eingerichtet hast, die das erlauben.

Da die Clients eine korrekte IPv6 erhalten, sollte es also gehen.

Ich würde (das geht erst seit einiger Zeit) noch "Optional Prefix ID" setzen. Es muss ein anderer Wert als die Prefix-ID für jedes LAN sein.
Damit kann man die 8 Bit-Präfix-ID für das WAN bestimmen, dann bekommt das WAN auch eine IPv6 aus dem Präfix-Bereich zugewiesen.

Dann würde ich in dieser Reihenfolge testen:

1. Kann die OpnSense selbst IPv6 ins Internet? ("ping 2600::"). Falls nein: Firewall-Regeln und Routen prüfen, im FW-Log nachsehen.
2. Können die Clients ins Internet? ("ping 2600::"). Falls nein: IPv6-Zuweisung prüfen, Traceroute checken, FW-Log prüfen.

Erst im letzten Schritt gucken, ob Zugriff von außen möglich ist (aber wozu?). Etwaige FW-Regeln sollten sehr restriktiv sein - ich würde normalerweise für so etwas aber einen Reverse Proxy verwenden, wenn Du es wirklich benötigst. Siehe auch: https://forum.opnsense.org/index.php?topic=45822.0

[Ghostie91]

Die IPs sehen soweit richtig aus. Dass der Zugriff von außen nicht möglich ist, ist klar, wenn Du keine Firewall-Regeln eingerichtet hast, die das erlauben.

Da die Clients eine korrekte IPv6 erhalten, sollte es also gehen.

Ich würde (das geht erst seit einiger Zeit) noch "Optional Prefix ID" setzen. Es muss ein anderer Wert als die Prefix-ID für jedes LAN sein.
Damit kann man die 8 Bit-Präfix-ID für das WAN bestimmen, dann bekommt das WAN auch eine IPv6 aus dem Präfix-Bereich zugewiesen.

Dann würde ich in dieser Reihenfolge testen:

1. Kann die OpnSense selbst IPv6 ins Internet? ("ping 2600::"). Falls nein: Firewall-Regeln und Routen prüfen, im FW-Log nachsehen.
2. Können die Clients ins Internet? ("ping 2600::"). Falls nein: IPv6-Zuweisung prüfen, Traceroute checken, FW-Log prüfen.

Erst im letzten Schritt gucken, ob Zugriff von außen möglich ist (aber wozu?). Etwaige FW-Regeln sollten sehr restriktiv sein - ich würde normalerweise für so etwas aber einen Reverse Proxy verwenden, wenn Du es wirklich benötigst. Siehe auch: https://forum.opnsense.org/index.php?topic=45822.0

Danke für Ihre Hilfe :)

Das mit Optional Prefix ID hab ich nun so gemacht. Nun bekommt das WAN auch eine 2a00:6020:xxxx/64 Adresse.
(unterschiedlicher Prefix für LAN und WAN wurde genutzt)

OpnSense kann aber immer noch nicht nach außen Pingen (2600::).

FW-Log kein nennenswerter Eintrag gefunden (Plain View alle Log Level) ,General Log ist leer (alle Log Level), im Anhang die Routen, Firewall Live zeigt auch nicht, dass was geblockt wird.

Firewall Regeln: LAN Alles Erlaubt (ipv4+6), WAN nur die Ports die ich brauche. Aber sollte bei Ping nach außen ja keine Rolle spielen oder?

https://imgur.com/a/bfQUmwt


Ping geht raus (Packet Capture, aber es komm nichts zurück)

Code Select Expand

WAN (ixl0) – 2025-07-25 12:56:10.833750
ICMPv6 Echo Request (Ping), ID 51716, Seq 2
MAC: ac:1f:6b:••:••:•• → 20:00:00:••:••:••
IPv6: 2a00:... → 2600:...
Länge: 70 Byte, Hop Limit: 64
Wie gesagt, das seltsame ist, dass wenn ich nur eine direkt IP von DG für WAN anfordere, der Pingv6 und Zugriff von außen funktioniert

Nochmals vielen Dank.

Kann auch gerne Anydesk oder Teamviewer teilen, und würde auch Trinkgeld geben. Gerne dann eine PM.

Danke  :)

[meyergru]

Nimm auf WAN mal die (zusätzlichen) Regeln weg. Standardmäßig ist da alles erlaubt und das sollte es auch sein.

Und wie gesagt: Wenn man bei den Regeln das Logging einschaltet, sieht man dann ggf. im FW-Live-Log auch, ob die Regeln (eventuell unerwarteterweise) greifen, wenn man die Tests durchführt.

[Ghostie91]

Erledigt.

Kein Erfolg. Aber im WAN gibt es ja die auto. generierten Regeln. Meine waren nur da um etwas zuzulassen. Eine Default im WAN alles erlauben regeln gab es nicht.

So eine Regeln war nur im LAN. Ich hab jetzt aber auch kurzfristig die ganze Firewall deaktiviert und vorher auch eine Regeln erstellt, welche alles zulässt im WAN.

Beides ohne Erfolg. Der Ping geht aus Opnsense raus aber es kommt nichts zurück.

Ich hab hier einen Thread gefunden, dass genau dieses Problem mehrere Leute haben:

https://www.glasfaserforum.de/forum/thread/2530-kein-traffic-ueber-ipv6-moeglich-deutsche-glasfaser/?postID=42715#post42715

Ärgerlich... :(

[meyergru]

Also wenn das mit der IA_NA auf dem WAN geht aber die IA_PD nicht, dann hat DG das Routing der IA_PD (Präfix) nicht richtig konfiguriert.

Dieses Problem würdest Du aber auch mit deren Router nachstellen können und kannst sie dann um Support bitten. Bei 3rd-Party-Routern stellen die sich (wie viele andere ISPs auch) nämlich an.

Umgekehrt: Wenn es mit deren Router geht, dann liegt es an Deiner Konfiguration.