The Non-Meraki VPN tunnel will only be established between the Active WAN interface and the configured non-Meraki VPN peer. Typically, the WAN1 interface is the Primary interface, and assuming it is up, it will be considered the active interface, and the Non-Meraki VPN tunnel will be established over WAN 1 only (Port 3) and not WAN2 (Port 4). The MX will try to establish the VPN tunnel to the Non-Meraki Peer if WAN1 fails or if WAN2 is the Primary connection. You can change which WAN interface is the Primary interface on the "Security & SD-WAN > Configure > SD-WAN & Traffic Shaping" Page.  ... View more

I Agree with @Brash . It looks like a Layer 1 issue. Have you tried different ports on the Cisco c9300 and on the MX100?  ... View more

Access Control for VPN connections is handled via IP addresses or subnets, not MAC Addresses.   That said, you can use MAC-based access control to restrict access to the Local Network included in AutoVPN. If not allowed, the client will be blocked at the local network level and prevented from accessing anything.  https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X)   https://documentation.meraki.com/MS/Access_Control/Configuring_Microsoft_NPS_for_MAC-Based_RADIUS_-_MS_Switches   ... View more

The Client VPN Process will drop the flow if the packets are not Legitimate IKE packets or if IKE Authentication fails.    With respect to your second point, the behavior is constrained by the Architecture.   ... View more

I highly encourage you to use the "Give Your Feedback" feature on your Meraki dashboard to share your suggestion. User feedback is greatly valued and often carries more weight than that from the Support team.   Give your feedback (previously Make a Wish) - Cisco Meraki Documentation   ... View more

This can be caused by AMP's inability to connect to AMP cloud. This will cause all AMP inspected file downloads to be blocked unless AMP is manually disabled.   Most likely culprit is a firewall issue, or a DNS issue preventing the MX from resolving AMP Cloud hostnames.      ... View more

This is the Scenario that you are most likely experiencing.    Meraki MX appliance received packets from the source IP address 95.214.52.173. The packets were copied to the IDS process for further analysis. The IDS flagged the flow as potentially harmful, as it matches the pattern of a known attack vector. Before the IDS could take preemptive action to drop the flow, the Meraki MX's inbound firewall rules had already dropped it. In your case, if it was enabled, Client VPN could've been the process that dropped the flow as the destination port is port 500 As a result of the firewall's prompt action, the IDS process could not apply its own measures, which is why the Meraki Dashboard indicated the action as "Allowed." It is important to note that despite this indication, the flow was effectively blocked by the MX. Key Takeaways: The swift response by the firewall prevented any action from being required on the part of the IDS. An "Allowed" status on the Meraki Dashboard could sometimes mean that the threat was blocked by other security layers, not that the traffic was permitted through the network.   ... View more