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. ... View more

We're also semi affected on n426.meraki.com. No errors (yet) but we're getting that behavior where the dashboard doesn't fully load when trying to navigate around - for example, the left-hand nav menu is missing 9/10 times on refresh. Started for us at about 3:00 PM Central. ... View more

Got one opened not long after my post. Support is running some examples up to the Devs, will follow-up if/when they provide more info. ... View more

I've noticed the same thing. The change alerts for devices still identify the admin that made the change, but change alerts for MS (at least, for MS120 series which is all we've got) devices do not.    Going back through our change alert e-mail history, changes on MS devices identified the admin up till at least 12/14/21. There's a 14-day gap where we didn't make any switch changes, and then the next change alert was on 12/31/21 which does not identify the admin. All change alerts after this point do not identify the admin responsible for the change.   Edit: Reviewed the Organization -> Change Log entries, these do still identify the admin responsible, so the information is at least available. Would be nice to have it back in the change alert e-mails though. ... View more

Hopefully it's just a speed/duplex issue, we've seen this a couple times with our MX's that connect to CenturyLink or AT&T ONT's. We've had to go manually set the ports to 100/full or 1gbps/full, depending on what the carrier specifies. ... View more

I'm a little unclear on the last part of your post. Have you run a speed test over the new BT connection without the MX and gotten the expected speeds?   Any chance the ports are auto negotiating to half duplex when connected to the ONT? ... View more

Update!   I bounced this question off of our Meraki rep, and Support as well. Support also said there's no way to get this info; However, our Meraki rep clued us in on what is apparently a well hidden feature. There's an ability for Support (whether they know it or not) to enable configuration of SNMP traps from the dashboard for login attempts.   They can toggle that on and expose some configuration options (which you control) that will allow the Dashboard to send SNMP traps to your collector's public IP.   I'll follow-up once we've gotten everything configured and seen what it can do.   Login Attempts page with new option after support enabled it:   Trap configuration options (v1/v2c also available):   ... View more

Thanks, just wanted to confirm I wasn't overlooking something obvious! ... View more

Yeah. Our Meraki deployment doesn't make use of config templates - most networks were stood up using the Clone feature, then tweaked for the specific needs of a given network; However, not all were cloned from the same base network so there's quite a bit of variation across the environment.   A simple example is that we want to disable the Local Device Status page across the environment, only manually enabling it when we need it. In the dashboard, I've got no way to tell it "Go turn this setting off everywhere".   Another example would be the layer 3 firewall rules. We're currently building three rulesets, and one of the three rulesets will be applied at all locations depending on the needs of the location. The rulesets are aimed at separating ~10 vlans per location from eachother. We've got no good way, via the dashboard, to roll that out - in our team of 3 techs, trawling through ~150 networks and manually creating several rules at each isn't a great experience. Even if we were to work through and manually build the rules at each site, the dashboard doesn't provide a good method for ensuring the rules were built correctly or applied at each site (audit/compliance needs). ... View more

So I started noticing this a couple months ago - or, more specifically, noticing that it was becoming much more prevalent. We've been using Meraki equipment for ~2 years now, slowly replacing EOL Cisco routers with Meraki MX's wherever feasible. Since the start, I would occasionally see "GUID/UUID" type names for clients.   I'm not certain exactly when the GUID/UUID type names became the norm vs. the DHCP names, but it is "recent". I started poking around at this specific issue a couple days ago and like others in this thread, opened a case with Meraki support and got the same response outlining the priority list for client names.   EDIT: The prevalence of this issue coincided with a 2-3 month push to swap to MSEdge vs. Internet Explorer. The handful of GUID/UUID type names prior to this push most likely came from those folks using Chrome as their daily driver.   I then ran a couple packet captures on some LAN interfaces to capture the mDNS traffic, lo-and-behold, I saw workstations responding to mDNS queries with GUID-like names. Did some more poking around and found some info from ~2019 describing how WebRTC was being changed to use/respond to mDNS queries.   mDNS - WebRTC Glossary PSA: mDNS and .local ICE candidates are coming • BlogGeek.me   I'm no guru on web-dev-speak, but as I understand it...Chrome & Edge will spin up a UDP 5353 (mDNS, Bonjour) listener and respond with a randomly generated ID if it hears a query. You can see evidence of this yourself by viewing listening ports (resource monitor -> Listening Ports) on any Windows 10 workstation running Chrome or Edge.   So...it's not technically a Meraki problem. It's a Chrome/Edge/WebRTC problem (not sure if it affects firefox).   I think the long-term fix is going to be for Meraki to allow us to pick the order/preference for client name resolution. Not sure how realistic that expectation is, but I've submitted some feedback requesting as much. ... View more

One thing to note here. If this traffic is flowing over a Site-to-Site/Meraki AutoVPN, the cellular FW rules will not have any effect. ... View more

This appears to be the correct answer, Meraki's network objects/object groups is the saving grace.   Previously, technicians had attempted to use the Layer 3 firewall rules but got hung up on the fact that those rules don't affect S2S VPN traffic and thought they would have to create all the rules 2x. After some thinking, reading, and some testing we ended up with the following (high-level) approach:   Enable Policy Objects (Beta) - there's a gotcha here where if you have too many objects in a group (or too many objects in general, I'm not certain) they won't all display in the Dashboard UI. The full list can be retrieved via the API though so it's no big deal Create an object for each subnet, done via API scripting As a side note, it would be nice if each object didn't need a 'name'. If no name is provided, the subnet address should be assumed as the name vs. requiring us to specify Create an object-group for each 'segment' and fill with individual objects belonging to that segment. For example the ~150 enterprise workstation subnets from my first post go into the EnterpriseWorkstations object group. Add objects to object-groups in order to control deployment Build S2S VPN firewall rules using the object-groups as the source/destinations. This reduces the # of individual rules by a vast amount, making them easier to visualize/review. Create 'default deny' rules for each object group where applicable (for the Phones or Printers object groups, as an example), factoring in the implicit allow at the bottom of the S2S VPN firewall ruleset On the LAN side, the ruleset is standard accross the board. Powershell script to poll each 'network' for local LANs, and splat in the ruleset for each local LAN. For example don't let the Phones subnet talk to the Printers subnet, etc. Nix the Layer 3 SVI Group Policies at each site as deployment rolls forward   This seems to be working just fine at the five locations I've migrated to the deployment described above. Unsure what performance constraints I may see (particularly at the VPN Concentrators) as this moves forward. Will follow-up if I stumble across anything. ... View more

We struggled with this as well.   What we ended up doing was just enabling it as @SahandC mentioned, but disabling the e-mail alerts out of AirMarshal/Meraki dashboard. We then built specific rules in our Syslog server (Solarwinds, in our case), to fire e-mail alerts when a spoof syslog was received for a specific SSID. ... View more

@Inderdeep Excellent, thanks for summarizing! ... View more

@Inderdeep Thanks for passing that along.   I guess I should clarify what I'm asking. All of our MX/Z3 devices are running MX14.51, at some point soon we're going to want to update to the latest stable release (15.42.1).   I want to review all of the changes, enhancements, and gotchas between those versions - preferably in one place vs. going through every set of release notes between 14.51 and 15.42.1. If there is a way to do so, that is. ... View more

My favorite part is that there's no way for us to audit this stuff over time. Support doesn't appear to have an easy way to do this either - try asking some time. ... View more

Yep! ... View more