Messages

Durgesh,

Thanks for the heads up. To be honest, I didn't test the bootstrap method with 15.1 / 26.7. And it seems possible no-one has, because it doesn't work on amd64 either - at least in my quick test with an amd64 VM (FreeBSD-15.1-RELEASE-amd64-BASIC-CLOUDINIT-ufs). So apparently not an issue specific to my builds.

You may want to open an issue on https://github.com/opnsense/update.

For now, I'll remove the bootstrap instructions. Since you're using virtualization, you can use a 26.7 VM image. No need to bootstrap from FreeBSD.

OPNsense 26.7 aarch64 packages, sets and sample VM images released.

https://opnsense-update.walker.earth/FreeBSD:15:aarch64/26.7/

https://github.com/maurice-w/opnsense-vm-images/releases/tag/26.7

@patient0
Thanks for trying to help, seriously!
But in this case, I fear it's pointless.

@rusli
Oh, you're the one who spammed random GitHub repos with rude, out of scope complaints in 2024. I remember. And now you're doing it again.

Congratulations, you just made it to my block list.

OPNsense 26.1.11 aarch64 packages and sets were released on 2026-07-02.

Hotfix 26.1.11_6 was released today.

[Update 2026-07-16]
Hotfix 26.1.11_10 released.

The fingerprints were moved to GitHub, they're in my fork of opnsense/core:
https://github.com/maurice-w/opnsense-core/tree/stable/25.7/src/etc/pkg/fingerprints/OPNsense/trusted

OPNsense 26.1.10 aarch64 packages and sets released.

OPNsense 26.1.9 aarch64 packages and sets released.

OPNsense 26.1.8 aarch64 packages and sets released. Includes hotfix 26.1.8_5.

"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