The solution I had posted in November 2019 has been working.  The short of it is that you create a static route on the hub MX for the internet addresses you'd like to through the VPN tunnel.  For next hop, you put the hub MX IP.         This would create a routing loop.  So, you want to uncheck the Enabled box.      This will cause the route to be advertised through the VPN tunnel by the hub MX.  The spoke MX will see the route advertised by the hub MX and send the traffic through the VPN tunnel.  Then when it arrives, the hub MX will send it out the WAN interface.  One would expect the hub MX to stop advertising routes that have been disabled, but that hasn't happened in the 3 months since I set this up.   I opened a support case to get clarification, since the setup seems a bit suspect.  The support rep communicated with the development team and relayed the following:   1. This is not intended behavior.  While the team doesn't have any plans to actively change how it is working, a future fix for an unrelated issue could have the side effect of closing up the loophole.  So, it's use at your own risk.   2. The team does plan to implement a supported way to accomplish selective routing of internet traffic through VPN tunnels.   My plan is to ride out the work-around until the supported solution is available.  The worst that can happen is that the work-around stops working before the official solution is available and I'm back to where I started. But right now things are working exactly as I wanted, and I didn't have to buy any extra equipment.   If you are doing pre-purchase research, don't base your decision on this work-around, because it is unsupported and can disappear.  But if you've already got Meraki gear running, you don't have much to lose by trying it out. ... View more

This has been working great.  I used this technique to configure VOIP traffic to go through the VPN tunnel out a reliable data center fiber connection.  A colleague and I tested a phone call between a VOIP phone and a cell phone.  I unplugged the WAN1 link and the call continued.  I reconnected WAN1 and unplugged WAN2, and the call continued.  This is something I did not think was possible with Meraki.  We did notice brief interruptions due to lost packets.  But it was much better than expected.   I think the Meraki team is missing out on an opportunity here.  The Velo Cloud sales reps kept telling us how VOIP calls don't drop with Velo Cloud, but they do with Meraki. I was on a call with Meraki sales reps telling them I didn't think Meraki was "real SD-WAN", and they had no response.  And that's the sentiment I got from third party sales reps that sell both.  They told me if I wanted true SD-WAN, to get VeloCloud.  If I wanted a more reasonably-priced solution, get Meraki.  One VeloCloud sales rep used the phrase "you get what you pay for".   However, it is possible with Meraki to do a spoke failover without VOIP calls dropping.  If they wanted to, the Meraki team could implement packet duplication and jitter protection, and compete with the VeloCloud VOIP feature set. ... View more

I've been struggling with this for the past few days.  The company has VOIP telephone service.  Each branch has two WAN uplinks.  If an uplink goes down, then the phone calls will drop when the branch MX switches to the second uplink.  If I can route the VOIP traffic to the MX at the data center, then the branch uplinks can switch without the VOIP service seeing a change in the IP address.  I can also simplify IP whitelisting with 3rd party services if I can backhaul all of the traffic to those services through the hub WAN IP address.  But I can't send all of the branch internet traffic to the hub because that would kill the hub's uplink bandwidth.   I opened a support case and the rep responded it is not possible to set this up.  I called in and the second rep told me if I can get the hub MX to advertise the route, the branch MX will send the traffic over the VPN tunnel.  When I asked how to do that, he told me to put a static route into the hub MX with the IP of interest as a /32 subnet and the MX IP as the next hop.  I tried that, but the traffic got into a routing loop.  One would expect this to happen, but I have seen the Meraki dashboard have special support to "do what I mean" with some things like this.    To resolve the routing loop, I disabled the static route.  Then something amazing happened.  Things started operating exactly as I wanted.  The hub MX continued to advertise the route to the branch MX, and the branch MX happily sent it the traffic, but when the traffic got to the hub, the hub MX sent it out the WAN link.  Perfect!   So, this is great.  But I am worried that this behavior would be considered a bug that will eventually be "fixed".  If I were a programmer of the MX firmware, I would not advertise static routes that are disabled.  The point of disabling something is to completely remove it from use without losing the information of what used be active.  ... View more