Organization Wide Group Policies improvement proposal

GIdenJoe
Kind of a big deal
Kind of a big deal

Organization Wide Group Policies improvement proposal

Hey all, this is me with another org wide group policy post.
I really like the idea of the feature but it needs much more work to be truly useful.

I have already made a feedback post so that part is covered, however here I can add some graphics to improve the ideas I want to convey.

So without group policies I structure my ruleset as follows:

 

Classic-ruleset.png
As you can see in my example here I have clearly delineated areas.
1) InterVLAN rules sorted per source VLAN, ending in a DENY RFC1918

2) General local to internet rules where there is 1 rule per application containing all the source VLANs allowed to take part in this allow rule, ending in a DENY ANY.

However if you want to expand this to multiple sites where you usually have the same kind of source VLANs like clients, printers, collab screens, guests, etc you bump into problems.

In org wide policies you create a ruleset that is scoped to specific source VLANs.  So at first glance this would be an ideal solution to expand my screenshot above to 100+ sites.  However there are a few major issues that make it impossible to do this.

 

To simplify the explanation I will leave out any L7 rules and purely concentrate on the basic L3/4 firewall ruleset.


The rule ordering has been taken away.  And rules now are ordered this way:
1) Explicit DENY rules
2) Explicit ALLOW rules

3) Default action (where only either RFC1918 or ANY can be selected)

See example belowexample-policy.png
Here you can see that the DENY all has been selected and manual RFC1918 objects have been placed on top.

 

Meraki also does some unwanted handholding by adding their IP's to allow to to make sure your Meraki devices always can reach dashboard even if they land on a VLAN that has a policy scoped on it.

This can work fine for VLANs that don't require local VLAN to VLAN configuration since you can just block the RFC1918 ranges above and only allow the ports you want.

Alternatively you can make a policy that just adds allow rules for local and internet destinations and ends with a deny RFC1918.  However this leaves you without a DENY ANY at the bottom so the VLAN can reach unwanted ports on the internet.

In following screenshot you can see I tried to add a local allow but the automatic ordering put it BELOW the deny rules making it never match.
Test-allow-local.png

This then causes the rule to order incorrectly:

Btw don't mind I'm using management VLAN for this since I didn't want this network to have other issues.

Test-allow-local2.png

 

Secondly another issue is that in the rulemaking you can add destinations in the form of IP's, VLANs, objects and object groups.  
Rule-destination.png

The issue with this is that you either have to keep adding destination VLANs from multiple locations if you add locations later or that you have to add every destination VLAN in an object group but this I think will cause too many destinations to be added to every group policy on every branch location.

The solution could be as simple as to create a "destination scope" where you can add in all destination VLANs and add that are referenced in there and just like the regular scopes only the locally significant VLAN for that MX will be placed in the destination IP range for that rule.

Secondly instead of only having the option to choose either deny RFC1918 or deny any, you should have an option for both.  Where rules with destination VLAN scopes are placed in the first location followed by the deny rfc1918, then followed by the other rules followed by the deny ANY.

 

I hope some Meraki employees read this and share this with the development team.

0 Replies 0
Get notified when there are additional replies to this discussion.