Meraki Firewall Group Policy Issue - Deny Any

[EthanVerhoff]

I am in desperate need of some help

Goal:
We want all "Lab Devices" on our Vlan6 to be explicit deny ALL rule to not let any traffic IN or OUT unless specified. Any device found on VLAN6 should be a "Lab Device." (Meraki Default rule is Any Any Allow for Group Policy) We will need to whitelist some HTTPS addresses in order for certain things to work on this network like Azure AD login and other things.

Background: We currently have a group policy thats applied to VLAN 6. (Group Policy takes precedent over any Firewall Policy. ) Group Policies are applied in two ways. First it checks the Layer Three Rules. If there is a match it will stop processing future rules. If no rules match it will eventually hit the DENY any any rule. And basically will never hit the Default Any Any Allow created for Group Policy.

Then the layer 7 Rules will be hit.
We say in this rule deny all web traffic (Appended) unless specifically specified in the whitelist.

This also seems to be what is recommended as well but does not work in practice due to the issue below. Layer 3 Rules (Can Provide Picture) Layer7 Rule (Can Provide Picture)

Issues:
Because we need DNS traffic port 53 and HTTPS Traffic port 443 in the Layer 3 Rules. Its finding a match for the DNS Rule rule and then failing to process any other rule in the list (This is whats expected apparently in the document "Using Layer 3 Firewall Rules") This results in us being able to see the DNS name but not actually browse to the site, We attempted to correct this by specifying the port 53 and 443 within the same rule entry but Meraki will not allow us to save when its formatted like this. In Meraki policies, its my understanding that once a Rule is met it will stop processing further rules.

[RaphaelL]

Hi ,

Your DNS flow ( UDP 53 ) is a different flow from TCP/443. Different flow means they each need to be processed and match some rule. 

Where is that GP applied ? On a client connected to a MS , MR , MX ?

[EthanVerhoff]

Hi RaphaelL!

I thought that was the case as well but when I would Ping I could resolve the hostname but not ICMP (Because I know that would require another rule)

When I would attempt to go out to one of the whitelisted sites the page would just sit like it was going to load content but would never deliver any. 
We tried Mutiple whitelisted addresses during our testing. 

GP Is applied at the Vlan. 
Clients are connecting via MS and MR(AP's) All Uplink to a MX

[RaphaelL]

Got it. 

Do you have a MX with a recent firmware ? if so can you try the live firewall log : 

It might help.

[EthanVerhoff]

Didn't know this existed! 


Great call out! I am running a trace on it now. Running MX 18.211.2 on the MX105

So it sounds like to me the first rule in the group policy hits based on port/destination combo will be evaluated and subsequent rules will not. 

Every Port 53/443/80 ECT is a single stream. 
When a Destination + Port combo is matched then any subsequent lower rules never get seen.


I see 80 traffic being blocked but I dont see 443 so per the Group Policy it looks correct. 
I am having someone check to see if an approved domain actually returns the webpage on the client.
Will message back again shortly. 

[rhbirkelund]

The rules are a top-down, until there's a match. It doesn't process any other rules. So if your traffic matches an allow rule earlier, it stop processing from there.

You might also want to match on DNS over TCP, as I think Chrome may fallback to TCP is UDP doesn't work. I'm not completely sure though.

[EthanVerhoff]

We had UDP listed as DNS Sec uses UDP 443.
We moved the alert prio so TCP traffic is evaluated first but I dont think that will matter since they are two different streams and dont match as TCP and UDP traffic is seen differently. 

We were able to use this MS article to whitelist the addresses needed and now attempting to do one off service troubleshooting. 

Microsoft 365 URLs and IP address ranges - Microsoft 365 Enterprise | Microsoft Learn
There is a JSON in this that we parsed with all MS service URLS

I believe that we got this to work however will be testing further towards the end of this week. 

If its solved Ill make sure to give you credit!

Cant thank you enough for your help thus far! 

[PhilipDAth]

What about forgetting about using L7 for this and converting those L7 rules to L3 rules?  You can create FQDN rules.

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Using_Layer_3_Firewal...

[EthanVerhoff]

I looked at doing this, Within the GP you only get a deny option listed.
We would need to work off a whitelist instead of a blacklist for this sort of functionality