Dnsmasq help: how to suppress the OPNsense iface GUA in DHCPv6 options?

Started by OPNenthu, Today at 11:08:46 AM

Previous topic - Next topic
I'm trying an experiment to assign both GUA and ULA ranges in Dnsmasq, but to logically separate them with DHCP tags.  The idea is to let clients auto-configure IPs on both ranges, one for stable internal IPv6 networking, and one for internet access.  Since I have a dynamic ISP prefix, I want to exclude any DNS assignment on the GUA range and offer only a ULA address for Unbound in Dnsmasq RAs (RDNSS).

As per the Dnsmasq manual, we should be able to override the default option which sets the OPNsense interface address as the DNS by setting the option with an empty value:

Quote-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<enterprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|option6:<opt>|option6:<opt-name>],[<value>[,<value>]]
...
An option without data is valid, and includes just the option without data. (There is only one option with a zero length data field currently defined for DHCPv4, 80:rapid commit, so this feature is not very useful in practice). Options for which dnsmasq normally provides default values can be omitted by defining the option with no data. These are netmask, broadcast, router, DNS server, domainname and hostname. Thus, for DHCPv4 --dhcp-option = option:router will result in no router option being sent, rather than the default of the host on which dnsmasq is running. For DHCPv6, the same is true of the options DNS server and refresh time.

So I tried this-

On each of my VLANs I used a tagged 'xGUA' range with the interface constructor (constructor=LAN) and a second tagged 'xULA' range with the ULA that I defined in VIP configs (constructor=None).

Then in DHCP options I offered the OPNsense ULA address as the DNS on the 'xULA' range and I overrode the DNS with a blank value for the 'xGUA' range, as the manual says I can do.

You cannot view this attachment.

You cannot view this attachment.


What works:

- The SLAAC addressing is fine.  Clients are configuring themselves with IPs on both ranges.

What fails:

- Clients are still getting the OPNsense GUA interface address as the IPv6 DNS.

$ ip a
...
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether <redacted> brd ff:ff:ff:ff:ff:ff
    inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute enp6s0
       valid_lft 86248sec preferred_lft 86248sec
    inet6 fd7b:1236:9970:1003:e717:cc84:66e1:d8f3/64 scope global temporary dynamic
       valid_lft 86357sec preferred_lft 85901sec
    inet6 fd7b:1236:9970:1003:44df:603e:214c:824f/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86357sec preferred_lft 86357sec
    inet6 26xx:xx:xxxx:3163:a54b:860e:9bf9:3109/64 scope global temporary dynamic
       valid_lft 86357sec preferred_lft 85901sec
    inet6 26xx:xx:xxxx:3163:xxxx:xxxx:xxxx:xxx/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86357sec preferred_lft 86357sec
    inet6 fe80::xxxx:xxxx:xxx:xxxx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

$ resolvectl status
Current DNS Server: 172.21.30.1
       DNS Servers: 172.21.30.1 26xx:xx:xxxx:3163::1
        DNS Domain: clear.h1.internal

I expected to see an fd7b:...::1 address here ^.

Anybody know what I missed?
N5105 | 8/250GB | 4xi226-V | Community

https://www.youtube.com/watch?v=XI9NG068TwI