Messages

"Request prefix only" ist eine Einstellung des DHCPv6-Clients und nicht PPP-spezifisch. Es geht nur darum, ob der dhcp6c auch IA_NA anfragt.
Bei der Telekom ist es völlig egal, ob man diese Option setzt oder nicht, denn per DHCPv6 bekommt man dort ausschließlich ein Präfix (IA_PD), keine Adresse (IA_NA). Für die Konfiguration der WAN-Adresse wird dort wie gesagt SLAAC verwendet.

Deine Analyse scheint dann mein Bauchgefühl zu bestätigen: Bei SLAAC auf PPP-Interfaces ist die für EUI-64 verwendete MAC-Adresse mehr oder weniger zufällig und OPNsense kann daran auch nichts ändern. Das ist natürlich unschön.

mpd5 kümmert sich nur um IPv6CP, nicht um DHCPv6 und Router Solicitation / SLAAC. Das läuft ganz normal über dhcp6c und rtsold.

OPNsense 26.1.7 aarch64 packages and sets released. Includes hotfix 26.1.7_2.

[Update 2026-05-08]
Hotfix 26.1.7_3 released.

Ich bin mir nicht ganz sicher warum auf dem WAN Interface überhaupt eine GUA auftaucht. In der Konfiguration steht doch "nur Präfix anfordern".

Die Konfiguration bezieht sich nur auf DHCPv6. Die RAs der Telekom enthalten aber zusätzlich ein /64 mit A-Flag, weshalb das WAN-Interface eine per SLAAC autokonfigurierte Adresse bekommt. Das ist völlig unabhängig von DHCPv6. Es gibt in OPNsense leider keine einfache Möglichkeit, SLAAC zu deaktivieren.

Sollte das dann nicht an das zugrundeliegende Interface gekoppelt sein, oder zumindest statisch bleiben?

Das wäre aus User-Sicht sicherlich sinnvoll. Wie genau SLAAC auf PPP-Interfaces in FreeBSD / OPNsense implementiert ist habe ich gerade nicht im Kopf. Ggfs. ein Issue auf GitHub aufmachen.

Nein, das manuelle setzen der Schnittstellen-ID hat leider nicht funktioniert. Es wird immer wieder die EUI-64 verwendet. Nach wie vor vom falschen Interface.

Dann bezieht sich das nur auf Track Interface bzw. Interface Association und nicht auf SLAAC. Eigentlich auch logisch. SLAAC passiert soweit ich mich erinnere im Kernel, da hat OPNsense wahrscheinlich wenig Einfluss drauf.

2601:xx:xxxx:3168::/64 is on-link on the loopback interface, which effectively blackholes this prefix when trying to connect to it from interfaces other than the WAN. It's a side effect of the loopback workaround.

For eight /64 ULA subnets, you'll need a /61 NPT rule. That's half of the /60 you get from your ISP, so not a problem.

Loopback interface prefix ID: 8
NPT internal IPv6 prefix: fd5a:xxxx:xxxx:1000::/61

This translates ULA prefixes fd5a:xxxx:xxxx:1000::/64 .. fd5a:xxxx:xxxx:1007::/64 to GUA prefixes with IDs 8 .. f.
GUA prefixes with IDs 0 .. 7 remain available for other purposes.

Cheers
Maurice

I use a very similar setup for special use cases and yes, this works just fine (with all the known limitations of ULAs of course).

What seems special about your setup is that you translate multiple /64 ULA subnets to the same /64 GUA subnet. While this may or may not work for outbound connections, it can't work for inbound connections since there is no way to determine which internal prefix to translate to. You need a true 1:1 mapping for this.

I instead use a single NPT rule for a larger subnet, for example:

Loopback interface prefix ID: 0x10
NPT internal IPv6 prefix: fd01:2345:6789:1000::/60

So you only need a single NPT rule for 16 LAN interfaces (fd01:2345:6789:1000::/64 ... fd01:2345:6789:100f::/64).

This assumes you get a /56 PD from your ISP, but of course you can adapt this to any PD size.

Cheers
Maurice

Das wird an PPPoE liegen. Die WAN-Adresse wird ja nicht an igb0_vlan7 gebunden, sondern an pppoe0. Und ein PPP-Interface hat keine MAC-Adresse. Welche MAC-Adresse dann für EUI-64 verwendet wird scheint mehr oder weniger random zu sein.

Gib in der DHCPv6-Clientkonfiguration einfach eine "optionale Schnittstellen-ID" ein, dann wird diese verwendet (statt EUI-64).

[edit]
Bin mir gerade nicht mehr sicher, ob die optionale Schnittstellen-ID auch für SLAAC funktioniert (was hier auf dem WAN-Interface verwendet wird) oder nur für Interface Association / Track Interface. Ausprobieren.
[/edit]

Grüße
Maurice

So I'm not sure I gain any separation by using a dedicated loopback interface for redirects over just assigning a ULA VIP to the normal loopback.

Additional loopback interfaces are useful for running multiple services on the same port, but on different IP addresses. Some services only allow you to specify the interface they bind to, but not a specific IP address. So you need one interface per service / IP address.

If you just need additional IP addresses (e. g. as NAT redirect targets), I see no benefit in additional loopbacks and would indeed use VIPs.

Cheers
Maurice

Was meinst Du mit "Interface eintragen"?

Services: Router Advertisements
Falls es dort einen Eintrag für das FRITZBOXWAN-Interface gibt, diesen löschen.

Falls nicht, dann:
Interfaces: [FRITZBOXWAN]
IPv6 Configuration Type auf Static IPv6 stellen (und eine Dummy-Adresse eintragen, z. B. 2001:db8::1/64).
Nun wieder zu Services: Router Advertisements und den Eintrag für das FRITZBOXWAN-Interface löschen.
Wenn Du schon dabei bist: Prüfen, dass weder Kea noch ISC noch Dnsmasq auf dem FRITZBOXWAN-Interface aktiv sind.

Abschließend das FRITZBOXWAN-Interface wieder auf DHCPv6 umstellen.

Eventuell wurde opt10 / vtnet4 früher mal anderweitig verwendet und bei der Umwidmung zum WAN-Interface wurde dann radvd (und ggfs. weitere Dienste) nicht korrekt deaktiviert. Und rtsold + radvd auf dem selben Interface geht quasi zwangsläufig schief.

Grüße
Maurice

Auf dem WAN-Interface darf definitiv kein radvd laufen, da ist irgendwann etwas mit der Konfiguration durcheinander gekommen.

Stelle das WAN-Interface mal vorübergehend auf Static IPv6, dann kannst Du die Router Advertisements deaktivieren. Anschließend wieder auf DHCPv6 umstellen.

Alternativ die config.xml manuell bearbeiten.

Grüße
Maurice

Looks like you may have somehow managed to enable radvd on your WAN interface? This should be mutually exclusive - you can either run rtsold (on WAN-type interfaces) or radvd (on LAN-type interfaces), but never both. Check your config.xml as well as /var/etc/radvd.conf.

Cheers
Maurice

[edit] Sorry, bin mit den Sprachen durcheinander gekommen. Ich sollte um die Zeit vielleicht nicht mehr posten. 🥱[/edit]

ich vermute, ich bekomme kein Prefix von der FritzBox

Der Vermutung kannst Du nachgehen, indem Du das Log von dhcp6c anschaust (System: Log Files: General, ggfs. Debug-Logging in Interfaces: Settings aktivieren).

Grüße
Maurice

OPNsense 26.1.6 aarch64 packages and sets released.

[Update 2026-04-28]
Hotfix 26.1.6_2 released.

Consumer routers don't let you create an arbitrary number of subnets or manually configure subnet IDs at all. If all you have is one LAN and maybe a guest network, it's easy to handle a dynamic PD size. Just use subnet ID 0 for the LAN and 1 for the guest network. If you only get a /64, disable IPv6 for the guest network (or enable an NDP proxy).

We shouldn't do that level of automation in OPNsense. But the current workflow isn't ideal either. Many ISPs don't document their PD size. So you have to go to Interfaces / Overview, click the WAN interface's magnifying glass, scroll down to "Dynamic IPv6 prefix received" and then configure the PD size displayed there in the WAN interface's DHCPv6 client settings.

Franco, I think we once discussed the idea of a big fat warning somewhere in the GUI when the configured PD size doesn't match the actual PD size. I still think that would be a good idea.

Or maybe go one step further and actually change the config based on the actual PD size (optionally of course)?

Cheers
Maurice

In my mind, this should be determined from the DHCP response, so I shouldn't have to configure it statically.

A good idea in theory (and some / most consumer routers do that), but for more advanced setups you really need to know the PD size in advance. For example, when configuring the subnet IDs of your LANs, you need to know how many bits are available. Let's say you configure a subnet ID 0x10 but then only get a /60... Things will break.

Cheers
Maurice