Ability to push a Wifi client to a different SSID using NAC?

[ronnieshih75]

We are in the process of implementing NAC control and is looking for a way to automatically disconnect a WiFi endpoint from any SSIDs users shouldn't connect to and placing them into a guest SSID.  I have already spoken to Meraki support and was told that there is no way to do this as an endpoint is the selection host of SSID to connect to and it cannot be done via an intermediate NAC control point or a Meraki group policy.  A NAC solution can exercise a block action by basically making an API call to meraki dashboard, but making the endpoint connect to a different SSID is not possible.  I'd like to know that there is really a way to do this.

We are currently deploying Forescout as the NAC solution.

[PhilipDAth]

There isn't any generic way to tell a client to connect to an alternative SSID.  You would require some kind of agent on the endpoint that the NAC can talk to and tell it to connect to a different SSID.

HOWEVER, you could just use a single SSID, and then have your NAC drop the user into different VLANS and apply different firewall rule sets (done by NAC telling Meraki to apply a specific group policy to a client).

https://documentation.meraki.com/MR/Group_Policies_and_Block_Lists/Using_RADIUS_Attributes_to_Apply_... 

[alemabrahao]

I think It's not possible, maybe with an MDM solution, but I'm not sure.

[ronnieshih75]

Using an installed agent is out of the question.  The whole point of my goal here is to prevent people from connecting their personal devices to a SSID using PSK, where everyone already knows the password.  I cannot possibly tell people to install an app agent so I can kick them off the network 😅 This needs to be transparent in the background.  Yes yes, we are looking to change the PSK passphrase on that SSID, however, that's easier said than done because there are hundreds legit IoT devices using that existing PSK SSID.  We have a rampant problem with people connecting their personal cell phone and streaming on the wifi network causing high bandwidth usage.

[PhilipDAth]

>The whole point of my goal here is to prevent people from connecting their personal devices to a SSID using PS

For the IoT devices, consider using iPSK, where each individual device gets its own key.

https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication 

You could also look at only using IoT devices that support WPA2-Enterprise mode authentication, and use certificate-based authentication.

Another option I have done for a client is to make the default firewall rule "deny all", so anyone attaching to WiFi has no access to anything.  Then for approved devices, you apply a group policy that changes that firewall rule and allows access.

[KarstenI]

This problem can also be addressed with changing the SSID to "Identity PSK without RADIUS". One PSK is left on the old value, but the group policy is highly restrictive just for the IoT use case. For regular devices you configure a new PSK with a different Group-Policy. On the Networks device list you can also see which device uses the old and the new group-policy and directly address people that use the old one.

[ronnieshih75]

Keeping track of over 5000 approved devices across 145+ networks would be a monumental full time task for me.  So I'm leaning toward the iPSK without RADIUS idea.  We are using Forescout, and is the iPSK with RADIUS even possible?

I am still picturing our field techs heading out to all locations and modifying the PSK for all IoT devices first even if I use iPSK without RADIUS.  Secondly, if I do assign a different group policy to personal wireless devices, it still sits in a vlan that's not of the "guest" vlan correct?

[KarstenI]

I don't know Forescout, but I don't know why it shouldn't work. With both solutions, you can assign different VLANs to different groups of clients.

[PhilipDAth]

>So I'm leaning toward the iPSK without RADIUS idea

You are limited (off the top of my head) to 50 iPSK devices when doing it manually via the dashboard per network.

At your scale - you would only consider dong iPSK via RADIUS.  These are the instructions for how to do it with RADIUS.

https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication 

A special note, Microsoft NPS is not capable of doing this.  Most other RADIUS servers can, including FreeRADIUS.

[PhilipDAth]

Note that if you do use iPSK and RADIUS, you can also push per-use group policies as well.

So you could have printers using one group policy, door sensors another, etc.

Splash Access have an onboarding system that uses iPSK (and they handle the RADIUS for you).  It's actually the education product for student accommodation.  Students get a username and password they can log onto a web portal with, and can then allocate a PSK for each of their devices (like a play station, etc).  It also supports using group policy and VLANs (I think they use it to put each student into their own VLAN so every student is isolated from every other student).

https://www.splashaccess.com/ 

So you could nominate people (like IT staff) to be able to onboard your devices, and then each location can look after their own devices.

[ronnieshih75]

Because I'm told by Meraki support that assigning or tagging a different VLAN by a NAC mediator by means of applying a group policy via meraki API does not "move" an endpoint into a different SSID network.  In theory, it changes the VLAN the client sits in, but it does not connect the endpoint to a different SSID.

Is this true?

[PhilipDAth]

Correct - but there is no need to move them to a different SSID.  Each user is virtually isolated using whatever VLANs (such as guest) and firewall rules you like.

Using separate SSIDs only works on smaller scales.

[ronnieshih75]

So I have several challenges here:

- Since everyone knows the PSK passphrase for the existing SSID network, every single IoT devices + personal devices are connected to that SSID.  I basically need to kick all those personal devices off that existing SSID network first.  I see this is possible by using the "assign group policies by device type" then create and apply a policy with a firewall rule which says "Deny Any to Any".  Our network has a rampant issue with personal Apple iPhones running wild so this is easy for me to do.

- iPSK with RADIUS needs a database of MAC addresses of approved devices that are allowed to connect correct?  I basically need to gather device types and their first few octets and configure them inside Forescout.  Forescout will then act as the central point of auth for PSKs.  Although all our wifi networks are centrally managed via a template, so by having the different PSKs configured inside 1 single Meraki template, is that not the equivalent of having the PSKs on a RADIUS server?  It's almost like one solution is enclosed within Meraki and the other I'm using a 3rd party off-band server for auth.  The only feature I'm missing here is that I wouldn't have a database of approved devices by doing it inside Meraki as oppose to inside Forescout.

BTW, we will not have more than 10 devices using PSK because all windows domain joined devices are using 802.1x auth through a different SSID already.  So I don't see doing this at the meraki level being an issue, with the limit of 50 iPSK devices.

- THEN, we need to have our field techs change the PSK on IoT devices so that legacy PSK passphrase can be eliminated, preventing any future personal devices from using it.  And the different PSKs can start to be handed out for different purposes.  This last part is the most painful as our company has geographically diverse locations throughout US and will not be easy.

[PhilipDAth]

Having fewer than 10 devices using iPSK - then you can simply do this via the Meraki Dashboard.  You can just load in the existing MAC addresses, and assign them the current PSK, and they will still be able to connect, while everything else will be blocked.  Going forward you can use a unique PSK per device.

 "assign group policies by device type" would not work for your use case.  You would find it unreliable.

If using RADIUS, I would dump every single connected MAC address for the whole org.  Apple devices should be easy to spot because of their MAC address.  Delete all of those.

Now load in that MAC address list to your RADIUS server, and assign every one of them the current PSK.

Now on day one, every device will still be able to connect, except Apple devices.  At this point, you have mostly achieved what you want.  Only authorised MAC addresses can now connect.

As you go forward, you can then start assigning unique iPSKs.

[ronnieshih75]

Did you mean loading the approved MAC addresses into Forescout and utilize iPSK with RADIUS right away?  Since I don't see a native connectivity restriction by MAC address option in Meraki.  I mean, other than the "MAC-based access control (no encryption)" option.  And that's up to 10 IoT devices per network and I have 145 networks, so it's 1450 legit IoT devices that need to remain connected.

I should mention that I do not have an inventory of all IoT devices as we speak.  That's why I need to phase this in by forcibly disconnecting other types of devices first, and without changing the existing PSK passphrase because I cannot drop those IoT devices off the network.  I understand "apply group policy by device type" option is not reliable but it's something than nothing.  I don't see why I cannot use this right away simply to disconnect Apple devices off the network.  The most recent version of Meraki dashboard 90% of the time can identify apple devices properly from what I've been seeing.

[MarcP]

@PhilipDAth When using iPSK and having a bandwidth limit in generell for the SSID, I have a question on...

Creating three goup policies for the SSID (10mbit ssid bandwidth)

1 group "use network bandwidth" - will it have the 10mbit defined in Firewall & traffic shaping?

2 group "ignore" - unlimited whatever id defined in fw&traffic shaping?

3 group "custom" - for each device in this network?

[ronnieshih75]

"Assign group policies automatically by device type" option works within each SSID network where it's defined, as I tested using an Apple ipad and an android phone.  A single Deny Any to Any rule + an Allow UDP port 67 allows a device to obtain an IP address seemingly to allow access but all traffic to anywhere is denied.  Although, you do need to allow for existing traffic streams to die off then all new traffic would effectively be blocked. This fulfills my goal of kicking all personal devices off our existing PSK SSID without changing the passphrase.  This forces everyone to use the guest SSID instead.

After the above is done for a while, we'll implement iPSK with RADIUS where we have a central MAB database of devices using different PSKs.