Meraki and MAC Address Randomization
MAC randomization has become much more prevalent in enterprise networks. With newer mobile devices like Apple or Android smartphones, this feature is usually enabled by default. This document will cover some of the current MAC randomization feature that are available and how these features effect Cisco Meraki devices/features.
iOS 14 MAC Randomization
Apple released iOS 14 on September 16, 2020, which included some changes to how MAC addresses are handled on iOS devices. iOS 14 introduced the MAC randomization feature which means that for each SSID, devices running iOS 14 will present a distinct randomized MAC address. This randomized MAC address for each network will not change over time, upon reconnecting to the same SSID, or when the SSID is “forgotten” in the device settings and re-joined later on. Also, toggling ‘Private Address’ on and off on an iOS 14 device will switch between the real MAC and the randomized MAC for that Wi-Fi network, but that the randomized MAC won’t change as a result of the toggle either.
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.
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.
Android 10+ MAC Randomization
Similar to iOS devices, the MAC randomization feature on Android devices allows for the use of randomized MAC addresses when connecting to a Wi-Fi network. On Android 10+ devices, MAC randomization is enabled by default, and can be enabled/disabled by going to the network details section of the settings page:
Android devices will use one of two specific MAC randomization types when connecting to a Wi-Fi network. These two types are persistent randomization and non-persistent randomization. Android devices themselves will pick the type of MAC randomization to use when they connecting to a Wi-Fi network.
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.
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.
How MAC Randomization Affects Features Provided by Meraki
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.
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 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”