How to handle randomized MAC addresses on Android 9+ and iOS 14+

Previous versions of Android and iOS already used randomized MAC addresses prior to joining a WiFi network. This proved to be a great privacy addition as it disabled passive MAC address “following” just because the WiFi radio was on.

Modern Android and iOS take MAC address randomization one step further by generating MAC addresses even when connected, never revealing the real MAC address. This new setting is now the default, which is a positive move for when you join someone else’s hotspot.

However, in your own network, there’s no advantage to a privatized MAC address whatsoever, assuming you (or people you trust) manage your network.

adam:ONE uses MAC addresses as unique identifiers so the dashboard administrator can assign policies based on the MAC address. Note that little “home network” privacy is gained because the NAME of the device is still visible on your own network in any case.

On a per-network basis, you can turn off MAC address randomization by navigating to Settings -> WiFi -> Click on the (i) beside your connected WiFi and disable the Private Address like this:

On Android, choose your WiFi Network -> Advanced -> Privacy and choose Use device MAC like this:

Note that you don’t need to do this to any other WiFi network except the SSIDs that utilize adam:ONE for security.

References:

iOS feature: https://support.apple.com/en-us/HT211227
Android feature: https://source.android.com/devices/tech/connect/wifi-mac-randomization

Users that don’t like filtering or just passive users won’t have any incentive to do this. It’ll have to be a one policy fits all approach.

Our recommended default policy is a kind of Holding Tank. This is the case with every managed deployment, in any case.

If you deploy the same approach, users will be incentivized.

Any “stranger” that comes onto your network needs to be treated as such. As per @David 's suggestion they need to be in the HoldingTank (Essentially a modified No-Internet policy). If your device presents itself as a stranger it will not be allowed to go anywhere. So regardless if the user “likes filtering” or not, they will have to allow their device to present itself as a Known entity to get access in our out of the protected network (Meaning: not with a randomized address).

Getting Internet access is a pretty good incentive. :slight_smile:

so a question on that. I am wondering if there is a way around this. If I have a default NO INTERNET policy where new devices automaticaly go into, BUT I have firewall bypass rules for whatsapp and facebook because they don’t work with adam one otherwise.
Is there a different way I can set it up so that the devices truly have NO INTERNET?

An enabler is a firewall rule that supersedes adam:ONE DTTS functionality (this applies only to pfSense platform). Here’s one way you can address it that requires a little planning and onboarding per-device, which you need to do anyway in order to assign them a specific policy:

  • segment your subnet to DHCP range and DHCP RESERVATION (Static DHCP) range in half
  • for example, 10.10.10.30-127 can be for non-reserved DHCP offers, 10.10.10.128-254 for reservations
  • create your enabler rules for 10.10.10.128/25 subnet only and the non-reserved IPs will not have the enabler rules applied to them

Other clients take it a step further and simply deny IP addresses to any non-reserved MAC address, but then the onboarding is a little more difficult b/c you can’t get the newcomer’s via mytools.management/whoami (or by looking at DHCP lease table, or by looking at your holding tank, etc).

Of course there’s another mechanism as well, which would be to use 802.1x authentication on your wifi network and have entire VLANs dedicated to either a holding tank/no internet policy with no enablers, vs approved use with enablers.

If you’re a unifi shop, this may be helpful: https://help.ui.com/hc/en-us/articles/360015169854-UniFi-Configuring-Access-Policies-for-Wireless-Clients