Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About EthanVerhoff
EthanVerhoff
Just browsing
Member since Jan 14, 2025
Jan 16 2025
Community Record
5
Posts
0
Kudos
0
Solutions
Badges
Jan 15 2025
5:46 AM
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!
... View more
Jan 15 2025
5:39 AM
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
... View more
Jan 14 2025
11:38 AM
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.
... View more
Jan 14 2025
11:13 AM
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
... View more
Jan 14 2025
10:48 AM
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.
... View more
Labels:
- Labels:
-
Firewall
© 2025 Cisco Systems, Inc.
