Issues Implementing Umbrella Cloud On-Ramp

[Brash]

I'm working on implementing Meraki to Umbrella SIG Tunnels (using Cloud On-ramp) but am seeing some strange behaviour.

The existing topology is relatively simple - single MX hub at the HQ and around 30 branch locations as spokes.

The hub at the HQ is a VPN concentrator and advertises around 6 subnets.

At a branch location, soon as I add the two Umbrella hubs all network traffic (including that which should go to the HQ) is sent to the Umbrella tunnel, and therefore black-holed.

I've got a ticket open with Meraki support already who suggested there may be something messed with the routing table implementation?

Has anyone with a similar setup seen issues like this?

[alemabrahao]

Have you reviewed these documents?

https://documentation.meraki.com/MX/Site-to-site_VPN/MX_and_Umbrella_SIG_IPSec_Tunnel

https://docs.umbrella.com/umbrella-user-guide/docs/configure-tunnels-with-meraki-mx

[PhilipDAth]

I am very uncertain of this so could be very wrong ...

I believe all on-premise sites need to be spokes.  So you need to change your hub to a spoke.  You need to move your current AnyConnect termination to Umbrella.  Users need to VPN into there.

[PhilipDAth]

This will be related to it.
https://documentation.meraki.com/MX/Meraki_Umbrella_SDWAN_Connector/Deployment_Guide 

"Due to the default Meraki Auto-VPN design, all VPN hubs in an organization will automatically tunnel to all other hubs in an organization. This behaviour changes for the Meraki Umbrella SDWAN Connector solution, when the connector hubs are deployed, all other hubs in the organization will not automatically tunnel to SIG and all hub traffic will not be defaulted to Umbrella. The Meraki Umbrella SDWAN Connector network hubs will not automatically tunnel to other hubs in the organization."

[Brash]

See I had seen this but had discounted it as I would expect the packet flow for non internet bound traffic (RFC 1918 IP's advertised by the hubs) to flow from spoke to HQ hub as it would have a more specific route than the 0.0.0.0/0 that gets installed for Umbrella.

And assuming that's the case I'm not too concerned about communication from the hubs to umbrella as they're deployed as VPN concentrators and at this point don't require tunnels to umbrella

[PhilipDAth]

I am very uncertain about all of this.  I haven't played in this area yet.  I could easily be wrong.

[Brash · Accepted solution]

So an update on this.

Meraki support and some pre-sales engineers confirmed that it is indeed a supported topology. It was found that there was some backend 'route summarization configuration' applied to the org that was not visible on the frontend.

Having support remove this backend configuration appeared to correct the routing when looking at the uplink decisions.

We'll be implementing the SIG tunnel again early next month with some users on-site to validate. I'll update here to confirm whether it is indeed fixed or not.

[Brash]

Confirming here that after the backend configuration was removed, we re-implemented and routing works as expected:

 - Internet bound traffic flows to Umbrella via the SIG Tunnel

 - Internal traffic flows across the AutoVPN to the Hub

[whistleblower]

actually I´m also trying to understand how this scenario/design would work 😕

@Brash you mentioned that in your setup you´re using a MX in Concentrator mode acting as Hub next to the Umbrella SD-WAN connectors and advertising IP-Prefixes with the longest match to get the traffic routing correct to the spokes, right?
What´s about the connectivty between the Spokes? Is that traffic routed through the Default-Route via the SD-WAN connectors or isn`t there traffic flowing between your Spokes?

What I´m currently struggling with is to understand if it`s a possible setup to use a Full-Meshed Auto-VPN (where all MXs are used in Routed-Mode and as Hub) with Umbrella SD-WAN Connectors as so called "Exit- or Edge" Hub to the Internet... is this possible with that kind of solution or maybe Secure+ Connect can solve this design consideration?

[Brash]

My deployment didn't have a requirement for spoke to spoke communication. However from memory that still worked. 

Because the MX has a matching subnet for the other spoke in the route table with the next hop as the concentrator hub, it is still chosen over the 0.0.0.0 Umbrella routes.

I can confirm next week.

For your scenario of a full mesh with umbrella integration, I think it would still work but never tested. The secure+ connect design is also fitting, especially for a Greenfield deployment.

[Brash]

Spoke to spoke communication does work.

It appears to transit through the Meraki VPN Concentrator (non-Umbrella) hub.