Messages

Do I need the loopback step mentioned here under Interfaces->Devices->Loopback?

If you don't use NPTv6, you don't need it. But NPTv6 is the topic here...

As I explained, I want to use it, for when my ISP changes my prefix.

[Identify association]

I get a /48 from my ISP.
Right now I don't use NPTv6, but it seems handy if my ISP ever changes the prefix (it has been stable for over a year, but you never know).

I get the /48 via DHCPv6 (and the IPv4 via PPPoE) on my WAN interface.
My VLANS are set to "IPv6 Configuration Type" Identify association under Interfaces-[MYVLANNAME]
On the same page "Assign prefix ID" is set to a HEX-value for each VLAN, so every VLAN has a /64 each.

Do I need the loopback step mentioned here under Interfaces->Devices->Loopback?
It seems to me that has already been taken care of under Interfaces, isn't it?

Yes, I see now that if I change then old one to Automatic, the other is on Automatic too now.

Thanks!

[Mode]

I migrated my "Outbound NAT" to "Source NAT".
Seems to work.
Now manual Outbound NAT rules are empty, as is expected in the "old" interface.

Can I now put Mode back to "Automatic outbound NAT rule generation"? It was of course on "Hybrid outbound NAT rule generation"
Or are the new "Source NAT" manual rules not applied in that case?

It seems logical to put it back on Automatic, because in Source NAT, Mode  "Hybrid Source NAT rule generation is selected.

If you really want to, just do  "rmuser dhcpd" as root in a ssh session. It will remove the user and group. I did it, worke fine, no issues.

Hm... Strangly, after closing my browser (firefox) and starting it again the issue was resolved... Don't know what this was, strange indeed. We'll see if it happens again.

It noticed an annoying (probably cosmetic) issue in my installation after migrating to new rules, although it may have been present before the migration to the new rules. I have multiple Port Forward rules - Now called Destination NAT in 26.1. The screen with the rules is only 1.5 lines big, that is unusable. It is scrollable though. See screenshot. I also tries the light theme, but the issue is still there.

Migrated today and udpbroadcastrelay is happily starting here on my Protectli VP2420.

This is probably the bug: https://github.com/opnsense/core/issues/8838

Edit:

To tackle this:
You must Tick "Allow manual adjustment of DHCPv6 and Router Advertisements ", then Disable ISC DHCP6 for the interface. After that, you can enable Identity association.

[s]

With that option, you can but set one domain to be handled as local. Note the plural s in:

One problem could be DNSmasq still asking the upstream servers for local names for lack of having configured the "local" flag for your internal domains.

And you do not have to use DHCP for all of those zones - I use local domains for sites I reach via VPN and only have the DNS part configured for those.

The problem is that any domain that is not declared to be local one way or another and that is within your local DNS search list will be appended even to internet names by Windows and thus lead to DNS leaks and parallel queries.

Ah yes, I understand. Thanks. I was only talking about the one domain Unbound forwards to Dnsmasq, but of course there can be more situations.

[...]

One problem could be DNSmasq still asking the upstream servers for local names for lack of having configured the "local" flag for your internal domains.

[...]

If you checked "DHCP fqdn" under Dsnsmasq DNS & DHCP-General, checking "Local" on each and every host in "Hosts" should not be necessary accourding to the 3rd note here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

DHCP fqdn will do two things:

    Make sure all devices are registered in DNS with the configured domain name appended, e.g. smartphone.lan.internal. This ensures that smartphone can exist in both lan.internal and guest.internal.

    Register the DHCP domain name as local, which will make Dnsmasq authoritative for this domain, ensuring NXDOMAIN is returned for devices querying unknown hostnames within this local domain.

This is how I understood this. Correct me if I'm wrong.

Yes! Use both. Unbound as main DNS server and Dnsmasq for DHCP and internal DNS. Unbound asks Dnsmasq (which is running on a different port) for local domains in this scenario, works with a real domain too, have the same setup. Guide here: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration

Note1: To make local dns resolution work for static IP's even when a client hasn't had contact with the DHCP server: you have to fill in both a Host and a Domain under Dnsmasq DNS & DHCP-Hosts

Note2: Do not forget to Check Do not forward to system defined DNS servers under Dnsmasq DNS & DHCP-General (it's in the guide too).

Hmm, I thought FQDN would resolve all of the IPs but it looks like it doesn't pick up IPv6 auto-generated addresses, at least in my current setup with Kea+Unbound.

MAC aliases seem reliable, though.

It works with MAC in aliases. Then it will track IPv6 too.

I have setup Unbound with forwarding for my local domain to Dnsmasq per the docs: https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration
I have DNSSEC enabled in Unbound.

I noticed there is also a DNSSEC switch in the settings of Dnsmasq. If I switch this on, everything works the same as switched off. Is there any advantage or disadvantage switching this on in Dnsmasq? It seems useless to me, since it is for local lookups only... does it even do anything in this scenario?

Yes, thank you, all clear now. The ISC part will be removed from the docs, see this PR, already merged: https://github.com/opnsense/docs/pull/744