Action Needed pop up for one SSID when connecting

Solved
Mud_Flaps
Conversationalist

Action Needed pop up for one SSID when connecting

Hello all, curious why one of our SSID's always has a windows pop up when auto-connecting. It says Action Needed to connect to the SSID. If you click on that it doesn't take you to a splash page or anything, and it then just works. Even if you just leave it sit for a bit it will eventually go away and work. 

 

I was curious if this had something to do with my policy to block IOS/Android devices from that network, seemed to start noticing those prompts around same time we started blocking those devices. 

 

It doesn't pop up every time you connect, but if you don't connect for a day or two it will then pop up the action needed.

 

Any ideas? 

 

Thanks! 

1 Accepted Solution

When we are using the device policy setting for an SSID, a couple of things will occur.

 

First, it will not stop a "blocked" device type from attempting to connect to the AP but it will deny any traffic from that device starting at the AP. It can be thought of as a deny any-any firewall rule assigned by the AP to that specific type of device.

 

Second, when we are using the device policy setting how we obtain the device details to mark them as iOS, android, windows, etc, is we push them through a transparent splash page. Client identification is done by examining the User-Agent string field of an HTTP GET, and to force this GET the transparent splash is used as opposed to waiting for an HTTP GET from the device. This could be triggering the connection delay on the Windows device, and why you are seeing this "further action needed message". If it is reliably reproduced on the Windows devices then a quick test could be to disable device policies on the impacted SSID connect a known impact Windows device and see if the behavior reproduces.

 

If we are seeing a consistency between this setting and this behavior on Windows devices I would advise opening a support case for further review of the behavior. 

View solution in original post

12 Replies 12
alemabrahao
Kind of a big deal
Kind of a big deal

We need more details, what is the AP model and version it is running?

What type of authentication are you using?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
PhilipDAth
Kind of a big deal
Kind of a big deal

I this WPA2-Enterprise using username/password authentication, and is it by chance a Windows machine doing this?

 

If so, this was a change Microsoft made maybe 3 months ago.  WPA2-Enterprise with username/password authentication can not longer be used for SSO (where the machine automatically connects).  You now have to click on it to connect.

 

Microsoft wants everyone to migrate to using certificates.

Mud_Flaps
Conversationalist

Hi guys, we are running MR44 AP's and it's on version MR30.5 firmware. 

 

This only happens on one of the SSID's we have the same auth setup for all of them. PSK (WPA2)

Mud_Flaps
Conversationalist

This is the message that comes up:

 

ssid pop-up.jpg

Can you show your SSID configuration?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
UKDanJones
Building a reputation

I've only ever had issues when using the device policies from Meraki. They're a best guess, not a definitive list that can be counted on. I always suggest people disable device policies. 

Please feel free to hit that kudos button
Mud_Flaps
Conversationalist

I do find the device policies helpful for stopping mobile devices from connecting to some of our networks, that is why I'm keeping it on so far. Thanks

UKDanJones
Building a reputation

This is the issue I’ve found… it doesn’t only stop mobile devices. Not only that but it often doesn’t stop mobile devices at all. 

there’s no way for the AP to know that it’s definitely a mobile device. It’s basically guessing. 

Please feel free to hit that kudos button

Our testing proved out pretty successful in stopping mobile devices from connecting, granted it's based on connection information being shared during association, and can definitely be spoofed, but overall it prevented most mobile's from connecting. 

 

We have not seen it prevent a non IOS/Android device from connecting so far. 

UKDanJones
Building a reputation

What do you class a surface pro as? Tablet or laptop? What about an android TV? Or an iPhone in power save mode?

 

I think my point is that a proper NAC is better than the ‘best guess’ of the meraki device policies. 

Please feel free to hit that kudos button

When we are using the device policy setting for an SSID, a couple of things will occur.

 

First, it will not stop a "blocked" device type from attempting to connect to the AP but it will deny any traffic from that device starting at the AP. It can be thought of as a deny any-any firewall rule assigned by the AP to that specific type of device.

 

Second, when we are using the device policy setting how we obtain the device details to mark them as iOS, android, windows, etc, is we push them through a transparent splash page. Client identification is done by examining the User-Agent string field of an HTTP GET, and to force this GET the transparent splash is used as opposed to waiting for an HTTP GET from the device. This could be triggering the connection delay on the Windows device, and why you are seeing this "further action needed message". If it is reliably reproduced on the Windows devices then a quick test could be to disable device policies on the impacted SSID connect a known impact Windows device and see if the behavior reproduces.

 

If we are seeing a consistency between this setting and this behavior on Windows devices I would advise opening a support case for further review of the behavior. 

Thanks for this! Pretty much what I was thinking. I haven't been able to easily test this because once I get connected on a device,  I don't see that windows pop up again for quite some time. It's not as easy as disconnect, turn off that policy, try again. 

 

I'm pretty confident the device policy is at fault here. At some point I will just turn that off for a period of time and see what if the windows pop up is gone. 

 

Thanks! 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels