Blocked clients still getting DHCP (and DNS)

[Trooper]

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?

[BrechtSchamp]

It is normal behavior, and documented.

See here:

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

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.

[Trooper]

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:

• Firewall rule applied to block all communication with other devices on the Network
• (Only applies to traffic that traverses the Cisco Meraki Device that has the block is configured)

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.

Thanks again.

[BrechtSchamp]

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:

• Blocked Splash Page will be displayed when user tries to load a web page

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.

[NolanHerring]

If your using an open authentication SSID, are you able to utilize the NAT mode for that SSID (instead of bridged).

This would solve the issue with DHCP scope being too small. Or just make it larger.

Once a client is blocked, they'll get that message and they shouldn't be able to do anything.

[PhilipDAth]

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.