MX Group Policy: VLAN ACLs

[Miyo360]

Hi,

I have an MX84 acting as the router/gateway in a small network. I'm splitting out what is a flat network into VLANs (servers, workstations, printers, voip, etc) and needs some ACLs to control what traffic is allowed between VLANs.

On the face of it, group policy seems a neat way to do this, rather than filling up the appliance L3 firewall rules with dozens of rules which may make it hard to review later. However, I'm confused as the group policy rules don't contain a source address field - I understand it is implied that the source is any device which the policy is applied to.

Assume I want a individual workstation in the workstations VLAN to have just SSH access to an individual server in the servers VLAN, can I achieve this with group policies? 

If not, what are the use cases for the L3 firewall in GPs?

Many thanks in advance.

[CptnCrnch · Accepted solution]

There's one big difference with L3 rules compared to Group Policies:

L3 rules are stateful (return traffic is automatically allowed) - Groupd Policies are not. Therefore, your best option is going the firewall route.

[Crocker]

It took me a little while to get my head around the behavior of Group Policy Layer 3 Firewall rules. In our case, we migrated from Cisco ISR 4321 + Cisco Catalyst 2960 hardware to MX67/MS120's. In the old setup, the SVI's were defined on the Catalyst and each SVI had an inbound/outbound ACL that had ACE's to only allow the conversations we wanted to allow. We attempted to recreate that with Meraki gear, but with the SVI's defined on the MX67 and the group policies filling in for the ACLs. Note that we also use full-tunnel Site-to-Site VPN between our remotes and our datacenters, which introduces some caveats. In a nutshell:

The group policy Layer 3 Firewall rules do not block traffic inbound to a client in the VLAN, only traffic outbound from a client in the VLAN. Say you have a simple policy applied to VLAN 100 (and the subnet associated with that VLAN is 10.10.20.0/24) that permits SSH to 10.10.10.35 and blocks all other traffic.

Anything on your network is going to be able to send packets to 10.10.20.0/24 clients (and the clients will receive these packets) using whatever protocol/port they want; However, the group policy will block response traffic that doesn't match the permit. You can verify this with a packet capture either from the MX or on the client itself.

While this works to block unwanted conversations, it does not block unwanted packets the way we were used to. We didn't like that packets were getting to clients that shouldn't have been, even if the outbound packets were getting dropped so no real communication occurred. We ended up reworking this to nix the group policy firewall rules entirely, instead using a combination of Layer 3 firewall rules + Site to Site VPN firewall rules.

[Miyo360]

@Crocker thanks for the detail - this is really helpful. Guess I'll stick to L3 firewall rules then.

Are you using the recent Network Objects feature with L3 firewall rules? It seems using groups of objects could consolodate some of the similar firewall rules we have and make the overall 'readability' of the rules easier to review.

[Crocker]

Yeah, the Policy Objects/Policy Object Groups are a lifesaver for that exact reason. Even though they're marked as a beta feature, I believe several folks are using them successfully. We haven't seen any problems with them either - they behave exactly like you would expect. That said, we do back up the policy objects, policy object groups, and site to site VPN firewall rules daily using API calls...just incase.