Messages

Code Select Expand

Internet Protocol Version 6, Src: 2a02:8010::188, Dst: fe80::62be:b4ff:fe1e:1640

The source address of the Neighbor Solicitation (2a02:8010::188) is likely not on-link, hence not considered a neighbor and ignored by FreeBSD.
That's something your ISP could fix, or you can keep using the tunable.

Cheers
Maurice

[os-]

The os-ddclient plugin supports both its own native backend as wells as the legacy ddclient. The os-ddclient plugin is not going away, only the ddclient backend might at some point.

So the way to go is using os-ddclient and selecting the native backend. If your provider is not yet listed as a supported service, you can create your own configuration using the 'custom' service.

Cheers
Maurice

OPNsense 26.1.2 aarch64 packages and sets released.

Why do you delegate ULA prefixes? You can't use ULAs for Internet access.

Simply configure KEA with GUAs based on the static prefix you get from your ISP.

@OPNenthu
No ISP should delegate less than a /56, even for the cheapest consumer plan. If you use one /57 for numbering the LANs and the other /57 for PD, 128 devices can request their very own /64 (or 64x /63, 32x /62, ...). Should be fine for a home network.

A single /60 is just nasty and a reason to complain. I once was with an ISP who only delegated a /59, but they eventually switched to /56, adopting the de-facto industry standard.

@Monviech
Well, the deployment reality on the router / firewall side is that OpenWrt, AVM, MikroTik and many others support downstream PD with a dynamic upstream. OPNsense is rather the exception. (Yes, ISC kind of supports it, but only with tricks, and it's EOL.)

The P flag in RAs is rather new, but trivial to implement on the server side. OpenWrt (odhcpd) supports it in 25.12 and there is an open pull request for radvd.

ndp-proxy-go is a great piece of software! But I don't see it as a replacement for prefix delegation, just like a traditional ARP proxy is not a replacement for proper IPv4 routing.

@GerhardHeus
No one mentioned ULAs. If you want to use DHCPv6-PD, you can simply configure KEA with a static GUA prefix. If your ISP provides you with fixed prefix 2001:db8:abcd::/48, you can e. g. use 2001:db8:abcd:ff00::/56 for KEA's PD pool. This allows it to delegate e. g. 16x /60.

Migrated the firewall rules on my main system yesterday. I was naughty and didn't perform step 2 (left the anti-lockout rule disabled).
Also, manually created new source NAT rules and disabled legacy outbound NAT entirely.

No issues so far!

Cheers
Maurice

Dynamic prefixes are not designed to be used at more hops than the exact edge between the "real" ISP and the "real" customer.

That's the only point where I'd disagree. DHCPv6-PD is absolutely designed to work over multiple hierarchy levels. And it's further gaining importance with recent developments like RFC 9762 (P flag in RAs) and Android now starting to prefer DHCPv6-PD over SLAAC.

Cheers
Maurice

I'm curious where the configuration/direction for OPNSense's firewall to resolve hosts comes from - which DNS source of truth is it using?

Should be whatever is configured in System: Settings: General.

Cheers
Maurice

Alternativ an ein zusätzliches Loopback-Interface binden. Das kann nützlich oder sogar erforderlich sein, wenn man mehrere Dienste auf dem selben Port benötigt - das geht mit ::0 / 0.0.0.0 nicht.

Grüße
Maurice

2000::1:1/64 and 2000::2:1/64 is the same network - 2000::/64. You shouldn't have the same network on two interfaces.

Cheers
Maurice

Not all clients / servers / relays properly support Rapid Commit. And it has disadvantages if there are multiple DHCPv6 servers on a network.
Other than that, if it works, it's a little more efficient than the full four message handshake.

Under System->Settings->General I have "Allow DNS server list to be overridden by DHCP/PPP on WAN" unticked.  In that case, does this WAN setting have any effect?

The technical difference is that DNS servers are either request via DHCPv6 but then ignored by OPNsense, or they are not requested at all. There are probably very few use cases where this really makes a difference.

Not a lot to document about Rapid Commit since this is nothing OPNsense-specific, but a standard DHCPv6 feature. Whether you can use it depends on whether the upstream DHCPv6 server supports it.

Both settings are probably most relevant when dealing with very picky DHCPv6 servers.

It's a brave new world since https://github.com/opnsense/dhcp6c/commit/369b4dcf ;)

Indeed, optional prefix ID / interface ID for WAN interfaces has proven to be very useful for some uses cases.

OPNsense 26.1.1 aarch64 packages and sets released.

[Update 2026-02-08]
Updated upgrade paths from 25.7. Upgrading from 25.7.11_9 will now skip 26.1 and install 26.1.1 directly.

@franco Sneaky! ^^