The name is case sensitive. Save like this "Profile.xml"   Save in this path: C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile   https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/Client_deployment#How_to_Create_a_Profile ... View more

This usually appears when, the switch receives a DHCP Client Identifier instead of a hostname, the device is behind an unmanaged switch, which can obscure hostname resolution or the network card or OS is configured to send a UUID-style client ID instead of a hostname. ... View more

It depends on your needs. This is more your choice than any recommendation. I personally prefer to use routed mode. I did use VPN concentator mode once, but that was because the customer only needed VPN functionality because they already had another firewall. ... View more

For most Auto VPN use cases between Azure and branch offices, Routed/NAT Mode is preferred because it offers greater flexibility, security, and integration capabilities. VPN Concentrator mode is more limited and best suited for very specific scenarios.   When to Consider VPN Concentrator Mode Instead? If your Azure environment already has a dedicated firewall or router handling routing and NAT. If you want the vMX to act only as a VPN endpoint, without participating in routing or security. If you need to avoid double NAT or simplify routing in complex environments. ... View more

Yes, it is a limitation; a non-Meraki VPN tunnel does not participate in AutoVPN. You would need to have a VPN tunnel with each network or use a dedicated machine to establish this tunnel and route through AutoVPN, for example, a Linux machine running Strongswan. ... View more

Yes, it is possible. There is a vast list of APIs that can be used. It all depends on whether you use the correct API and, of course, have programming skills.   https://developer.cisco.com/meraki/api-v1/ ... View more

It's a old domentation, take a look at the official documentation.   https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Setup_Guide_for_Microsoft_Azure         ... View more

No, the Meraki MX Large Essentials EA 3.0 license is tied to physical MX hardware, such as the MX105. It cannot be reused for a vMX-L deployment. The vMX appliances require their own dedicated license, typically labeled as LIC-VMX-L-ENT-xY.   Yes, you need an active Azure subscription, but no separate license from Azure is required specifically for the Meraki vMX.   vMX Setup Guide for Microsoft Azure - Cisco Meraki Documentation   The preferred mode is Routed/NAT Mode, especially for newer deployments. All new vMX instances are deployed in Routed/NAT Mode by default.   Yes, vMX-L supports NAT mode in Azure, starting from firmware MX 19.1+. ... View more

The best, cost-effective solution for your situation would be to first have a link of at least a /29, then connect your link to a switch using a port configured in an access VLAN (e.g., VLAN 999) and a port for the WAN of each MX in that same VLAN.   But keep in mind that this isn't full redundancy, because if you experience a failure in this switch, the link to both MXs fails. Not to mention that you'd also need power redundancy for both firewalls, or at least a UPS.   https://youtu.be/UHfr90en9As?si=AZSiY9LfxummiXUY     ... View more

Yes, this is supported regardless of the model. https://community.cisco.com/t5/security-knowledge-base/how-to-integrate-meraki-networks-with-ise/ta-p/3618650#toc-hId-1281948796 ... View more

The full CLI access does not always get unlocked even when “Device Configuration” is selected, in some cases, you must involve Meraki support (you have already done that).   So I think the best option for you is to call Metaki support. ... View more

Ensure the following outbound ports are open from the switch to the cloud.   TCP: 443 UDP: 7351 ICMP ... View more

As far I know the network objects are only supported on the MX    https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Network_Objects_Highlights ... View more

I think I found the explanation.   For example, if a client device's radio receives a signal at -75 dBm, and the noise floor is -90 dBm, then the effective SNR is 15 dB. This would then reflect as a signal strength of 15 dB for this wireless connection.    https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Signal-to-Noise_Ratio_(SNR)_and_Wireless_Signal_Strength   But 137db is still unrealistic. ... View more

I'm thinking here, could 137 dB represent total gain (for example, sum of antenna + amplifier gain), but not the received signal? ... View more

I'll be honest, I don't remember why in Meraki the value is displayed in dB. 😅     ... View more

That’s not just unusual, it’s physically impossible in the context of Wi-Fi signal strength.   RSSI is typically measured in dBm, a logarithmic unit that expresses power relative to 1 milliwatt. In Wi-Fi, RSSI values are negative, ranging from around -30 dBm (excellent) to -90 dBm (very poor). A value like 137 dBm would imply a signal strength far beyond any realistic or safe transmission level, it’s likely a misinterpretation or bug. ... View more

Take a look at the link I sent you.   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies     ... View more

You need to specify the destination for Any. ... View more

Try some think like this.     ... View more

Please share the rule that you have created. ... View more

It is expected, albeit not explicitly documented as a validation rule. When protocol is set to "icmp" or "any", the API automatically overrides srcPort and destPort to "Any" during processing. This behavior is not flagged as an error, and the request returns a 200 OK with the modified rule.   If you need stricter validation, you might consider implementing client-side checks before sending the request or I suggest you open a support case.     ... View more

Packet Capture Steps Navigate to: Network-wide > Packet Capture Select MX Appliance and choose WAN Interface.   Configure Capture: Protocol: Select UDP and ESP (or Any if unsure). Host IPs: Enter the public IPs of both MX devices. Port: Use 500 and 4500 (for IPsec/NAT-T). Duration: Set for 60–120 seconds during active traffic.   Start Capture on both MXs simultaneously. Initiate Traffic: Send pings or data across the VPN tunnel during the capture window.   Download PCAP Files from both devices.     https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview ... View more

The non-Meraki VPN tunnel works without issues behind NAT (I've used it myself at home). However, as you mentioned, you need to check if the device in front of Meraki (I believe it's the ISP's router) allows this. If you don't have access to the router, I recommend contacting your ISP. ... View more