This looks like AutoVPN issue based on the 'Meraki VPN' field, IKEv2 based negotiation would be for IPsec or Non-Meraki VPN tunnel. ... View more

Hi @HarleyPhreak,   The first thing that comes into mind with VPN tunnel connectivity flaps is intermittent packet loss or congestion in the internet pathway between the peers. Check if there is an indication of this in the default ping to 8.8.8.8 under the uplink tab in appliance status of the peers. Also consider adding a connection monitoring ping to public IP addresses of peers to see if there is a correlation between loss and latency at the timestamp when tunnel changes occur. ... View more

Hi @RahulPrasadh,   Yes, that should do it. You can also add custom expressions for a more specific set of IPs or subnets. ... View more

Hello @MyronW,   Packet captures can be taken from the dashboard by going to Network-wide > Monitor > Packet capture page. You'd need to capture it on the WAN interface—more details are below.   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#WAN_Appliances_and_Teleworker_Gateways ... View more

Hi @nikovalchanov,   What is the link negotiation speed of WAN 1? If you hover around the WAN port it will show you the current speed. If the negotiation is downshifted to 100 Mbps for some reason you might see a drop in throughput, so I would start with tshooting Layer 1 first. Also, questions from @double_virgule will help isolate the issue further. ... View more

Hi @mdubs91,   The banner is simply alerting you that MX local VLAN subnets overlap with Non-Meraki peer Azure which is configured with a default route 0.0.0.0/0 on MX VPN config, this will cause all traffic (including internet) from VLANs taking part in VPN to go over the full tunnel to Azure. If this is your intended design to tunnel all traffic to Azure then that banner will be there for alerting purposes.   Making changes to any routing configs to MX subnets like anyconnect routing for example will cause NM VPN tunnel to reinitialize hence you might see the drops for full tunnel traffic.   Is Azure peer supposed to share a 0.0.0.0/0 subnet? If not, it's better to only have IPsec SAs between specific subnets that you want to reach from MX to Azure instead of tunneling all traffic. This will get rid of the banner and network connectivity drops.       ... View more

Hello Guerino,   Flashing/blinking green and red LED is not mentioned in the normal LED indicator operation section in the datasheet. An NSE should be able to assist further on the Support case you opened. https://documentation.meraki.com/MR/MR_Installation_Guides/MR33_Installation_Guide#LED_Indicators_and_Run_Dark_Mode ... View more

Hi @40mb,   I agree with @DarrenOC, if you are making changes on the MX WAN interface for its management DNS servers it should not affect clients' DNS. Keep in mind that, if you have your DHCP scope set to Proxy to upstream DNS, clients with existing DHCP lease will get the updated DNS server when they renew their lease and new clients will get updated DNS servers immediately with the new lease.     ... View more

Hi @Hmuet,   I agree with @ww, the firewall rule is based on flow hence wait a 5-10 minutes after the rule is applied so that the preexisting flow expires and new ones from the client get processed by the firewall. Also, ensure the configs are up to date on the Security & SD-WAN > Appliance status page after the rule was added. ... View more

Hello @RaphaelL,   I will take back my previous response, as it does not seem we are compliant with RFC 5798 as you correctly pointed out. Thanks for that! Implementation of VRRP for HA is limited within MX product models and we don't use it for communication with another vendor for VRRP. We are not claiming that we are VRRP compliant, we just provide HA for MX and MS with our implementation. Apologies for the error everyone, I have added the feedback to the documentation already as stated earlier. ... View more

Hello @RaphaelL and @Jedediah_Jumbl,   Linked documentation is related to the switch warm spare and the mentioned virtual mac addressing scheme (88:15:44) is exclusive to switches. For MX devices virtual mac will be starting with first three octets as cc:03:d9 as mentioned earlier. According to RFC, the first 3 octets are derived by OUI, and from OUI lookups cc:03:d9 and 88:15:44 are Cisco Meraki. Hence, RFC is followed. @Jedediah_Jumbl I will add feedback in the MX warm spare KB to add that cc:03:d9 will be the starting virtual Mac address of the MX, similar to the lines that are seen in the MS warm spare KB.   ETA: This is incorrect. Please see my new response below with the correct and updated information. Thanks, and sorry for any miscommunication here!  ... View more

Please open a case with Meraki Support so they can identify and attach it to the parent bug and inform you when a resolution is available. ... View more

Hello! As stated above MR will bypass the L7 rule if there is a matching allow rule for the IP address in the L3 rule, so only wireless clients that connect to MR will be able to access the IP address.   Unfortunately, MR L7 rules don't have an option for country block, so you don't have option block Australia and then allow one IP address in L3 rules. MX L7 rules are all or nothing type of configuration, so you would need to remove geo-block for Australia which is what you have done already. However, it will be a good Feature to that will allow certain IPs from geo blocked countries, I encourage adding a feedback on the dashboard via Feedback button.  ... View more

Hello!   Do you mind opening a case with Meraki Support? An NSE can help with scoping and identifying this known issue. ... View more

Hello! If you need any assistance with packet captures and verifying tunnel connectivity, I recommend opening a case with Meraki Support so an NSE can also help with the investigation. ... View more

Hello! Please have a look at the configuration article below to confirm roles are created for each device type as required. E.g, you can add a role for switch event logs and make changes like cycling a port to see if syslog gets generated and gather packet capture to confirm.   https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration#Configure_Dashboard   Further, are you able to ping the Syslog server IP address? This is just to ensure network connectivity. I recommend opening a case with Meraki Support or calling us so an NSE can help with troubleshooting your issue effectively. ... View more

@Alain_Bensimon Have you tried using servername.domain.local (fqdn)? Or are you using servername? ... View more

@Alain_Bensimon Curious to know if you can ping the DNS sever from the client VPN host and what packet captures taken on the client vpn interface show when you are trying to reach via hostname. Also, check if the local firewall on the DC is blocking non-local subnets like 10.69.69.0/24. ... View more

Hey Boyan,   You are correct, the license will apply to the entire organization.   Once you add in the enterprise license for SM (for activating new features) in your organization it will automatically upgrade the entire organization from Legacy to Enterprise and the process is irreversible.    To answer your question, you cannot add paid licenses without converting. Legacy and Enterprise models will not co-exist in an organization.   You can create a new organization and apply the paid license to the new org. After that, move (re-enroll) devices that need to use the enterprise features to the new organization.         ... View more

Greetings,   Client IP conflict events cannot be disabled. These events are generated if the MX has observed traffic from multiple MAC addresses, using the same IP address.     ... View more

Greetings,   The VRRP MAC address (virtual mac address) is used by both MXs in the HA pair and will be a part of the VRRP process. LAN of both MX will use this virtual mac address instead of a physical MAC address. The First 3 octets for the virtual mac address will be "cc:03:d9" and is based on Primary MX.   The VRRP MAC address is shared by both MXs for LAN communication. Clients on the LAN will associate this shared MAC address with the MX's LAN IPs. As such, in the event of a failover, LAN clients won't need to update their ARP table with a new MAC address.          ... View more