Messages

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.

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.