I think I have found a bug in ISC dhcpv6 network definitions.

[ivarh]

I am running a opnsense 25.7.7_4-amd64 in a proxmox vm. I am using vlans to set up a DMZ and 2 internal lans where one is a normal assisted ipv6 network and the other network is a managed ipv6 network. The reason I need a managed ipv6 network is that windows seems to have a bug in it's ipv6 stack where slaac addresses seems to blead through vlans so by placing them on the managed network that is not on vlan1  resolves them getting a slaac address from the dmz and main vlan.

all these network are /64 networks carved out from a static /48 ipv6 network my ISP have assigned to me.

The bug is that when opnsense generates the /var/dhcp/etc/dhcpv6.conf file it does not use the netmask of the network but instead removes 0 nibbles from the end of the network address until it reaches a non zero nibble and uses that netmask to send ddns updates to the nameserver. Since the nameserver is set up with reverse mapping zones that match the network's defined netmask /64 and not the /56 the config generatore selects for one of the 3 networks the updates fail since there is no zone for the /56 network.

Code Select Expand

For subnet6 XXXX:XXXX:XX2c:200::/64, OPNsense/ISC DHCP generates (the wrong) subnet:
zone 2.0.c.2.X.X.X.X.X.X.X.X.X.X.ip6.arpa. { ... }

for other nets like XXXX:XXXX:XX2c:4::/64 it generates (the correct) subnet
zone 4.0.0.0.c.2.X.X.X.X.X.X.X.X.X.X.ip6.arpa. { ... }


Changing XXXX:XXXX:XX2c:200::/64 → XXXX:XXXX:XX2c:201::/64 changes the reverse zone to:
zone 1.0.2.0.c.2.X.X.X.X.X.X.X.X.X.X.ip6.arpa. { ... }

When configuring DHCPv6 with subnet XXXX:XXXX:XX2c:200::/64, OPNsense generates a zone 2.0.c.2.5...ip6.arpa. stanza for DDNS, which corresponds to a /56 and appears to be derived by chopping trailing zero nibbles from 0200. Other subnets like :4::/64 and :201::/64 generate the expected /64-style reverse zones (4.0.0.0... and 1.0.2.0... respectively). This causes DNS NOTAUTH errors unless the reverse zone is created as /56. Expected: use a consistent /64 reverse zone name that matches the configured subnet mask.


The fix for this bug would be to not trying to detect the netmask based on the network ip address but to use the configured netmask instead to generate the reverse mapping zone to update.