Hi everyone!   @RahulPrasadh , I recommend you read and understand this document before reading the other one @Mloraditch mentioned.   @RahulPrasadh , regarding local-ID: this is only available if the VPN is using IKEv2; this is optional but if you don't specify then MX will send "real IP" configured on that WAN interface.   Example: Suppose your MX has two WAN uplink interfaces and each one is connected to a ISP router that does NAT. So something like this: -> WAN1 IP 192.168.0.11 (real IP) and Public IP 11.0.0.11 -> WAN2 IP 172.16.0.22 (real IP) and Public IP 22.0.0.22 -> VPN peer IP 3.3.3.3   In this example, If you don't configure local-ID then MX will send 11.0.0.11 over WAN1 and 172.16.0.22 over WAN2 to the VPN peer when negotiating IKEv2 tunnel.   You can learn more about all the non-Meraki settings here.   On another topic, IPsec over VPN is a really cool feature! Thanks for bringing this up, @Mloraditch ! This feature offers new network design opportunities and I was particularly waiting for it.   I say this because I used to work with AWS before and their VPN service always has two endpoints and then AWS used to generate a lot of emails warning customers that they don't have redundancy configured.   So it was only frustrating and time wasting since most customers already knew that and they also knew they couldn't configure the redundant tunnel because their device didn't support. As it used to be the case with Meraki.   But not anymore!😎 And linking to your comment, @Mloraditch , at the moment We can't bind the tunnels to specific WANs. What I mean is: this IPSec over VPN feature is designed to interconnect with non-Meraki VPNs; as such, non-Meraki VPN tunnels will obey Primary WAN preference. This behaviour is documented here.   However, I believe We can have a VPN tunnel traffic engineering feature in the future if enough people make a Feature Request. To your point @Mloraditch , this would allow VPN traffic to flow on a selected WAN.   I'm particularly excited by this possibility now that Meraki supports IPSec over VPN. In order to make VPN tunnel traffic engineering possible, first of all, We would need non-Meraki VPN supporting Active-Active VPN Load Balance so BGP sessions can exist within each WAN uplink. That would give us two egress interfaces.   Next, since We have two egress interfaces, then We could fine-tune BGP settings to have a better Local Preference on a specific tunnel and also advertise certain subnets/prefixes with AS-Path prepending to influence the return traffic to flow via the same tunnel. That would be so cool! 😎   Everyone can make a feature request by going to the bottom right corner of your Dashboard and sending the request through the "Give Feedback" bubble.   Once you sent your Feature Request using the "Give Feedback", our Internal Team will process your suggestion and eventually you'll have your feature in the future. Keep in mind there will be no estimated time to implement your suggestion/feature.   Hope this information is useful. Feel free to post here anytime if you have further questions / concerns.   ... View more

@alemabrahao esta' correto! Quando o seu MX não consegue se conectar com a Meraki Cloud, o dashboard não consegue plotar o gráfico de Latência.   Você pode confirmar isso verificando a aba Summary e olhando para o Historical device data para o mesmo período no tempo. Se você ver intervalos em vermelho significa que o seu MX perdeu conexão com o dashboard (não necessariamente com a Internet).   Recomendo ler este documento sobre o Uplink & Stats: MX Uplink Settings   Como sabemos, o Historical device data mostra o gráfico de Latência e de Packet Loss com base nas respostas das "sondas" / pacotes de teste enviados pelo seu MX firewall. Os dados são enviados para o dashboard que então compila estes dados e gera o gráfico. Espero que essas informações sejam úteis. Fique à vontade para postar aqui a qualquer momento se tiver mais perguntas/preocupações.     ... View more

Yes, @PhilipDAth good point! If you change the STP type on the CORE, then it triggers STP to restart and converge again. So We would see a 30 to 60 seconds outage.   In summary: always do your changes in a maintenance window.🤓 ... View more

Hello everyone!   Hope you're doing great! That's a very interesting discussion.   TL/DR: only configure Root Guard in your CORE switch on trunk ports connecting to downstream switches; only configure BPDU Guard on ports connecting to end-user devices/hosts and never on a trunk connecting to any switch; Meraki switches can only run Rapid Spanning Tree so make sure STP types are compatible by running RSTP on all switches or tweak MSTP to be more like RSTP.   @michalc made a good point about compatibility between spanning tree types and interoperability, while @alemabrahao also raised a point to how STP is configured in Catalyst 3560.   To your point, @alemabrahao , it's true that the best action would be just to change STP type on the 3560s to RSTP so then every switch would run the same and the root election would be predictable.   However, not all IOS firmware offer you RSTP. An even more compatible approach would be to run MSTP (check if your IOS supports - most likely yes, it does). But MSTP needs some tweaks:   Single instance (0); running single instance 0 means there will be only one single STP process running in memory single region (region1), and single revision (revision 1); doing this together with step-1 basically makes MSTP behave like RSTP have your trunk ports configured as Native VLAN 1 and switch Management IP in VLAN1; you must to this because VLAN1 is used by MSTP to interact with other STP types   Making MSTP more compatible is described on section "Enable RSTP Globally" in Configuring Spanning Tree on Meraki Switches (MS).   Having said that, I want to dial back to the issue that raised @Mark-SPS 's post: "The trigger for this was that today a trunk port on a different switch went to "STP root guard activated" today."   @Mark-SPS , I need you to be careful when configuring STP Guard options. In a nutshell:   Root Guard will protect the switch from losing the STP election or changing the current Root. The way Root Guard protection does it is by transition the port to an STP-inconsistent state it the ports receives a superior BPDU (i.e. a STP management packet showing there's a better Root); the port in this state still processes BPDUs but will not learn MAC addresses or forward traffic. As a result, hosts upstream that port won't be reachable and you may lose access to your switch until the previous Root gets elected again. This is why you only configure Root Guard in your CORE switch on trunk ports connecting to downstream switches.  BPDU Guard protects the switch against "alien switches" and small loops. The way it does this is by putting port in a disabled state if it receives any BPDU at all. So if someone messes with the cables and create a loop or maybe if someone connects a hub or switch, the port would receive BPDU and then shutdown. This protection is useful when you are 100% positive that the devices connecting to this port will be only ip-phones and end-user hosts. This is why you only configure BPDU Guard on Access port type - never on a trunk connecting to any switch, as @michalc suggested. Loop Guard protects your switch from an exceptional situation where a switch believes there's a loop and starts transitioning port states and trying to check root election. It's recommended to configure this protection on redundant ports connecting to non-root downstream switches and also enable UDLD together with this.   Lastly, @Mark-SPS , you mentioned "Currently the STP Guard is disabled for these ports, as under no circumstances can these connections be blocked." I'm assuming your Catalyst 3560 upstream is your CORE switch and it has STP Root role. If that's the case here, then don't configure any STP Guard option on the Meraki switches' trunk ports connecting upstream to your CORE. Hope this information is useful. Feel free to post here anytime if you have further questions / concerns. ... View more

Thank you @PhilipDAth and EveryONE! I feel honoured and just want to do much more! ... View more

Yes, @Knowguy . That discussion is more complete. Firmware 18.211.3 don't fix this behaviour. @Tishman , feel free to post over there. ... View more

Hi @MarcW ,   Sounds like your non-Meraki peer is turning the tunnels off due to no activity.   Meraki devices send special DPD vpn packets to keep the tunnels alive when there's no traffic. However, not all VPN peers reply to DPD.   Therefore, the best way to keep site-to-site tunnels UP is generating interesting traffic - e.g.: a continuous ping from a host inside a local subnet into a destination at the other side. ... View more

Hi @BradSp    Thanks for updating us and sharing your screenshot. I'm sorry to hear that the Network Support Engineer didn't fully understand the problem you reported.   IMHO, this looks to be a dashboard delay. If the dashboard showed a different neighbour AP list and column "Last Seen" have less than 12 hours at the moment you called Support; then there might be a dashboard delay worthy investigating.   Please, send a feedback using the "Give Feedback" at the bottom right-hand corner of your Dashboard. Recommend informing the support case number as well.    Once you report this dashboard delay behaviour using the "Give Feedback" bubble, our Internal Team will process your feedback and work on it.     ... View more

Hi @RaphaelL ,   Thanks for bringing this up! I'm working with Internal Teams to get it done.   We'll update everyone here in this thread when We finish. ... View more

Hi @BradSp ,   Thanks for bringing this up.   I checked my own lab at home and Air Marshal is showing my neighbours. I've never seen 12hs delay to update the dashboard.   Perhaps you can benefit more if you open a Support case.     ... View more

Hi, thanks for checking.   If it is random, maybe it is related to firmware.   Perhaps you can try latest patch in version 18.211.3. I hope you can also upgrade your non-Meraki VPN peer.   Have you checked firmware? ... View more

Hello @Tishman    Based on what you said, I suspect your Trafic Selectors (TS ; a.k.a. encryption domain) don't match exactly.   I.e.: MX side may have a /24 subnet while the other side has a /25 ; so it works if the other side initiates because MX TS is like a summary route. On the other hand, MX initiating doesn't work because the other side has a /25 more specific TS.   You may want to double-check with the network admin at the other side and make sure both sides are configured with the exact subnets as traffic selector (TS).     ... View more

Hi @Barrowcuda    I believe you will benefit more from Meraki Network Support at this point.   Perhaps there is something We both are missing in your network topology. ... View more

Hi @Barrowcuda ,   It looks like there's a VLAN double tagging issue if you configure your Network Wide Config as "Wired clients behave as if connected to Voice VLAN".   I suspect your AP is already bridging its own LAN port to SSID Voice which is bound to VLAN269. So when it sends packets from the phone, it will forward to trunk port and add VLAN269 tag as if it came from a truly wifi client.   What happens if you configure as "Have no access"?       ... View more

Welcome, my friend! It's never late to share some knowledge! ... View more

Hi @PhilipDAth , I tested and it works. But only if you have full tunnel. Split tunnel, naturally doesn't get traffic instection.   I think it is the same logic as Site-to-Site VPN in full tunnel. ... View more

Gracias @Raul_Sanchez_G    Este tema ya tiene una solución, que es mi primera respuesta. No creo que podamos cambiarla después de que esté marcada como solución.   Gracias de todos modos. Creo que los demás usuarios del foro entenderán que mi segunda respuesta es una consecuencia de la primera. ... View more

Sí, @Raul_Sanchez_G Háganos saber si necesita ayuda para configurar L2TP o el cliente VPN de Cisco AnyConnect. ... View more

You're Welcome! 🙂 ... View more

Hi there! Yes, please let us know what you found. ... View more

Hola @Raul_Sanchez_G    Gracias por sus comentarios positivos y por agregar más detalles.   El error en la captura de pantalla puede deberse a dos problemas comunes:   1) suele ocurrir cuando su usuario remoto está detrás de un dispositivo NAT que (por coincidencia) también está detrás de otro dispositivo NAT. Como resultado, este doble NAT interfiere con los puertos UDP IPSec y, luego, su MX no puede responder a su solicitud de conexión VPN.   Este problema lo presentan muchos proveedores de Internet que hacen lo que se denomina CGNAT.   La solución o solución alternativa para problemas de CGNAT como ese es migrar a una VPN de cliente basada en túnel TLS, como Cisco AnyConnect.     2) su MacOS está realizando una negociación IKEv2 que no es compatible con la VPN de cliente. IKEv2 solo es compatible con la VPN de sitio a sitio.   La solución aquí es configurar L2TP IPSec en su MacOS. Solo asegúrate de que la configuración de VPN de tu Mac OS esté usando L2TP. Puedes consultar los demás detalles de configuración en la documentación del producto. Recomiendo leer los siguientes artículos:   Meraki Client VPN - Configuración de MacOS Apple MacOS - Configurar una VPN ... View more

That's great news @BlakeRichardson !   The "Give your feedback" button in the dashboard works. It may take some time, but new features often come from people that took the time to do a Feature Request. ... View more

Hi @sbcoms ,   Nice plan! Only a small detail: you need to create and configure the Group Policies before creating iPSK groups.   I recommend reading this article as a reference. ... View more

Hi @Thiandanai ,   Are these devices connected by cable or wifi?   Did you check if the devices went to sleep or energy saving mode? ... View more