Messages

OPNsense 26.7.2 aarch64 packages and sets released. Includes base / kernel 26.7.2_4, core 26.7.2_2 and hostapd 2.12_2.

If you don't want OPNsense itself to use NAT64, then you need to configure a DNS server without DNS64 in System / Settings/ General.

Did you enable DNS64? Then it's expected behavior. IPv6 is generally preferred over IPv4 and it doesn't matter whether the destination address is a "native" IPv6 address or an address synthesized by DNS64.

Cheers
Maurice

Privacy Extensions (RFC 4941) und Stable Privacy (RFC 7217) sind unterschiedliche Mechanismen.

Privacy Extensions spielen hier in der Tat keine Rolle, da diese nur zusätzliche Adressen für Outbound-Verbindungen erzeugen.

Stable Privacy ändert hingegen den Interface Identifier selbst, wenn sich das Präfix ändert. Das betrifft dann auch Inbound-Verbindungen und ist inkompatibel zu dieser DynDNS-Methode.

Ob Stable Privacy verwendet wird musst Du auf dem Wordpress-Server nachschauen (und dort auch ggfs. deaktivieren). OPNsense hat darauf keinen Einfluss.

Das funktioniert auch mit SLAAC, da sich der Interface Identifier im Normalfall nicht ändert (Ausnahme: Stable Privacy / RFC 7217).

Das Präfix wird nicht vom WAN-Interface übernommen, sondern von dem LAN-Interface, an dem der Server hängt.

Und ja, das funktioniert mit dem normalen os-ddclient.

You can create an NPT rule for a single /64 using the loopback method as well. That's not unique to the WAN tracking method.

And you can create an NPT rule for a shorter prefix using the WAN tracking method as well, in which case it's up to the user to avoid any collisions. That's not unique to the loopback method.

But I get what Franco said: Someone wanted that feature and now it's there. Nothing wrong with having options.

OPNsense 26.7.1 aarch64 packages and sets released. Includes hotfix 26.7.1_1.

Not sure. It seems to me that dedicated loopback interfaces are still the best option to get dynamic prefixes into NPT rules.
Maybe the person who requested using the WAN interface instead was not aware of this existing solution?

@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.