Wireless access by MAC Address

Bruce_Johnson
Comes here often

Wireless access by MAC Address

So I have created an open SSID, with no splash page.  I created default policy for each OS and the Other OS, as blocked.  This allows clients to join the open network, but must be configured individually to the whitelisted policy before having throughput on the network.

 

I have some clients that are not getting a policy by default.  Their OS says Other, not Other OS as the policy offers as a selection.

 

Hoping to have this as a good guest network that is controlled by MAC address.  No password, no splash page, just MAC address, but I am fearful that this has a possible open loophole.  This is in a school, so I need the security.

 

How can I make sure that all new clients are given the default blocked policy otherwise, if the OS is not being recognized?

 

Bruce_Johnson_0-1640016880012.png

 

 

9 Replies 9
KarstenI
Kind of a big deal
Kind of a big deal

You mention you need security, but every visitor with one of a recognised OS can connect. And also every student that can manipulate its PC. This gives you exactly zero security.

 

For an easy solution you could use the "Multiple PSK" feature that makes it quite easy to rotate the PSKs for a given user-group. Or if you really want security, you should have an account (AD, LDAP, Meraki) for each student and use Enterprise authentication.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
Bruce_Johnson
Comes here often

The LDAP solution does not allow for a guest speaker to come in.. they don't have ldap accounts.  I would prefer to whitelist them.

 

As for the security, the default policy is set to blocked for all OS's.. I've added a pick to the original post.

 

The issue is, some connections are not getting the default policy as configured in the picture above.. some get a "normal" policy, with no block.

KarstenI
Kind of a big deal
Kind of a big deal

Ok, now I understand your approach. I still would not do it that way as *every* not recognised device will get access by default.

If you really want to have MAC-based whitelisting, I would setup a RADIUS-server (open source like FreeRADIUS, RADIUSdesk  etc. will do the job) and maintain the list of MAC-addresses there.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
Bruce_Johnson
Comes here often

But shouldn't each new device connecting to this SSID be given this policy, as all OS's were selected?  That's essentially what my original question was trying to ask..  Why do some devices show up with a normal policy instead of the custom one, when I configured for all known OS's and Other OS too...

KarstenI
Kind of a big deal
Kind of a big deal

I never used this feature so perhaps someone else has more experience with that. But the classification is done on looking at HTTP-requests. I assume that the AP needs to see the user-agent to classify the device. But if there is no HTTP-request, there is probably no classification.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
Russ_B
Getting noticed

I wouldn't trust the OS Identification, I have Hyper-V servers that are identified as Xbox in the Meraki dashboard.  I would use a layer 3 firewall rule to deny all traffic on the SSID, then you can Allow specific clients to override that.  There's information on how to do that here:

 

Solved: Setting up an MR44 to allow only a few clients using MAC address filtering - The Meraki Comm...

 

and here:

 

Solved: Re: Restrict access by PSK and MAC? - The Meraki Community

 

 

Even with the deny all L3 firewall rule and Allowing certain clients I'm still not sure I'd feel comfortable with having a completely open network.

PhilipDAth
Kind of a big deal
Kind of a big deal

It can take some time for the system to identify a host.  It has to watch the traffic being generated by the host to try and figure it out.  Until the system can identify what type of host it is, it won't be able to assign a policy (hence why you are seeing it as having no policy assigned).

 

I would not use this approach.

rhbirkelund
Kind of a big deal
Kind of a big deal

Have you tried looking into Trusted Access?

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Trusted_Access_for_Se...

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
Bruce_Johnson
Comes here often

My issue is that I do have guests.  What I am trying to prevent, is students bringing in a personal device and connecting to the wifi.  We supply each student with a device that is managed, and on a SSID that is distributed by the management software.  I want to provide a SSID for adults.  Staff have personal devices, and there are guests that come and go.

 

A LDAP solution would make managing guests a nightmare.

 

A Meraki account solution would be very similar, and possible impersonation?

 

I am hoping to manage the solution through the portal.  As someone connects, I can see their presence, and establish an allow.  

 

The students are such a moving target, I am trying to prevent alot of repeated attention.  I need to not rely on an email request from a random address.  We have a tech person in each building, and I make the requests be in person through her.  Then I can allow.  Else we have issues.  I did just have a shared password on a staff SSID, but the teachers give it to the students when they whine.

 

I'm thinking RADIUS is the best blocking, and easiest whitelisting?  While preventing any accounts needed..??

 

Open to other strategies, just need to ensure their is an ease of use, and no opportunity for student access.

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