Messages

Ja, einen praktischen Unterschied sollte es nicht machen. Mich würde nur interessieren wo die Fehlinformation herkommt, dass man 192.168.100.1/24 eintragen muss / soll. Aus der Doku jedenfalls nicht.

This only works with the native backend and I'm not aware of a workaround.

Cheers
Maurice

Steht eigentlich alles in der Doku (https://docs.opnsense.org/manual/kea.html)...

1. Aktiviert das optionale REST API, wird z. B. für HA benötigt.
2. Du trägst in der Tat das Subnet ein, also z. B. 192.168.100.0/24. Wie kommst Du auf die Schnittstellen-Adresse?
3. 'Auto collect option data' deaktivieren, dann kannst Du das manuell eintragen.

Grüße
Maurice

1. Correct. Not every OPNsense update includes a new kernel + base.
2. Yes. These commits will be in a future version (26.1.3 or later).
3. Updating from 26.1.1 to 26.1.2 will not modify the installed kernel + base, so nothing to do.
4. Correct.
5. If an update includes a new kernel + base, there will be a src tag with the same version as the core tag (which determines the version used in the UI, release notes etc.). If an update doesn't include a new kernel + base, there's simply no new src tag.

Cheers
Maurice

A stable-privacy interface identifier (RFC 7217) is only stable as long as the prefix is stable, but then you wouldn't need dynamic DNS.
If your prefix is dynamic, you indeed have to use EUI-64 or a token (which most devices still do).

ISC DHCPv6 allows static mappings without an address range for dynamic leases. RA flags are configured independently (in radvd).
Kea does not (yet) support dynamic prefixes, so that's probably not an option.
Not sure about dnsmasq.

Please share your setup configuration with us :)

Just normal "bind service to loopback interface" stuff. :)

- Interfaces: Devices: Loopback, add two interfaces ('Loopback_Unbound', 'Loopback_BIND').
- Interfaces: Assignments, assign the interfaces and configure them with static /32 / /128 IP addresses (should not be within subnets used elsewhere).
- Services: Unbound DNS: General, set 'Network Interfaces' to 'Loopback_Unbound'.
- Services: BIND: Configuration, enter the IP addresses of 'Loopback_BIND' as 'Listen IPs' / 'Listen IPv6'.
- Now you can advertise the 'Loopback_Unbound' addresses to some clients and the 'Loopback_BIND' addresses to others, using a method of your choice (DNS servers setting in Kea / ISC / radvd / Dnsmasq).

Should work for any service which allows binding to specific interfaces or IP addresses. I do the same for e. g. the Web UI and downstream DNS-over-HTTPS (both on port 443).

Cheers
Maurice

You don't need DHCPv6 for that. SLAAC addresses are static, too. Devices may create temporary privacy addresses for outbound connections, but the primary SLAAC address uses a static interface identifier and is always available for inbound connections.

If your prefix changes, you can still use Dynamic DNS. The OPNsense DynDNS client allows combining a dynamic prefix with a static interface identifier.

Cheers
Maurice

Tough situation, but I'd really look into other options before considering the ISP's malicious DNS servers for anything.

- Using a less popular DNS over TLS server, which might not be blocked (there's more than Cloudflare / Google / Quad9).
- Using DNS over WireGuard (or other VPN).
- Running your own recursive resolver on a VPS and forwarding to it using DoT or a VPN.
- ...

But if you really want to forward dnsmasq to the ISP's DNS servers:
Bind dnsmasq to a dedicated loopback interface only (assuming that you don't use it for DHCP / RAs). Haven't tried that with dnsmasq and dnscrypt-proxy, but it works for me for running both Unbound and BIND on port 53 (but different IP addresses).

Is there a way to not have ISP's DHCP DNS in OPNsense's system DNS but still let DNSmasq forward to them?

- Make sure "System: Settings: General: Allow DNS server list to be overridden by DHCP/PPP on WAN" is disabled.
- In the general Dnsmasq settings, enable "Do not forward to system defined DNS servers".
- In Dnsmasq / Domains, create a global override and enter the IP address of the ISP's DNS server.

Cheers
Maurice

Have you tried Unbound with a DNS-over-TLS upstream? There shouldn't be a noticeable performance impact.

Since your ISP doesn't seem to be trustworthy, I would avoid using their DNS servers and plaintext DNS in general.

Cheers
Maurice

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.