Messages

@OPNenthu
Interesting approach. But I'm pretty sure an NPT rule for a prefix which includes the WAN address will make services which run on OPNsense itself (like Wireguard) unreachable.

As OPNenthu explained in post #2, this is experimental and not meant for production, except for some very niche use cases. Using only ULAs has too many side effects.

These days, dynamic prefixes work reasonably well. If you need to configure something statically and manual renumbering (if your prefix ever changes) isn't acceptable: Use ULAs in addition to GUAs.

Even if you want to go the NPT way: The loopback workaround is meant for frequently changing prefixes. With a prefix that's stable for more than a year, using a static NPT rule and updating it manually if the prefix ever changes makes more sense.

Cheers
Maurice

As far as I'm aware, all official FreeBSD 15.1 VM images (as well as images available at public cloud providers) use a packaged base system. You'd have to perform a manual installation to still get the traditional distribution sets.

But thanks for the explanation, I'll update my documentation accordingly. You might want to do the same for the opnsense/update readme as well as the opnsense-bootstrap man page.

Cheers
Maurice

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.