Random MAC Address - How to deal with it using ISE

[howon]

Mobile endpoints utilizing random MAC address is nothing new. But the way it is utilized has changed since it was first introduced. In the beginning, the randomization of MAC was used to probe for known wireless networks by the devices. By randomizing the MAC address used in the probe request frame, devices were able to hide real MAC address thus providing some level of privacy. Fast forward few years, now devices started using random MAC addresses for the association to the wireless networks. This causes issue on the network elements which relies on MAC addresses to uniquely identify the endpoint or the user behind it. The implementations of MAC randomization are different depending on the vendor but here are few examples of the behavior:

Microsoft Windows 10

• Can setup randomization both globally for all wireless connections or per network profile (SSID)
• Randomization is disabled by default out-of-the-box
• On the network profile, user can also configure Windows 10 to generate different random MAC every day
• Once random MAC is used for a given network profile, it will keep using it as long as user doesn't delete the network profile
• If user deletes the network profile, next time a different random MAC will be used

Google Android 10/11

• Can setup randomization per network profile (SSID)
• Randomization is enabled by default out-of-the-box
• Once random MAC is used for a given network profile, device will keep using the same random MAC even after user deletes the network profile and recreates the profile

Apple iOS 14, iPadOS 14, watchOS 7

• Can setup randomization per network profile (SSID)
• Randomization is enabled by default out-of-the-box
• Once random MAC is used for a given network profile, device will keep using the same random MAC even after user deletes the network profile and recreates the profile
• Randomization enabled upon update to iOS 14 from previous versions of iOS for existing SSIDs

Although this document is focused on ISE, it should be noted that the impact doesn’t stop with ISE. As MAC address as a unique identifier is hard-coded into products and solutions throughout Cisco and 3rd party, which includes MDM/EMM, wireless performance monitoring, and device profiling systems. ISE or wireless authentication system is in a unique position in the network to control the use of random MAC address for the rest of the network. The good news is that generation of random MAC follows rules set by IEEE. As noted in the diagram below, locally significant address 2’s bit of first byte is set to one. Any MAC address that has locally significant bit set as one and is also a unicast address can be considered a random MAC address.

So based on the rule, all of the numbers below would qualify as a random MAC address. For a simple rule, any MAC address’ first octet that ends 2,6,A,E would be a random MAC address.

With this, ISE policy rule can be created using a regular expression match against the RADIUS Calling-Station-ID attribute within the RADIUS Access-Request which includes the client MAC on virtually all Cisco devices: ^.[26AEae].*

Now that ISE can detect the random MAC, here are few options to consider:

	User experience	Note
1. Deny Access	User will not be able to connect to the wireless network	Bad experience as there could be many other reasons that user cannot connect to the network
2. Deny Access + Instructions	User will be able to connect, but will be redirected to a help page instructing user to disable random MAC feature for this network	Best option, if you do not want random MAC to enter the network.
3. Permit Access + Short session timeout	User will be able to connect, but after the device goes to sleep and awakes, user will be asked to login again
4. Permit Access + Short purge cycle	User will be able to connect, but user will be asked to login after X # of days
5. Permit Access + Consent	User will be prompted but can bypass and gain same level of access as unique MAC
6. Permit Access	User will be able to connect and there are no difference between random MAC and unique MAC

Note: Option 3-6 can be augmented with additional permission to restrict bandwidth, ACL, VLAN, etc. if needed.

User experience for Option 2:

To configure ISE for Option 2, follow instructions here: https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216021-using-hotspot-portal-to-instruct-users-o.html

The following devices have been confirmed to match the random MAC policy rule:

• Windows 10 Home Build 19041 with Intel Wireless Adapter AC 9560

• Google Pixel 2, Pixel 3, Pixel 4 running Android 10
• Samsung S10, S10+, S20+ running Android 10
• Google Pixel 3 running Android 11
• Apple iOS 14

Note: Please note that some devices may match the random MAC policy rule even though they may not be using random MAC address due to OUI assignment that overlaps with the IEEE rule noted above.

For additional information regarding workarounds for different ISE use cases, please review field notice for MAC randomization: https://www.cisco.com/c/en/us/support/docs/field-notices/706/fn70610.html

[D4rkie]

Maybe it is worth mentioning that for apple it changes ~every 24 hours

Regarding: 

2. Deny Access + Instructions

How can this be achieved with ISE only? We don´t want to host a Webserver for this purpose

[Hideyuki Osaki]

Hi D4rkie, you don't need to have another Webserver for option 2.  All you need is to create a guest portal on ISE. Please check this out to see how.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216021-using-hotspot-portal-to-instruct-users-o.html

[SeadDervishi2949]

Does anyone encountered MAC randomization even when device is connected to mobile data and not WiFi?

If so how can you disable it?

[drichards21]

@Hideyuki Nakai I followed the instructions for the Random MAC hotspot, and users match the policy but the redirect never happens.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216021-using-hotspot-portal-to-instruct-users-o.html

From this article it doesn't mention any other config needed, but on the controller I enabled ISE_NAC and had to have a VLAN with permit access to the PSN's.  Now the only issue is the web redirect isn't automatic on the iOS device, but does at least gets a message on Android that it needs to connect and then the redirect happens.  On iOS you have to manually get it to pop up with a web browser.

[howon]

@drichards21 drichards21, can you confirm whether the captive portal bypass feature is enabled on the WLC or WLAN. You will need to disable it for the iOS auto pop-up to work. https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_01010111.html (Note that later WLC OS supports per WLAN captive portal bypass)

@SeadDervishi2949 SeadDervishi2949, can you elaborate? The random MAC only applies to Wi-Fi access.

[drichards21]

@howon yes I can confirm that the captive portal bypass is disabled.  On the android it gives a message you must connect and then the popup or redirect happens.  On iOS it never comes up and acts as though it is connected unless you launch Safari then the popup or redirect happens.

[howon]

@drichards21 The captive portal bypass feature only affects Apple devices, so the fact that it works for Android doesn't mean it is not enabled. If not popping up for Apple devices only, I would check the settings again. The controller side setting only takes effect when the WLC is reloaded so even if it says it is disabled doesn't mean it is disabled until reloaded, however the WLAN specific feature works without reload. Another reason it may not be popping up on Apple device may be the DNS ACL entry on the redirect ACL. I would make sure apple.com or captive.apple.com is NOT in the DNS ACL for redirect.

[drichards21]

@howon let me clarify it isn't working on the Android, it just gives a message when connecting saying you must connect to this network and when you click on it the banner pops up.

I will try rebooting the controllers when I can (off business hours), but the TAC engineer Glen that helped me today failed to mention we needed to reboot

[howon]

@drichards21 Got it. Since your Android is prompting, it is seeing the captive portal. However, Android requires the portal to have proper certificate. If you are using self-signed, it may not work on Android captive portal browser. Also, what do you mean by 'banner pops up'? Can you share a screenshot of the experience?

[drichards21]

@howon rebooting the controllers fixed it, and to add another note a URL_REDIRECT_ACL was needed not just on the Controller ACL but also applied our on FlexConnect Groups policy too.

Thanks for your reply though that was the trick, reboot the controllers!

Edit:  We used the following commands in CLI 

config wlan disable <wlan id>

config wlan nac radius enable <wlan id>

config wlan security web-auth captive-bypass disable <wlan id>

config wlan enable <wlan id>    

config network web-auth captive-bypass disable

(save and reboot)

[SeadDervishi2949]

@howonyou are right, I did a bad test on VPN connection through a device using mobile data.

I confirm the MAC is the same always.

Thank you!