Nice work, Philip! This feature is essential for Meraki's core offering. Having no way to undo mistakes is a significant drawback for such a great concept. ... View more

When you assign a policy group to a client VPN, it looks like it is associated to a username but is not because if you connect from anohter computer using the same credentials, this new connection skip the policies applyed previuosly. Looks like there is no way to apply group policies to usernames, only computers/phones/tables. ... View more

We just tested it on a lab that we created for this purpose (2 MX's and 2 routers to simulate the MPLS) but the plan is to move to production this week.   What is important to have clear is : 1.- The MPLS has to be on the LAN of the MX. 2.- To have an SDWAN  tunnel up (not ordinary VPN's) using a WAN port.  3.- To understand the purpose of each route of your table, the priority of each route and to be clear what happens when one of your routes overlap another one (the redundant one). If you are not clear about the purpose of each of your routes and how they behave in every scenario, then it could not work as it should. ... View more

Thanks @Bruce .About  "The alternative would be to turn this into a SD-WAN solution, but in that scenario you'd either need internet access from your MPLS cloud, or to configure one end as a VPN concentrator - which means another firewall (potentially MX) required.", that is something we do pretty often and works. There is another reason (not part of this threat) why this option is the one we need.   Any way, we finally made it work and it goes like this. For the redundant route, instead of selecting the option "While next hop respond to ping" you have to select "while host respond to ping". This host can be on the other side as long as the IP of the host (192.168.0.1) it is included in the subnet (192.168.0.0/24 )that you want to reach.     ... View more

About "MPLS failover to Meraki auto VPN" solution, at first sight looks great but when you go deep on it you realize that the solution is very limited. The problem is that option "Active as long as a device on the other side responds to ping" is limited to a host / interface directly reachable by the MX (same segment).    Above image has been taken from the Meraki document. Here, the MX on the left is able to check MPLS availability by pinging the interface 192.168.128.249 (cannot do it against 192.168.129.249). The problem here is that interface 192.168.128.249 can remain up even if the link is down, in which case will never choose the second route over the VPN.   Quote form the doc: The next hop IP cannot be out the internet interface or over another static route.   Am I missing something?   ... View more