Hi Meraki expert friends!!
I'm trying to properly isolate some VLans in this specific customer's network.
The basic of the system:
MS250s and MS120s
VLANS: (don't judge, I didn't set this up, lol)
1 - AV
8 - Staff
12 - Guest
24 - Kids
32 - Video
45 - Camera Control
55 - Lighting
I will be combining some of these as soon as I can test functionality.
Now for the real question:
If I created SSID L3 rules to Deny Local Lan on a specific SSID, does that supersede any L3 rules in the MX?
SSID - Staff has Deny Local Lan, but I wanted to allow connection to a specific device on another VLan/subnet
If I set up a MX rule to Allow - 10.x.x.x/24 source to 10.x.x.x/32, would that work? or would it still be blocked by the SSID rule?
Thx. and my apologies if this is a dumb question.
If I understand correctly, yes they will supercede. The firewall rules under Wireless are enforced on the AP directly, and the rules under Security are enforced on the MX. So if you block something at the AP it's blocked there, and the MX never sees that traffic.
And to add one more thing, this is what deny local LAN blocks:
Thanks for your help.
So, if this is correct, I will then only do my L3 rules in the MX to prevent unwanted restrictions.
I know that, in the MX firewall rules, the rules are applied in the order of appearance. With that in mind, if I'd like a specific subnet to have access to specific IP adress, but nothing else, what would be the proper rule?
Can I do deny all, then allow only one IP address? Example:
Allow 10.0.12.0/24 to 10.0.1.100/32
deny 10.0.12.0/24 to 10.0.1.0/24
Or would I have to create two deny rules:
deny 10.0.12.0/24 to 10.0.1.0 to 10.0.1.99
deny 10.0.12.0/24 to 10.0.1.101 to 10.0.1.254
Or am I overthinking this?
Good plan. If I have an MX available my preference is to use the MX for rules and not the AP.
Your first example is correct. You have to keep in mind that Meraki has a "permit everything" rule at the end you can't change.
So your approach should be allow as specifically as you can, and then block broadly everything else.
Your second example would likely work, but from an administrative point of view it's harder to read and understand, and more prone to errors if modifications are needed. Especially if it's not you in the future making changes.