Meraki and MAC Address Randomization

How to Identify Randomized iOS MAC Addresses

If a MAC address second character is a 2, 6, A, or E, then it is a randomized address.

x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx

How iOS MAC Randomization Impacts Networks

If an Apple user upgrades to iOS 14 and visits your location, their device will connect to the network with a randomized MAC address. This MAC address is different from the device MAC address, is SSID specific, and will remain the same for a given SSID. Apple has, however, stated the possibility of implementing rotation of MAC addresses within a single SSID in the future.

This change from Apple is expected to impact several Wi-Fi features and services across various products in the industry. This is also expected to increase the load on the network and cause anomalies. Meraki will be tracking the impact of this closely and taking proactive steps.

Persistent randomization 

This is the default type of MAC randomization that is used when MAC randomization is enabled on Android devices. An Android device will generate a persistent MAC address based on specific parameters in the network profile like SSID or security type. 

This MAC address will remain the same until a factory reset of the device. The MAC address does not get re-randomized if the user forgets and re-adds the Wi-Fi network since the MAC addressed depends on the parameters of the network profile.

For Android 10 and 11 devices, the persistent randomization framework is used for all networks when MAC randomization is enabled.

Non-persistent randomization 

This type of MAC randomization is available for Android 12+ devices, and relies on the Android device either (1) re-randomizing the MAC address at the start of every connection (to the same SSIDs, etc.) or (2) uses the existing randomized MAC address to connect to a known network. 

An Android device that is using this type of MAC randomization will re-randomize the MAC address in the following situations:

• The DHCP lease duration has expired and more than 4 hours have elapsed since the device last disconnected from this network.
• The current randomized MAC for the network profile was generated more than 24 hours ago. MAC address re-randomization only happens at the start of a new connection. Wi-Fi won't actively disconnect for the purpose of re-randomizing a MAC address.

If none of these situations apply, the framework uses the previously randomized MAC address to connect to the network.

For devices running Android 11 or 12, users can enable non-persistent MAC randomization globally for all Wi-Fi networks (that have MAC randomization enabled) through the developer options screen.

Duplicate Client IP Address Reporting

Depending on the duration of the DHCP lease, there is a possibility that the dashboard might report IP conflicts if an iOS 14 client switches its MAC but keeps the same IP address  (for example, immediately after the upgrade the client device is requesting the same IP address from a different MAC address). This behavior may trigger false-positives in a network for duplicate IP assignment.

Also, under certain circumstances, iOS 14 is sending a malformed ARP response that carries the HW MAC address instead of the Randomized MAC address it should instead be using.

DHCP Pool Assignment

Since Apple devices are now changing their MAC address and sending DHCP requests to obtain an IP address, MX (or MS L3 switches acting as a DHCP server) security appliances are offering new IP addresses based on new randomized MAC address because most Meraki assignments are done via MAC address. The MX devices must now account for two IP addresses for each iOS 14 device present in the network using the MAC randomization features per SSID in bridge mode. Below is a snapshot of the same client as it appears in the MX dashboard using the original MAC and randomized MAC.

This may cause DHCP pool exhaustion issues. Lowering the DCHP lease time might mitigate this issue to some degree.

Location Analytics

You might see a decrease in “Connected” clients as devices transition to randomized MAC addresses because the Meraki dashboard will filter out all randomized MAC addresses by default.

You also might notice a decrease in “Passerby” and “Visitor” because the Meraki dashboard will also filter out all randomized MAC addresses for these categories. Please note Apple devices have been using a randomized MAC address for Probe Requests prior to the iOS 14 release.

Loyalty and Engagement graphs will be impacted in a similar way but will stabilize over time.

We have also noticed that in some cases devices are not following the standard process of settings the locally administered bit correctly which is used for identifying randomized MAC address. A unique non-randomized MAC address needs to be detected for more than 1 minute interval for the client device to be classified as Passerby. If the device is using MAC randomization the MAC address used for probe requests changes multiple times within the 1 minute interval. Dashboard will be eliminating these MAC addresses from the Location Analytics computation and the Scanning APIv2 output as well.

Meraki Health

Meraki Health reports are based on MAC address. Because the MACs will be changed as the client changes SSID, it will be difficult to track if a client device has issues for connectivity or performance across the network or with only one specific SSID. 

Network-wide > Clients page

As iOS devices will report different MAC addresses for the client device, we will categorize this client as a new client in the dashboard. This may cause a sudden surge in the typical client count in any wireless network. This will be shown on the Network-wide > Clients page and in the Summary report.

Systems Manager Sentry Policies

Sentry Policies applies group policies to devices based on their MAC addresses and SM tags. When using randomized MAC addresses, the MX will be unable to properly apply policies to the devices as the MAC address available to SM via MDM is the physical MAC address, and the MAC address reported to the MX will be the randomized MAC. This will cause Sentry Policies not to be applied to SM devices on an MX network with Sentry Policies.

Systems Manager Sentry Enrollment

Sentry Enrollment uses the device burned-in (real) MAC address (received directly from the device via MDM) to detect whether a device has been enrolled with SM when connecting to an MR. Because the device's randomized (private) MAC reported during association to the SSID will not match the burned-in (real) MAC address available to SM, Meraki is unable to detect the device as being already enrolled in MDM. This will cause the feature not to work as designed, as devices will be continuously asked to re-enroll upon association.

Steps You Can Take with Cisco Meraki to Minimize Impact

• Adopt OpenRoaming (part of Cisco DNA Spaces, now adopted as an industry standard for seamless Wi-Fi onboarding)

• Implement policies (e.g. via MDM solutions like Cisco Meraki Systems Manager - see details below) to turn off MAC randomization for the company-owned devices or BYOD devices if the company policy allows it

• Ask users to turn off MAC randomization on their devices

How to Use Systems Manager to Turn Off MAC Randomization

Meraki Systems Manager customers can use the WiFi Settings payload to prevent iOS devices from randomizing their MAC addresses on specific SSIDs

The steps below are demonstrated in this video on using SM to disable MAC Randomization

• Create a new settings profile or modify an existing one

• Choose “+ Add Settings”

• Select the WiFi Settings payload

• Select “Disable MAC address randomization”