13.01.2021

8059

OPNsense: Schaffe es nicht IPv6 an einem vlan-Interface zum Laufen zu bringen

Hallo liebes Forum,

lange Zeit war ich stiller Mitleser. Aber jetzt möchte ich euch gerne um Hilfe bitten.

Zunächst mal: Vielen Dank für den vielen und überaus nützlichen Input und ganz besonderen Dank an Kollegen Aqui für die wirklich zeitlosen Tutorials!

Auch habe ich mich -bis auf wenige Ausnahmen- an eure Hardwareempfehlungen gehalten.

Zu meiner Situation. Ich befinde mich seit Juni letzten Jahres in Griechenland. Hier habe ich das Hotel meiner Eltern übernommen. OK, wie überall auf der Welt ein derzeit schwieriges Business zum Geld verdienen.

Hier habe ich eine IT-Infrastruktur aufgebaut inklusive Gäste Wifi über Captive-Portal mit voucher-system.

Die Hardware:

- Speedport Entry 2i im Bridge-mode (nur DSL-Modem).
- APU2E4 (OPNsense).
- Fritzbox 7590 (beschnitten bis auf VoIP und DECT-Station).
- Cisco SG250-10P 10-Port Gigabit PoE Smart Switch.
- Raspberry pi4 (pi-hole, Unifi AP Controller, CUPS, Samba …).
- 1 (bald mehrere) UniFi AP-AC-Pro Access Point.

Aufbau:

ISP (Cosmote, GR) -> OPNSense (igb0=WAN, igb1=LAN) -> Cisco Switch

Switch:
Port 1: OPNsense
Port 2: Raspberry Pi4
Port 3: Fritzbox
Port 6: Unifi AP

Der AP sendet 2 SSID’s. Eine für das administrative LAN und eine weitere (vlan=2 mit parent interface igb1 an der OPNsense) für das Gäste Wifi. Am Switch habe ich die Ports 1,2 und 6 auf Trunk gestellt (default vlan1=untagged, vlan2=tagged). Sämtliche Aufgaben übernimmt die OPNsense (DHCP, Routing). Routing ist am Switch disabled.

Alles funktioniert wunderbar. Aber ich habe hier zu viel Zeit und den Anspruch auch IPv6 zum Laufen zu bekommen. Für das administrative LAN (native vlan 1) klappt es auch. Leider nicht für das vlan Gäste WiFi. Am ISP liegt es nicht es nicht. Vom ihm bekomme ich ein /56 Prefix. Ich habe mal Testweise das igb2 Interface an der OPNsense aktiviert. Interface, DHCPv6 und radvd-Einstellungen bis auf „IPv6 Prefix ID“ identisch wie bei igb1 und igb1_vlan2 (Track Interface, Assisted Mode). Wenn ich am igb2 Interface ein Laptop einstöpsele funktioniert alles einschließlich IPv6.

Also, ich bekomme für das Gäste Wifi keine IPv6 Adressen. Ein seltsames Verhalten habe ich noch beobachtet. Nach einiger Zeit im Gäste Wifi sehe ich auf meinem Android-Smartphone doch eine IPv6 Adresse und kurz darauf schmeißt mich das Captive-Portal raus. Wenn ich IPv6 abstelle, kein Problem.

Könntet ihr mir helfen? Was übersehe ich? Noch irgendwelche Einstellungen am Switch? Oder an der OPNsense? Wie bekomme ich IPv6 an der vlan Schnittstelle zum Laufen?

Hoffe, ich habe ausreichend Infos mitgeben können

Vielen Dank schon mal im Voraus.

Niko

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 640124

Url: https://administrator.de/forum/opnsense-schaffe-es-nicht-ipv6-an-einem-vlan-interface-zum-laufen-zu-bringen-640124.html

Ausgedruckt am: 05.05.2025 um 18:05 Uhr

23 Kommentare

Neuester Kommentar

Der AP sendet 2 SSID’s. Eine für das administrative LAN

Wie gruselig !! Du strahlst im Ernst das administrative LAN also das Management LAN als WLAN SSID aus ?? Nicht dein Ernst oder ? Ein Kardinalsfehler im WLAN Design. Das Management Netz hat logischerweise niemals eine WLAN SSID und sollte aus Gründen die auf der Hand liegen immer nur per Kupfer zugänglich sein. Das solltest du dringenst mal überdenken was du da machst ?!
Zurück zum Thema....

Am Switch musst du nichts einstellen, der rennt ja sicher im reinen Layer 2 Mode und für den sind nur Mac Adressen interessant aber nix mit IP.
Dadurch das es an 2 LAN Interfaces funktioniert kannst du ja auch sehen das du generell mit der IPv6 Konfig alles richtig gemacht hast. Im Grunde ist es ganz einfach...den /56er Pool den du per PD vom Provider bekommen hast gibt die Firewall als /64er auf den LAN Interfaces weiter. Ob das VLAN Subinterfaces sind oder physische Interfaces ist dabei völlig Wumpe....jedenfalls bei einer pfSense Firmware.
Gehe einmal startegisch vor um die gruselige Ubiquity Hardware als Fehlerquelle ausschliessen zu können:
Generiere dir einen UNtagged Kupfer Port im Gastnetz VLAN auf dem Switch so das du direkt mit einem Test PC/Laptop an der Firewall hängst.
Dann testest du die IPv6 Adressierung nochmal. Das VLAN Subinterface sollte für IPv6 natürlich identisch so konfiguriert sein wie eins der pysischen Testinterfaces igb1 oder igb2.
Normal sollte der Client dann eine entsprechende v6 IP bekommen.
Die OPNsense Firmware ist in machen Teilen recht buggy und instabiler als ihre pfSense Schwester. Einen Fehler in der Firmware im v6 Verhalten an virtuellen VLAN Interfaces kann man also bei OPNsense nicht vollends ausschliessen. Ggf. solltest du dir alternativ einmal ein separates Flash besorgen und das mit einer pfSense Firmware testen. Hier in D rennt das an einem Telekom Dual Stack mit pfSense und einem VLAN Port mit 3 dort aufliegenden VLAN Interfaces völlig fehlerlos.

Hallo Aqui,

vielen Dank für die Rückmeldung. Werde so vorgehen. Mittlerweile denke ich auch, dass AP`s den Controller on board haben sollten. Hätte ich doch bloß auf diese wenigen Ausnahmen bezüglich Hardwareanforderung von euch (Unifi AP's, OPNsense) verzichtet ;)

Hallo Forum, hallo Aqui,

Am Unifi AP lag es nicht. Habe einen untagged Port am switch geschaltet und das Laptop dort eingestöpselt. Das Laptop bekommt dort auch keine IPv6 Adresse.

Habe mittlerweile PFsense auf meine Appliance aufgespielt. PFsense zeigt das gleiche Verhalten wie OPNsense. Clients am Interface igb1.2 (vlan 2) bekommen keine IPv6 Adresse. Habe auch die neueste development Version von PFsense aufgespielt (Wollte mir nebenbei auch den WireGuard Server anschauen) Bei dieser Version auch das gleiche Verhalten. Erstes physisches Interface funktioniert, vlan-Interface mit dem ersten physischen Interface als parent funktioniert nicht, ein zweites, physisches Interface funktioniert.

Wenn bei der Telekom alles flutscht, sollte es demzufolge am ISP hier liegen?! Oder habt ihr noch weitere Hinweise für mich. Übersehe ich noch etwas?

Danke und viele Grüße aus Griechenland.

Niko

Das Laptop bekommt dort auch keine IPv6 Adresse.

Das war zu erwarten, denn der AP arbeitet ja nur als einfache Layer 2 Bridge und hat mit dem IP Forwarding nichts zu tun. Dennoch aber ein wichtiger Test um da ggf. einen Fehler ausschliessen zu können.

Habe mittlerweile PFsense auf meine Appliance aufgespielt. PFsense zeigt das gleiche Verhalten wie OPNsense.

Sorry, ist hier nicht nachzuvollziehen. In einem Testaufbau funktioniert das hier absolut fehlerlos an einem Telekom Dual Stack VDSL Anschluss !
https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-tele ...
Entscheident ist hier die Prefix ID !!!
Diese muss für jedes lokale Interface (dazu zählen natürlich auch VLAN IP Interfaces !) einzigartig sein und musst du pro lokalem Interface hochzählen.
Sprich solltest du beispielsweise eine zusätzliche Netzwerkschnittstelle als VLAN 10, VLAN 20 usw. einsetzen, übernimmst bis auf die IPv6 Prefix ID alle Einstellungen für diese Interfaces genauso, außer bei der IPv6 Prefix ID wo du hochzählen musst: VLAN 10 ist dann IPv6 Prefix ID 1 , VLAN 20 dann IPv6 Prefix ID 2 etc..
Sehr wahrscheinlch hast du das nicht beachtet ?!
Das ist aber wichtig weil nur mit der unterschiedlichen ID die Firewall in der Lage ist den PD Pool entsprechend pro ID als /64er an die lokalen Interfaces zu vergeben.
Die IPv6 Konfig mit der pfSense an allen Dual Stack Anschlüssen klappt damit generell fehlerlos.

sollte es demzufolge am ISP hier liegen?!

Nein, ganz sicher nicht, denn die kochen auch nur mit normalem IPv6 Wasser wie es weltweit überall gleich ist. Wichtig und zwingend ist natürlich das dein Provider dir immer per Prefix Delegationen einen größeren Pool überträgt z.B. /56 usw.
Wenn die dir nur ein /64er übergeben kannst du genau ein einziges lokales v6 Segment betreiben. Aber wie du selber sagst ist das ja nicht der Fall.

Hi Aqui,

Danke für die Rückmeldung. Ja, es sollte funktionieren. Aber irgendwie tut es das nicht. Die Prefix ID für die jeweiligen Interfaces habe ich berücksichtigt.

Hier ein Screenshot der Interfaces aus dem Dashboard:

GST ist das vlan Interface mit "LAN" (physisch) als parent interface. MNG ist das zweite physische interface.

Ein Auszug aus dem DHCP-Log (gefiltert nach Prefix):

Ich nehme an, dass das Prefix ein /56 ist. Ich sage "ich nehme an" weil ich mir mittlerweile unsicher bin. Wenn es doch überall läuft, sollte es doch auch bei mir laufen. Irgendwo muss ich da doch etwas unberücksichtigt gelassen haben. Habe auch sämtliche Optionen ausprobiert. DHCPv6 Server enabled und disabled. Router advertisements assisted oder unmanaged -> kein Unterschied.

Noch eine Idee?

Danke nochmals!

Mmmhhh...das sieht doch aber alles sehr gut und richtig aus !!
Die lokalen Interfaces haben doch allesamt eine korrekt v6 IP bekommen und auch vom Log her sieht das alles sauber aus ?!
Normal müsste ein Endgerät doch in den lokalen Segmenten entweder per SLAAC oder DHCPv6 eine v6 IP bekommen. Unverständlich....

Da wirst du nicht umhinkommen einmal den Wireshark Sniffer auf deinem Test PC anzuschmeissen in einem der lokalen VLAN Segmente und dir den v6 Traffic mal anzusehen WAS da genau schiefläuft bei der Adressvergabe. In den Capture Filter gibst du dann ip6 an so das du nur IPv6 relevanten Traffic siehst.
Es wäre sehr hilfreich wenn du den Trace dann hier einmal posten könntest.
Welche Mechanismen da ablaufen bzw. ablaufen müssen erklärt dieses kostenlose Tutorial recht gut:
https://danrl.com/writing/ipv6-workshop/

Hallo Aqui,

vielen Dank für die Lektüre! Macht wohl am meisten Sinn, wenn ich mich jetzt in das Thema IPv6 einlese. Dann werde ich auch die Wireshark-logs besser deuten können.

Arbeite mich da durch. Dieses Thema hat meinen Ehrgeiz geweckt. Sobald ich mich mit den jeweiligen SSID's (lan und vlan) verbinde und das sniffen starte, kommen trotz "ip6" Filterung viele Zeilen zusammen. Momentan wüsste ich auch nicht, wie ich das hier im Forum am einfachsten posten könnte (Screenshot oder Codeblock). Brauche noch ein wenig Zeit, um auch das Tool Wireshark zu überblicken.

Also, Danke nochmals für die Hinweise!

Viele Grüße

verbinde und das sniffen starte, kommen trotz "ip6" Filterung viele Zeilen zusammen

IPv4 dürfte dann aber nicht kommen !
Oder du hast fälschlicherweise NICHT den Capture Filter aktiviert sondern nur den Anzeige Filter...ein Unterschied.
Hier findest du Hilfe und Anleitung:
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html

Aqui, Danke für die Anleitung!

Bin jetzt unter Ubuntu Linux auf dem Laptop.

Hier ein Mitschnitt des problematischen vlans. Mitschnitt direkt nach dem Verbinden mit der vlan-SSID. Hab etwas mehr als 1 Minute aufgezeichnet. Verglichen zu der lan-SSID passiert hier nicht viel. Siehst Du da was auf Anhieb? Für mich ist das hier noch eine "Fremdsprache"...

No. Time Source Destination Protocol Length Info
1 0.000000000 2a00:1450:400a:800::200a 2a02:587:6e25:f402:385:3b7b:757:1b45 TCP 94 443 → 43806 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 SACK_PERM=1 TSval=1924541654 TSecr=3124054667 WS=256
2 0.410173723 fe80::f12c:62b4:e3dc:e760 ff02::16 ICMPv6 110 Multicast Listener Report Message v2
3 0.414151898 fe80::f12c:62b4:e3dc:e760 ff02::2 ICMPv6 62 Router Solicitation
4 0.421858273 fe80::f12c:62b4:e3dc:e760 ff02::16 ICMPv6 110 Multicast Listener Report Message v2
5 0.452519578 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 205 Standard query response 0x0000 PTR, cache flush ni-notebook.local AAAA, cache flush fe80::f12c:62b4:e3dc:e760
6 0.632903152 fe80::f12c:62b4:e3dc:e760 ff02::1:ff42:e2ef ICMPv6 86 Neighbor Solicitation for fe80::4b46:245e:1142:e2ef from 48:f1:7f:64:e8:ad
7 0.661823930 fe80::f12c:62b4:e3dc:e760 ff02::16 ICMPv6 110 Multicast Listener Report Message v2
8 0.825921940 fe80::f12c:62b4:e3dc:e760 ff02::16 ICMPv6 110 Multicast Listener Report Message v2
9 1.607905493 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 124 Standard query 0x0000 PTR _nmea-0183._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question PTR _ipps._tcp.local, "QM" question
10 1.657938821 fe80::f12c:62b4:e3dc:e760 ff02::1:ff42:e2ef ICMPv6 86 Neighbor Solicitation for fe80::4b46:245e:1142:e2ef from 48:f1:7f:64:e8:ad
11 1.870381459 2a02:587:6e25:f402:20d:b9ff:fe57:115 2a02:587:6e25:f402:385:3b7b:757:1b45 ICMPv6 86 Neighbor Solicitation for 2a02:587:6e25:f402:385:3b7b:757:1b45 from 00:0d:b9:57:01:15
12 2.549407895 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 205 Standard query response 0x0000 PTR, cache flush ni-notebook.local AAAA, cache flush fe80::f12c:62b4:e3dc:e760
13 2.681917137 fe80::f12c:62b4:e3dc:e760 ff02::1:ff42:e2ef ICMPv6 86 Neighbor Solicitation for fe80::4b46:245e:1142:e2ef from 48:f1:7f:64:e8:ad
14 2.922174982 2a02:587:6e25:f402:20d:b9ff:fe57:115 2a02:587:6e25:f402:385:3b7b:757:1b45 ICMPv6 86 Neighbor Solicitation for 2a02:587:6e25:f402:385:3b7b:757:1b45 from 00:0d:b9:57:01:15
15 3.870350072 2a02:587:6e25:f402:20d:b9ff:fe57:115 2a02:587:6e25:f402:385:3b7b:757:1b45 ICMPv6 86 Neighbor Solicitation for 2a02:587:6e25:f402:385:3b7b:757:1b45 from 00:0d:b9:57:01:15
16 4.130899093 2a00:1450:400a:800::200a 2a02:587:6e25:f402:385:3b7b:757:1b45 TCP 94 [TCP Retransmission] 443 → 43806 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 SACK_PERM=1 TSval=1924545686 TSecr=3124054667 WS=256
17 4.220078035 fe80::f12c:62b4:e3dc:e760 ff02::2 ICMPv6 62 Router Solicitation
18 5.608632262 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 124 Standard query 0x0000 PTR _nmea-0183._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question PTR _ipps._tcp.local, "QM" question
19 8.220706686 fe80::f12c:62b4:e3dc:e760 ff02::2 ICMPv6 62 Router Solicitation
20 13.610875174 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 124 Standard query 0x0000 PTR _nmea-0183._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question PTR _ipps._tcp.local, "QM" question
21 29.612548568 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 124 Standard query 0x0000 PTR _nmea-0183._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question PTR _ipps._tcp.local, "QM" question
22 61.614327525 fe80::f12c:62b4:e3dc:e760 ff02::fb MDNS 124 Standard query 0x0000 PTR _nmea-0183._tcp.local, "QM" question PTR _ipp._tcp.local, "QM" question PTR _ipps._tcp.local, "QM" question

Es ist schwer das nur als ASCII Text zu erkennen, da man die Mac Adresse des Ubuntus nicht kennt.

Es passiert aber eine Neigbor Solicitation wie du sehen kannst 2a02:587:6e25:f402:385:3b7b:757:1b45 from 00:0d:b9:57:01:15.
Man müsste nur wissen ob dein Rechner die 00:0d:b9:57:01:15 als Mac Adresse hat.
Was sagt denn ein ifconfig auf der Ubuntu Kiste ?
Checke auf dem Ubuntu auch das dort sicher IPv6 aktiviert ist. In der Datei /etc/sysctl.conf sollten die 2 Zeilen:
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.all.disable_ipv6 = 0
entsprechend gesetzt sein.

Eine klassische Neigbor und Router Solicitation bei v6 sieht so aus:
1.) Cature Filter auf ip6 setzen das du nur IPv6 Traffic snifferst und v4 dir nicht den Wireshark "vollmüllt" !

2.) Hier siehst du die Neigbor Solicitation des Clients (ICMP Typ 135) und dananch gleich die Router Solicitation die der Router dann mit dem RA und Prefix des Global Unicast Netzes sowie DNS IPs beantwortet:

3.) Adressvergabe:

Hallo Aqui, danke für die Hinweise.

Habe jetzt noch ein paar Versuche gestartet. Ich habe ja eine funktionierende Schnittstelle SSID A, vlan1. Ich dachte, ich kann dann einfach die nicht funktionierende Schnittstelle SSID B, vlan2 mit der SSID A, vlan1 vergleichen. Hier ein Screenshot beider Schnittstellen. Oben vlan2, nicht OK. Unten vlan 1, funktioniert. Momentan sehe ich nur, dass oben viel mehr passieren müsste. Ich sehe kein DHCPv6 Protokoll und vieles mehr. Irgendwo hängt da die Kommunikation.

Nebenher mache ich noch Herrn Lüdkes's Workshop.

Hast du den DHCPv6 Haken am Interface gesetzt ?
PFsense IPv6 - Was mache ich falsch ?

Ja, Haken ist gesetzt. Bin die Einstellungen wirklich sehr oft durchgegangen, um sicherzustellen, dass ich da ja nichts verpennt hab. Die Interfaces -bis auf die IPv6 Prefix ID- sind alle gleich konfiguriert.

Ruf zur Sicherheit nochmal bei deiner technischen Provider Hotline an ob der auch wirklich physische /56er Pools per PD verteilt. Auch hier in D gibt es Provider die das vorgeben, tatsächlich aber nur ein /64 ausgeben.
Nicht das du dir einen Wolf probierst und es liegt doch am Provider. Kläre das also besser wasserdicht bevor wir hier weiter ins Detail gehen.
Kann ja eigentlich jetzt nur daran liegen, den du hast wirklich alles richtig gemacht bis dato.

Hallo Aqui, die Hotline hier ist ganz, ganz "schwierig". Ich dachte immer ich würde mich in der EU befinden, tatsächlich bin ich in Griechenlandistan. Selbst die frühere Deutsche Bundespost war ein Highflyer dagegen. Aber ich sollte hier nicht poltern...

Habe doch an meiner APU noch ein zweites physisches Interface. Das habe ich entsprechend konfiguriert und ein Laptop direkt an die Firewall angeschlossen. Da funktioniert IPv6 ebenso problemlos. Ich kann also gleichzeitig mindestens zwei /64 Netzweksegmente aufspannen. Nur dieses eine störrische vlan-interface.

Habe gestern Wireshark unter Windows 10 installiert und mal dort an der Wifi-Schnittstelle gelauscht. Bekomme hier "mehr" Informationen und vergleiche hier die Interfaces.

Hab ein Screenshot angehängt. Hier habe ich Tabellen nach DHCPv6 sortiert. Was mir als IPv6-Laie auffällt ist, dass sich bei der problematischen Schnittstelle (unten im Screenshot) die Zeile "Solicit XID" mehrfach wiederholt, während bei der funktionierenden Schnittstelle ein "Confirm und Reply" kommt. Fällt Dir da was auf?

Ich mache jetzt weiter mit Herrn Lüdkes Workshop. Ich denke, dass Deine Message klar war. Erstmal verstehen was man macht ;)

Viele Grüße

Nur dieses eine störrische vlan-interface.

Uuuhh böses Faul !
Könnte natürlich sein das das v6 Feature für virtuelle VLAN Interfaces einen Bug hat oder schlimmer noch nicht supportet ist auf virtuellen VLAN Interfaces und nur auf physischen Interfaces rennt.
Das müsstest du ggf. mal mit dem 2ten phyischen Port versuchen zu reproduzieren. Wenn die Verteilung des PD Pools über die ID nur auf dem Parent Interface bzw. dem physischen rennt und reproduzierbar nicht auf den virtuellen VLAN Interfaces, dann sieht das ein Fall für den pfSense Bug Report zumindestens aber einmal für einen Thread im (Englisch sprachigen) pfSense Forum um das zu klären.

und mal dort an der Wifi-Schnittstelle gelauscht. Bekomme hier "mehr" Informationen und vergleiche hier die Interfaces.

Was ist denn unterschiedlich in Bezug auf IPv6 an deinem WiFi und Kupfer Interface ?

dass sich bei der problematischen Schnittstelle (unten im Screenshot) die Zeile "Solicit XID" mehrfach wiederholt

Das ist richtig.
Das zeigt ganz klar das die "andere Seite" nicht antwortet ! Wenn du ein Layer 2 Problem sicher ausschliessen kannst (VLAN IP muss per Ping erreichbar sein !!) ist das einen Fehlfunktion.
Nur mal doof nachgefragt:
Das die virtuellen VLAN Interfaces alle natürlich Firewall üblich jeglichen Traffic im Default blockieren, musst du logischerweise dort natürlich eine entsprechende FW Regel pro VLAN Interface generieren die den lokalen Traffic sowohl für IPv4 als auch IPv6 erlaubt. Hast du das beachtet ?

Hallo Aqui, die Firewallregeln sind ok. IPv6 Traffic ist auf allen Interfaces erlaubt. Mittlerweile habe ich wieder OPNsense aufgespielt.

Unterschiede in Bezug auf Wifi und Kupfer gibt es bis auf die IPv6 Prefix ID nicht.

Habe im OPNsense Forum (allerdings das Deutsche) geschrieben. Habe da keine Antwort bekommen. Mich wundert es auch, dass ich fast nichts darüber finde im Netz. Nur diesen Eintrag:

https://forum.opnsense.org/index.php?topic=12305.0

Ping -6 auf die Schnittstellen IPv6 funktioniert. Alle Schnittstellen einschließlich vlan-Schnittstelle antworten. Werde nachher mal ins englische OPNsense Forum schreiben und doch mal die technische Cosmote-Hotline anrufen (auf die Gefahr hin, dass mir da wieder eine Frau Papadopoulos klar machen möchte, dass ich einen teuren Business-Tarif benötige.

Viele Grüße

Ping -6 auf die Schnittstellen IPv6 funktioniert. Alle Schnittstellen einschließlich vlan-Schnittstelle antworten.

Bekommst du denn die Schnittstellen IPs hier aus dem PD Pool oder hast du sie statisch nach eigenem Ermessen gesetzt ?
Wenn du sie über den PD Pool bekommst arbeitet ja alles so wie es soll was die Adressverteilung anbetrifft auf den lokalen Interfaces.
Der Rest ist dann nur eine Fehlfunktion von SLAAC oder DHCPv6.
Wenn die Distribuierung der lokalen Interface Adressen sauber funktioniert, kannst du mit dem Wireshark dann einmal die RA Broadcasts mitsniffern und dort die Status Bits aufklappen. Das wäre einmal interessant wie die gesetzt sind !
Nur nochmal zur Sicherheit nachgefragt: Die globalen IPv6 Settings hast du alle gemacht ??
https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html
Vielleicht hilft das noch:
https://blog.friedlandreas.net/2018/12/opnsense-ipv6-hinter-einer-fritzb ...
https://www.thomas-krenn.com/de/wiki/OPNsense_IPv6_deaktivieren
https://blog.veloc1ty.de/2019/05/26/pfsense-opnsense-ipv6-delegation-fri ...

Danke für die Links. Bin sie eben durchgegangen. Eine Sache habe ich nochmals ausprobiert, die ich in der opnsense-doc gesehen hab. Habe den Haken Allow DNS server list to be overridden by DHCP/PPP on WAN gesetzt. Und meinen PI-Hole als DNS Server wieder rausgenommen. Hat aber erwartungsgemäß nichts gebracht.

Die Interface IP sind nicht von mir gesetzt worden. Also, kommen aus dem PD-Pool.

Bei dem Problematischen vlan sehe ich beim sniffen leider kein Router Advertisement (Type 134). Soweit kommt es da nicht. Anscheindend ein Folgefehler. Aber Router Solicitation (Type 133) ist zu sehen. Hier ein Screenshot. Links die LAN Schnittstelle (die OK ist) Rechts die VLAN-Schnittstelle. Hier sehe ich nur ein paar andere Bits fürs "flow-label"

Bei dem Problematischen vlan sehe ich beim sniffen leider kein Router Advertisement (Type 134)

Obwohl dieses Interface eine gültige IPv6 Adresse aus dem PD Pool bezogen hat ??
Das ist dann ein Fehler, denn eine Router muss zwingend RAs senden damit die v6 Endgeräte den und auch den Netz Prefix erkennen.
Interessant wäre ob diese fehlenden RA Advertisements rein nur auf den (oder allen) virtuellen VLAN Interfaces fehlen oder generell ?
Du solltest also auf den physischen Interfaces bzw. den Parent Interfaces (untagged Physik) zu den VLAN Interfaces einmal checken ob dort die RAs kommen. Das wäre hilfreich.

Aber Router Solicitation (Type 133) ist zu sehen.

Die kommt ja immer von den Clients ! Darauf antwortet der Router dann mit einem RA.

Wenn die RAs nur auf den physischen Interfaces kommen und da die v6 Connectivity klappt, aber nicht auf den virtuellen VLAN Interfaces bei sonst gleicher Interface Konfig ist das wohl ein Bug oder eine Fehlkonfig.
Da es an einem Comcast IPv6 Netz fehlerfrei mit 16 VLAN Interfaces rennt:
https://blog.barclayhowe.com/16-ipv6-subnets-pfsense-and-comcast/
und das schon seit 3 Jahren muss man wohl doch eher von einer Fehlkonfig ausgehen.

Hallo Aqui, habe jetzt doch RA's gesehen auf dem vlan-Interface. Ich musste nur lange genug warten. Das RA kommt etwas spät, So lange hatte ich bisher nicht gewartet bei Sniffen. Hier wieder ein Screenshot angehängt. Links die funktionierende Schnittstelle (lan). Da kommt das RA bereits nach 0.1 Sekunden, während das RA beim vlan interface mit Parent LAN nach 6 Minuten kommt.

Locally administered address, this is not factory defalt sehe ich da. Wie ganz am Anfang erwähnt, bekomme ich auch auf Android mobil eine IPv6 Adresse und werde kurz darauf vom Wifi getrennt.

Ansonsten warte ich gerade auf einen Rückruf vom ISP. Ist eine kostenpflichtige (und nicht ohne die Kosten) Hotline des Providers. Bin mal echt gespannt. Werde berichten...

Hi Aqui, hallo Forum,

endlich habe ich das Problem gelöst. Bin auf die Lösung gestoßen, als ich das mit dem zweiten physikalischen Interface rumprobiert hab. Es liegt am captive portal. Ich hatte ein captive portal ans vlan-interface gebunden. Ohne captive-portal geht IPv6. Und im Netz bin damit nicht alleine. Hätte ich früher drauf kommen sollen...

https://forum.netgate.com/topic/149712/why-does-captive-portal-not-work- ...

Aqui, nochmals ein riesengroßes Dankeschön an Dich, dass Du mich unterstützt hast!

Viele Grüße

Niko

Es liegt am captive portal.

Ohh man.... Das hättest du aber auch gleich sagen können als uns hier so ins Messer laufen zu lassen !

https://forum.netgate.com/topic/134389/ipv6-with-captive-portal/2
Na ja...wenigstens hast du den bösen Buhmann nun identifiziert !
Beim nächsten Mal also vorher nachdenken um solche Fauxpas' zu vermeiden.