WIFI MAC Whitelisting breaks

[Kegan]

I can't find any previous posts relating specifically to this issue.

We Whitelist client machines on our network on the dashboard, but it seems to break often. At random clients will get prompted with the sign in splash screen, then our first line team need to lookup each user set their policy to normal and then back to whitelisted to fix the problem.

It causes a lot of overhead. So I need to fix it.

Has anyone seen similar issues?

Using Mostly MR42

[kYutobi]

Why not create a group policy and add clients that way. Maybe a "client whitelist" policy that way you can keep a list of everyone and not have to keep changing it. I've never seen an issue where it changes it automatically.

[Kegan]

Thanks kYutobi!

I will give this a try, although I'm not sure I will help, the clients still show as whitelisted in the Dashboard when they stop working.

Will update once I've tested this..

[PhilipDAth]

Some Apple devices (and Android for that matter) use MAC address randomization to make them more anonymous.  Devices with this feature enabled will cause issues like this.

Are you able to change to using something authenticated, and perhaps a RADIUS server? If so, then you could apply the policy dynamically based on who the user is.

[BrechtSchamp]

---

@PhilipDAth wrote:

Some Apple devices (and Android for that matter) use MAC address randomization to make them more anonymous.  Devices with this feature enabled will cause issues like this.

Are you able to change to using something authenticated, and perhaps a RADIUS server? If so, then you could apply the policy dynamically based on who the user is.

---

It would be interesting to find out if a MAC address change actually took place actually caused this issue.

I was under the impression that MAC randomization only took place while not actually connected to networks and in some cases once upon connecting to a new network?

[Kegan]

Thanks Both.

In this case we run 90% android phones and 100% HP Notebooks. I'm sure the mac addresses on our notebooks are fixed, these are all affected at random. 

[Cmiller]

Could you not setup a "internet" SSID with the splash screen and then a "Internal" SSID without the splash screen? To clarify, why would you whitelist all devices and not set up a group policy with less strict rolls? Whitelisting seems to be a security risk as it removes content filtering and Layer 3,7 firewall rules.

https://documentation.meraki.com/MX/Group_Policies_and_Blacklisting/Blocking_and_Whitelisting_Client...

TIL you can only have 3000 whitelist or blocked items

[Kegan]

Thanks @Cmiller

We have a guest network with no splash page, they can do what they like, throttled and segregated of course. Traditionally have used WPA2 in combo with meraki auth, with lots of staff it's hard to keep them from doing silly things with the with the WIFI key. meaki auth allows us to keep random devices off our internal network, as they need to be whitelisted first.

I know this is not the greatest solution. Ultimately we will be moving to proper Radius solution(not MS) as there are a lot of clients, but this requires some planning and fitting around other projects so might not happen in the next few months. For now Id like to try getting the Meraki whitelisting to work for us.

Small Update: This seems to be worse in our most busy area's. We have a load of MR42's on one floor that gets tons of foot traffic, this seems to be where users WIFI drop's and they get the splash page despite being whitelisted. Meraki have offered to RMA our unit's. I not 100% this will sort the issue but we will see what happens.

[Cmiller]

So you're having the user connect to the WiFi with WPA2, then the Meraki authentication, and then "whitelisting" the device on the SSID, not on the Network-wide > clients page?

I was testing on one of my sites and noticed the wireless > access control > my test SSID > Splash page, choosing Meraki authentication adds the Authenticated user line where you can set who is allowed at all. I guessing this is the method you are working from correct?

[Kegan]

Hi @Cmiller

Sorry I'm still getting to grips with the dashboard. I am using the Network wide Page to set the policy for the clients:

[Cmiller]

Under wireless > access control > choose your staff SSID and what option are you using under Splash page?

[Kegan]

Sign on with Meraki authentication

[Kegan]

Quick update - Meraki Support have found this to be a back end issue, they are trying to fix it.

[BrechtSchamp]

Thanks for the info. Keep us posted!

[GlenW70]

We are experiencing this same issue at 2 sites

Does anyone have an update on this?

I have 2 tickets open with Meraki support but nobody is claiming to know about a back end issue.

[Kegan]

Hi Glen,

Glad to know we were not the only ones to suffer this strange issue. 

There was definitely some kind of server side issue causing this whitelisting reset issue, Meraki support were reluctant to give away any information about this problem, there was always some 2nd line engineers who discvered and appear to have resolved the problem, though you never get to talk directly to them.

We tried updating, resetting and replacing WAP's, we thought it may be a through put issue at one point, but in the end Meraki did something and the issue wen't away.

If it helps support our case was: Case 03187258

Support didn't update the case with anything really useful, they most only eluded to a server side issue over the phone.

'As a little update here, our development teams have a good understanding of what's causing the applied group policies to not be honored by the devices, but we are waiting for them to implement a fix or to provide us with more feedback. As per request, I will reach out to you weekly to keep yourself up to date with this.



In the meantime, do you have any active examples of this occurring that you can leave in the broken state for some time? Development has asked support for active examples to investigate further.



I know you have previously given us a list of affected APs, but would you mind sending us a newer/more up to date list of all affected APs? This is mainly for us to keep a record, but it also might assist the development teams.'

good luck! I hope this helps..

[GlenW70]

Hi Kegan,

Yes we currently have 2 sites experiencing the issue.

Our case number is 04537743.

Site #3 is all MR42s and MR70s

Site #14 is all MR42s and MR70s

In both sites we have 3 or 4 fully functional devices but 1 device (iPad pro in both locations) that will not respond to whitelisting.

In each of the sites we've gone so far as to replace the device and testing in site 3 shows no change.

Both are broken now (since nobody at support has been able to solve our issue) so replicating the issue is very easy for us right now.

I am happy to assist with beta or patch if you think it could help.

Please let me know how I can contribute.

[Kegan]

Hi Glen,

This issue seems to have gone a way for us, I suspect something was done by the Meraki engineers but it was hard to get and information from them via the support ticket...

[GlenW70]

Support was able to fix this for us.

It is an engineering change made behind the scenes

If you have a similar issue you could ask support to reference our case 04537743