Meraki

alemabrahao

As mentioned by GIdenJoe, you need to consider site-to-site traffic as a separate ZONE. Generally, site-to-site VPN rules are applied organization-wide, across all VPN-enabled MX devices. VPN Firewall Rule Considerations When configuring VPN firewall rules, it's important to remember that traffic should be blocked as close as possible to the originating client device. This reduces traffic in the VPN tunnel and results in better network performance. Therefore, site-to-site firewall rules are only applied to outbound traffic. Thus, the MX cannot block VPN traffic initiated by IPsec VPN peers. https://documentation.meraki.com/MX/Design_and_Configure/Configuration_Guides/Site-to-site_VPN/Site-to-site_VPN_Firewall_Rule_Behavior Note - Site-to-Site Firewall Rules Behavior when Group Policy is Configured If Site to Site Outbound Firewall Rule allows and Group Policy L3 denies, traffic will be denied. If Site to Site Outbound Firewall Rule denies and Group Policy L3 allows, traffic will be denied. If Site to Site Outbound Firewall Rule denies and Group Policy whitelisted preset is configured, traffic will be denied.

alemabrahao

That's correct, that Group Policy was applied to the LAN and not the VPN. Since you blocked ICMP on the LAN for a specific source and destination, it's being blocked, but not by the S2S VPN rules, but rather by layer 3 rules. Take a look at this document. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Using_Layer_3_Firewall_Rules

alemabrahao

You need to consider the number of users behind the vMX who are using Umbrella for DNS resolution. Umbrella uses the concept of roaming clients, network devices, and virtual appliances to track and enforce licensing. Even if you're not deploying Umbrella agents on endpoints, Cisco expects you to license based on the actual number of users or endpoints protected. FAQ: Umbrella Licensing and Account Provisioning - Cisco

alemabrahao

For S2S VPN ACLs, no. Group policy ACLs are for LAN L3 rules.

alemabrahao

There is no hard published limit by Meraki, but performance and manageability can degrade with a large number of rules. In practice, hundreds of rules can be configured, but Meraki recommends keeping the rule set as lean as possible for optimal performance and easier troubleshooting. Not to mention that I've personally experienced a few cases where, when working with templates, the settings took a long time to be replicated to the MX records within the template.

alemabrahao

Yes, I understand your question, and what I'm saying is that the tool is not yet reliable; it needs improvements. 😉

alemabrahao

The tool is still under development and needs improvement.

alemabrahao

Do you want to update the email you use to access the Meraki dashboard to manage your organization? I don't believe support will be able to help you with that; for this reason, it's always recommended to have more than one organization administrator. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Global_Overview#:~:text=set%20of%20credentials.-,Initializing%20the%20Global%20Overview,is%20a%20change%20in%20personnel.

alemabrahao

I don't know if support will help with this case, I don't think so, but it doesn't hurt to try.

alemabrahao

The Catalyst Center has the same level of visibility, and even a little more. 😊

alemabrahao

I'm not sure, but you could try this syntax. https://api.meraki.com/api/v1/networks/L_609111849601866880/events?productType=wireless&includedEventTypes[]=8021x_eap_success&occurredAfter=2025-10-28T23:08:00Z&occurredBefore=2025-10-28T23:13:00Z I haven't had time to test it.

alemabrahao

Sorry, I forgot to mention that the frame rate is based on video quality and resolution.

alemabrahao

Try this. https://api.meraki.com/api/v1/networks/L_609111849601866880/events?productType=wireless&occurredAfter=2025-10-28T00:00:00Z&occurredBefore=2025-10-29T00:00:00Z

alemabrahao

These per-device policies are not reliable; I suggest you apply the policy directly to the MX VLAN interface. When a group policy is applied to a VLAN, that policy becomes the new "network default" for any other group policies applied to clients in that VLAN. Since this policy is the new "network default," the client devices will still show a "normal" policy applied under Network-wide > Monitor > Clients. For example, a group policy named "Guest Network" with more restrictive layer 3 firewall rules than the network-wide configuration is applied to the guest VLAN, and a second group policy "Low Bandwidth" has a custom bandwidth limit, but is set to Use network firewall & shaping rules. If the Low Bandwidth group policy is applied to a client on the guest VLAN, the client will use the layer 3 firewall rules configured on the Guest Network group policy, not the network-wide layer 3 firewall rules configured on the Security & SD-WAN > Configure > Firewall page. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies

alemabrahao

Your link is experiencing some loss but is not completely out of service. Try disabling load balancing and forcing traffic to go only through WAN2.

alemabrahao

Try printing the repr(identity_raw) to see the exact string, including hidden characters. To isolate the issue from your script, try querying the API directly using curl or Postman for the same network and date range. This can help confirm whether the API is returning the event for user at all.

alemabrahao

Add a debug print for the full event object when identity is missing or doesn't match. You're normalizing the identity by stripping the domain and lowercasing it, but if the event doesn't include a domain or uses a different format (e.g., DOMAIN\username), this could cause mismatches.

alemabrahao

Cisco/Meraki devices are indeed compatible with third-party SFPs; I've used them in several projects and never had a problem. What model/vendor of SFP are you trying to use?

alemabrahao

What are the frame rate, bit rate, and resolution settings on your cameras?

alemabrahao

I understand, but something that would worry me more than the settings in this case would be losing access to the dashboard and not being able to unclaim the devices to add them to a new organization if necessary. Don't you think?

alemabrahao

Even if you make a backup, not all settings will be restorable via API. There are other ways to prevent someone from improperly accessing your dashboard, one of which is to enable multi-factor authentication and use strong passwords. It may not guarantee that no one who shouldn't have access will be able to access it, but it certainly makes it much more difficult.

alemabrahao

To be honest, I think it's unnecessary, unless you want to move to a new organization. Another thing you can do is simply clone a network, or even use templates for most things. https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Cloning_Networks_and_Organizations_in_Dashboard https://documentation.meraki.com/General_Administration/Templates_and_Config_Sync/Managing_Multiple_Networks_with_Configuration_Templates

alemabrahao

You can customize the HTML. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Customizing_the_Splash_Page

alemabrahao

Yes.

alemabrahao

No, As you can see in the images I sent, you can separate the ports by commas and create objects for the IP or name of your servers. But, for UDP and TCP you need to create separate rules.

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges