Secure Connect design including Azure vMX

[jimmyt234]

We have a greenfield deployment for a customer: Secure Connect, Azure vMX, multiple spoke networks spread across the globe.

My question is around the integration of the vMX's into the design. They will be deployed as Hubs because we require eBGP to Azure Route Servers, but from what I am reading this then means that from a spoke deployment perspective they must have the Azure vMX networks as Hub priority 1 and 2, with the Secure Connect Hubs as 3 and 4.

Surely this then means all spoke <> spoke traffic now traverses the vMX rather than Secure Connect, rendering any rules on the CDFW redundant and instead we would have to replicate them on the Site-to-Site outbound firewall rules page in Meraki? Is there a way I can avoid this, perhaps by having the Azure Hubs as picks 3 and 4 on the spoked and keeping Secure Connect as 1 and 2 (or would this simply not work??)

I have raised a support ticket, but thought the community may also have some knowledge on the subject. 😊

[alemabrahao]

It would be interesting to consult a Meraki SE, to validate your design.

[PhilipDAth]

Because you are using SecureConnect - why don't you connect it directly to the Azure VPN gateway.  You don't really need to use a VMX ...

https://docs.umbrella.com/umbrella-user-guide/docs/manual-azure-ipsec-deployment-guide

[DanD]

I'm not the OP, but just a different perspective that we are trying to battle. The Azure VPN gateway is a dead simple setup, but for us, we want to be able to exclude certain traffic that a particular application we use generates. This app uses rotating AWS IPs that change every couple of months, so we would like to exclude the traffic via FQDN so we don't have to consistently try to figure out these IPs. There's no great way to do this in Azure because everything is IP-driven, whereas a vMX gives us this ability via the local internet breakout. 

[jimmyt234]

We have taken a step forward - there is a "2025 platform optimization" update: Cisco Secure Connect - Design Best Practices - Cisco Meraki Documentation

We are in discussions with support finalising our requirements but it looks like we will be going for Design B in the linked article and this should allow spoke<>spoke traffic to traverse the Secure Connect backbone, but spoke<>vMX Hub to go direct.