In a Zero Trust connectivity policy where 802.1x is not in use, the MAC address becomes the device identifier to determine its adam:ONE® policy.
It is desirable to disallow a layer2 connection until the real MAC address is being used as per steps outlined at adamnet.io/macrandom.
From RFC 7042 we learn the following:
Two bits within the initial octet of an EUI-48 have special significance in MAC addresses: the Group bit (01) and the Local bit (02). OUIs and longer MAC prefixes are assigned with the Local bit zero and the Group bit unspecified. Multicast identifiers may be constructed by turning on the Group bit, and unicast identifiers may be constructed by leaving the Group bit zero.
This translates into the second digit of the first octet being a 2, 6, A or E. Another way to look at it is with wildcard syntax:
*2:*:*:*:*:*
*6:*:*:*:*:*
*A:*:*:*:*:*
*E:*:*:*:*:*
Popular DHCP servers all have a way of blocking matching DHCP requests, and since pfSense is a popular platform, here are the steps to deny a DHCP address to RFC 7042 randomized MAC addresses:
From the pfSense GUI, choose → Services → DHCP Server. On each of your LAN segments this should apply, click on MAC address control → Display Advanced and enter this string into the the MAC Deny field:
A2,B2,C2,D2,E2,F2,12,22,32,42,52,62,72,82,92,02,A6,B6,C6,D6,E6,F6,16,26,36,46,56,66,76,86,96,06,AA,BA,CA,DA,EA,FA,1A,2A,3A,4A,5A,6A,7A,8A,9A,0A,AE,BE,CE,DE,EE,FE,1E,2E,3E,4E,5E,6E,7E,8E,9E,0E
To test it out, we try an iPad out with a random MAC address (default) and as we can see, it ends up using 169.254.x.y self-assigned IP and is unable to get onto the network:
In pfSense, we observe logs like this:
Jul 1 16:45:25 dhcpd 3062 DHCPDISCOVER from f6:ac:55:6d:52:21 via hn1: network 192.168.29.0/24: no free leases
Jul 1 16:45:25 dhcpd 3062 DHCPDISCOVER from f6:ac:55:6d:52:21 via hn1: network 192.168.29.0/24: no free leases
Jul 1 16:45:25 dhcpd 3062 DHCPDISCOVER from f6:ac:55:6d:52:21 via hn1: network 192.168.29.0/24: no free leases
But as soon as we disable Private Wi-Fi Address, it is able to get an IP address just fine:
Link-local addresses
Devices that attempt to join the network with a randomized MAC address may still be enrolled by adam:ONE® with link-local addresses. Those can simply be set to Forget.
Important notes
This is not something you want to do for a public hotspot such as at a coffee shop. The device anonymity is valuable there.
This step should also not be done on a voucher-based guest wifi option where users rely on vouchers or credentials to have time-limited guest wifi. Such users will and should expect private MAC address usage.
Finally, note that this is not a security feature. A randomized MAC address with a manual IP address specification may still get onto your network. This is where your default adam:ONE® policy to quarantine them in a Holding Tank is still essential.