Pihole with MAC filtering of devices based on DHCP

I am administrator of a Ubuntu 20.04 LTE server (latest updates installed) that already runs PiHole (v 5.3.1/FTL v. 5.8.1), using the PiHole both as DHCP server and web filter for a network with up to 1200 devices connected to Wifi, the server is attached to a router but the internet traffic is not directed through the server.

This is working pretty good so far.

Now we want to have the DHCP addresses split into two disjunct ranges, depending on the MAC addresses but using one PiHole instance only. We run a lot of same models of devices that use the same Wifi manufacturer chips and thereby having a range of "same" MAC addresses, say A:B:C:D:: with the last two bytes being wildcards. And there are other devices which should be allowed in the net as well, as "guests", i.e. their MAC addresses are not known to us in advance.

The real IP addresses etc. are different, but consider following smaller setup

Gateway is working (but not important for the issue)
NIC address: 10.20.0.10
DHCP range 10.20.0.11 to 10.20.0.200 for the devices

We thought about using a custom dnsmasq configuration file placed in /etc/dnsmasq.d, say 99-custom-dhcp.conf with following rules (A:B:C:D will be replaced by the real bytes of the MAC addresses)

/* This is meant for all other devices that do not match the MAC address range below */
dhcp-range=tag:secondaryRange,10.20.0.11,10.20.0.99,255.255.0.0,8h

/* Now the devices with known MAC address range */

dhcp-host=A:B:C:D:*:*,set:primaryRange
dhcp-range=tag:primaryRange,10.20.0.100,10.20.0.200,255.255.0.0,8h

Now, pihole restartdns works and it reads the custom configuration file, recognizes the custom rules, but afterwards the DHCP range is fixed again from 10.20.0.11 to 10.20.0.200 as set in the web admin interface of PiHole -- the rules are not applied, i.e. the devices from different MAC address ranges are served with arbitrary IP addresses from the whole range, not from their designated segments.

My understanding of dnsmasq rules is that the latest one is used first, then preceding ones will be applied -- I am wrong here?

Is my setup of MAC filtering wrong, i.e. wrong usage of tags?

Are there other ways to achieve our goal from within Pi-hole?

Edit: Please note that our issue is about filtering the MAC addresses from the DHCP part, not about web blocking based on rules for MAC addresses (all devices should have the same blocking rules)

There is no general rule, you'd have to check that on a per option basis.

In case of dhcp-range, dnsmasq documentation states (emphasis mine):

This option may be repeated, with different addresses, to enable DHCP service to more than one network.

I read this as a requirement for DHCP ranges to be disjunct.

In your configuration, dhcp-range seems to be used three times:

/* from Pi-hole's UI */
dhcp-range=10.20.0.11,10.20.0.200,24h
/* from your custom configuration */
dhcp-range=tag:primaryRange,10.20.0.100,10.20.0.200,255.255.0.0,8h
dhcp-range=tag:secondaryRange,10.20.0.11,10.20.0.99,255.255.0.0,8h

So your DHCP ranges are not disjunct - they overlap.
In addition, you don't seem to set the secondaryRange tag, so that option would never be applied anyway.

To make this work as intended, I'd probably try to limit Pi-hole's UI DHCP range to serve your guest devices only and keep just the primaryRange in your custom configuration file, so you'd end up with only two dhcp-range options:

/* from Pi-hole's UI */
dhcp-range=10.20.0.11,10.20.0.99,24h
/* from your custom configuration */
dhcp-range=tag:primaryRange,10.20.0.100,10.20.0.200,255.255.0.0,8h

Note however, that your issue is essentially a dnsmasq question.
If my above suggestion doesn't produce the desired outcome, it may be worth considering to additionally consult dnsmasq's support channels.

And on a parting thought, some side notes on MAC address usage (click for details)

Usually, the first three bytes of a MAC address (OUI) identify the organisation that issued the interface device, so it might be sufficient to provide only those.

On the other hand, you should be aware that any guest device that would happen to match your MAC address mask would be tagged as primaryRange as well. It may be required to use more specific MAC address details, or to find other means of tagging a client (e.g. provide guest access only through a specific dedicated interface).

And finally, you should be aware that DHCP clients may present a client id instead of a MAC address to register a lease, whoich may interfere with your tagging as well (e.g. VM clients or some dual stack clients may do so - see also RFC 4361).

Hello Bucking_Horn,

thank you very much for you elaborate reply.

First of all, you are right about the non-disjunct dhcp-ranges -- my bad, my mind was going into the wrong direction about this.

You're also right about the three first bytes of MAC addresses -- I remembered it wrong.

About your insights on MAC addresses:

Yes, we are aware that there might be guest devices having the same MAC address vendor type and that we would be able to 'catch' any guest device -- that's not really issue however.

We also considered having a specific interface for guest devices access.

Yes, but this is rather unlikely -- about 99% of guest devices are not sophistically configured notebooks, tablets or smartphones owned by our 'guests' -- the chances for VM etc. are quite low.

I will give your suggestions a try and will come back reporting in a few days -- hopefully being successful then.

I will also do some research on dnsmasq in addition

BlackForester