Messages

You're using the DHCPv6 to delegate a prefix? ULA or GUA? 

I was using DHCPv6 to give out ULA prefixes and since its a track interface clients use DHCPv6 to get GUA addresses.  I had some issues with the lease table being empty though it seemed to work.  ...but when OPNSENSE would reboot or a switch sometimes the apple Tvs would change prefixs and not agree and matter/thread would not be happy.  Letting them just dynamically create their own backend ULA prefix works well.

If your delegating ULA prefixes are you seeing lease table problems in the GUI or anything off in the logs? Is the interface you are using a GUA or track wan or ULA?

The setting didn't actually allow the processing of announcements for NDP per RFC 4191 on internal networks behind the router though. It only allowed the processing of it's own NDP annoucements from interface lo0 via ix0. This is an issue for the support and usage of IPv6 in the product.  I assume nearly everyone with Apple, Google, Amazon, or really any vendors home hubs for Matter/Thread is affected and just doesn't know it because reach-ability isn't an issue in their use case yet. It would become a bigger issue for those with interfaces in multiple internal networks as you wont be able to add the dynamic IPv6 routes and cross the L3 boundary. 

I tested "ifconfig ix0 inet6 accept_rtadv". After some time my IPv6 default route changed from the fe80::21c:xxxx:xxxx:xx%igc0 (ISP WAN gateway) on igc0 (WAN) to fe80::2f0:xxxx:xxxx:xxxx%ix0, which is the LL of OPNSENSE LAN interface itself.  This broke IPv6.
It also added one route to the IPv6 route table:
fd11:yyyy::xxxx:xxxx:xxxx:xxxx          link#6                        UHS         lo0

fd11:yyyy::1/64 being an OPNSENSE VIP on LAN (ix0), and xxxx:xxxx:xxxx:xxxx being the same mac/duid or suffix of the ix0 LL fe80.

So it looks like it added itself, but still ignored ix0 LAN ND messages from border routers.

Any workarounds?  Is this a bug I should report, or something FreeBSD won't be able to handle, or something else?

OPNSENSE seems to ignore any other RAs on my LAN and won't add routes.

OPNSENSE is running IPv6 RA on LAN interface for track GUA, but I also have other IPv6 RAs on the L2 LAN vlan for thread/matter that border dynamic ULA networks.  Pings to ULA devices behind the border routers, from OPNSENSE itself, try to go out WAN.  GUA Clients (windows/linux/macOS) on the L2 LAN vlan find those advertised ULA routes and can ping ULA devices behind those border routers because they see the RAs and update their route tables. Does something have to be enabled to allow OPNSENSE to accept IPv6 router advertisements on it's LAN interface for other internal IPv6 networks beyond the L2 vlan it is directly connected to?

I found this information online in regards to IPv6 route distribution:  The announcements are sent using the standard IPv6 Neighbor Discovery Protocol (NDP, or often ndisc) via RFC 4191 Route Information Option (RIO).

It may have something to do with net.inet6.ip6.no_radr, net.inet6.ip6.rfc6204w3, or something like ipv6_cpe_wanif, but I played with changing all those values and it didn't seem to change anything.  radvdump shows the router seeing the advertisement on the LAN interface:

radvd configuration generated by radvdump 2.19
based on Router Advertisement from fe80::49e:xxxx:xxxx:xxxx
received by interface ix0
interface ix0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 0;
        AdvDefaultLifetime 0;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;

        route fd4c:43e9:xxxx::/64
        {
                AdvRoutePreference medium;
                AdvRouteLifetime 1800;
        }; # End of route definition

}; # End of interface definition

...However it does not get added to the ipv6 FreeBSD route table like all the other ipv6 hosts on the L2 vlan.  Static routes aren't an option as these ULA networks can dynamically change and are not directly under my control.  Maybe I could force this by running an IPv6 routing protocol like OSPFv3 or BGP on my switches, but that's a poor workaround and not something I want to maintain when ND should be working.

Maybe I'm missing something simple? Any ideas???

If you moved the blocks what are you IPv6 and IPv4 responses for those names?  is it NXDOMAIN or 0.0.0.0 or ::?

I've been using:

server:
    local-zone: "doh.dns.apple.com." always_nxdomain
    local-zone: "use-application-dns.net." always_nxdomain
    local-zone: "mask.icloud.com." always_nxdomain
    local-zone: "mask-h2.icloud.com." always_nxdomain
    local-zone: "mask-api.icloud.com." always_nxdomain

Idle battery drain seems to be high on iphone and ipad.  I can verify with dig that I do get NXDOMAIN for these domains for clients on my network.

When you say the blacklist UI, are you saying you put them in the field "Services: Unbound DNS: Blocklist: Blocklist Domains"?

Will this cause any MAC address flapping, multicast, or arp table problems? Two separate physical interfaces. 

LAN (igb1) is assigned a ULA and DHCPv6 issues static reservations to clients.  It also has the IPv4 and DHCPv4.
LAN2 (igb2) is assigned to track interface WAN and uses RA with SLAAC.

Clients get ULAs, GUAs, and generate those privacy temporary GUA addresses and everything seems to work well.  The firewall does sees the same mac addresses out both LAN,LAN2 ports for the same clients with the ULAs being on LAN and GUAs on LAN2.  Any sort of problem or potential problem with this?

I originally tried a VIP, but VIP cant track WAN for RA SLAAC, and if I put ULA on VIP then DHCPv6 has to be used for GUA and my ULA become SLAAC.