Join us for a month-long contest with heaps of swag to win!Learn More ›
After manually blocking some devices from Wifi, I see they still can request DHCP addresses and are assigned them from the DHCP server.
This is an issue for the school, as hundreds of students bring in their devices.
Even though they cannot access the Internet, they do use up the DHCP leases.
Anyone know a workaround for this.
SSID has open authentication.
I also noticed that even a blocked client can resolve DNS.
Is this really blocking?
Shouldn't it block them at Layer 2 right at the AP before they ever get an IP Address, let alone resolve DNS?
It is normal behavior, and documented.
Note: The device will still receive an IP address and will be able to resolve DNS names.
Perhaps you should think about other ways of blocking them if that is an issue? RADIUS accounting maybe? That way access will be blocked on a L2 level during the connection phase.
Edit: Forgot to specify... WPA2-Enterprise with RADIUS is what I mean, not splash page with RADIUS accounting.
Thanks for the reply, and thanks for the link.
We were hoping to keep it simple and not involve such measures as radius accounting.
But good idea.
Although I don't see where it is documented that this is normal behavior.
It does say the device is subject to Association Requirements, but in that document there is no mention of DHCP as an Association Requirement.
For blocking, it says:
Traffic is traversing the Meraki device, but we are still able to communicate with some devices on the network.
I guess it is what it is.
It's a note two lines down from the bullet points you copy pasted. I had copy pasted it in my previous post.
I guess it needs the IP and the DNS access for the other bullet:
Using a big enough pool for your DHCP and lowering the lease time should mitigate the DHCP issue. Adding to that taking a look at other high density tricks might also be relevant. Segmenting the traffic per floor to avoid having floods all over the place might help.
Another thing you could do is to use a dedicated 3d party DHCP server and having MAC blacklists on that. This way both problems would also be solved.
But like you I like KISS, so I'd only consider these if I'm really experiencing issues.
If it was me, I would just expand your pool of IP address space for the devices that are attaching.
Note that you do expose yourself to a possible DHCP exhaustion attack using the approach you are using (and you are in a school ...). With a DHCP exhaustion attach you can download existing attack tools, and all they do is send DHCP requests using different MAC addresses until the DHCP server has no IP address space left to give out to real clients.
The second approach I would use is to just use a NAT mode SSID. With 16 million IP addresses it makes a DHCP starvation attack improbable. With the hashing method that Meraki uses with a NAT mode SSID to generate DHCP client addresses - it is probably impossible.