Skip to main content
Cisco Meraki Documentation

Meraki SD-WAN Hub Integration with Secure Connect


Meraki SD-WAN (MX) configured as a hub will build a full mesh of VPN tunnels to all other hub MXs in the Auto VPN domain and point-to-point tunnels to all spoke MXs that have this MX configured as a hub. If all MXs in the Auto VPN domain are configured as hub, the Auto VPN has a full mesh topology.


Graphical user interface, text, application, email

Description automatically generated

Challenges that existed with Cisco Secure Connect before the Hub Integration Solution

Integrating Meraki SD-WAN with Secure Connect leverages Meraki Auto VPN technology. Meraki SD-WAN creates Auto VPN tunnel to Secure Connect’s service edge region which are head-ends that are deployed as Hubs in Umbrella DCs.

There is a default route ( that propagates from the headend, iBGP propagates this default route to the next hop (Spoke) or (Hub). As mentioned in the above Hub Mesh, all Hubs in the organization form a mesh with each other including the Secure Connect regional headend hubs. Thus, we have the default route ( to Secure Connect now propagating via iBGP to all the Hubs part of the mesh.

Now, all the Auto VPN enabled subnets traffic from each Hub gets defaulted to Secure Connect, thereby causing a complete routing change in the customer network. This could result in large packet drops based on how the policies are set in Umbrella, add unwanted latency, and other unintended consequences for the flow of traffic.

For flexible migration and retaining of legacy architectures, we have implemented a solution to transform and migrate existing Meraki data center or private cloud environments configured as hub to Secure Connect by ENABLING the integration of Meraki SD-WAN hubs with Secure Connect.

Customer Use Cases



  1. Organizations migrating their network infrastructure as it is to Secure Connect world by retaining their Data Centers or Azure/AWS/GCP/Alibaba/other  etc hubs as it is. Thereby, exposing all the resources or applications behind these hubs to both remote and branch users to securely access through Secure Connect fabric.

  1. Organizations with Meraki SD-WAN hubs configured with BGP downstream to all their resources wanting to migrate to Secure Connect so that all remote and branch users can securely access these resources through Secure Connect fabric.

  1. Organizations with some resources behind a Meraki SD-WAN hub need to access the Internet securely via Secure Connect, with Secure Connect regions as Exit Hubs.

Exit Hub

When an MX is configured as a Hub, then an additional config option becomes available: ‘Exit hub’. This allows you to bind a default route ( to the IPSec security association of that hub in a similar fashion to the ‘Default Route’ option for Spoke MXs.

  1. Organizations want remote or branch users to securely access via Secure Connect some resources behind a spoke branch that is connected to Meraki SD-WAN hub.

  1. Organizations want their branch (spoke) users to securely access only the Internet via Secure Connect but still be able to directly access resources behind a Meraki SD-WAN hub that is connected to Secure Connect.

Integrating Meraki SD-WAN hubs to Secure Connect

This is a tailored solution that will still retain the Auto VPN mesh between Meraki hubs but enables a more selective and flexible integration of Meraki SD-WAN hubs to Secure Connect. This entire solution is customized to Secure Connect and is available ONLY with the Secure Connect Headend. There will be no default routes propagated to the Meraki SD-WAN hubs that are connected to Secure Connect regions.

Background Requirements

First and foremost, make sure we have NOT DISABLED the Meraki Hub to Hub mesh feature for the organization. If it is disabled, you will have to ENABLE it back if the plan is to integrate ANY Meraki SD-WAN hub to Secure Connect. If unsure, please call Secure Connect support to help verify if the mesh feature is disabled organization-wide for your org.

Connecting Meraki SD-WAN hubs

After carefully completing the background requirements, now you will be able to see all the Meraki Hub networks show up in the list of Meraki networks when you go to Secure Connect > Sites > Add Sites. The user experience is the same for connecting either hub or spoke to Secure Connect.

Select all the Hubs that you want to connect to Secure Connect. We have simplified and retained the same user experience of connecting a spoke network to Secure Connect.


After choosing and confirming the Secure Connect Region to which we want to connect the Meraki Hub an AutoVPN tunnel will be created from the Hub to each Secure Connect DC within the region.

There will be NO default route ( advertised to the Meraki SD-WAN hub that you will be connecting to Secure Connect. Instead, we will be serving selective Secure Connect learned routes to the connecting Meraki hub. However, all spokes directly connecting to Secure Connect will still be advertised the default route ( to Secure Connect.


Meraki hub Integration with Secure Connect Supported Use-Cases 

Transforming an organization’s existing network infrastructure to Secure Connect’s SASE model will require certain routing considerations and adaptations. Especially using the Meraki SD-WAN hub Integration with Secure Connect where we are changing the Meraki MX hub’s existing behavior upon integrating with SC. Following are some of the unique customer transformation use case designs currently supported by Secure Connect and the necessary steps to successfully achieve it along with the change in routing behavior.

Connecting Meraki spokes to both Meraki hubs (connected to SC) and Secure Connect regions

After integrating both Meraki hubs and spokes with Secure Connect, to establish an interconnect between Meraki spokes, hubs, and Remote Users, the following is the Secure Connect supported routing design:


  1. As shown above: If a spoke (S) is connected to a Secure Connect region then it will receive a default route to SC via IBGP. This will direct all Internet and SaaS traffic to route through Secure Connect.

  2. If spoke (S) wants to directly access resources behind the Meraki hub (connected to a different SC region) WITHOUT routing through Secure Connect then,

    • If the priority of the Site-to-Site hubs are SC regions DCs as primary and secondary with Meraki hub as tertiary.

    • CHANGE the priorities hubs in Site-to-Site VPN page to the following:

      1. Meraki hub

      2. SC Region DC1

      3. SC Region DC2

  3. After changing the DC priorities, all internet traffic from spoke (S) will be secured through Secure Connect and all Auto VPN traffic to resources behind Meraki hub will route directly to the hub.

  4. Remote users from all Secure Connect regions can access resources behind Meraki hub via SC fabric secured by Secure Connect Cloud Firewall.

Connecting a Meraki SD-WAN hub with spokes attached to it

While integrating a Meraki hub to Secure Connect, if there is a spoke (eg: Spoke SA as shown in figure which is not connected to Secure Connect) attached to the Meraki hub, Secure Connect USERS cannot directly access the resources behind the Spoke (SA) through SC fabric.

For SC users to be able to access the resources behind Spoke (SA), Secure Connect supported design is:

  • Along with connecting the Meraki hub to Secure Connect.

  • Connecting the spoke (SA) directly to Secure Connect enables connectivity to all resources behind spoke (SA) for Secure Connect users.

If a spoke (S) is connected to Secure Connect Region1 and Meraki hub is connected to Secure Connect Region 2, then to establish an interconnect between spoke (S) and Meraki hub, the current recommendation is to make sure to have Meraki hub as one of the hubs for Spoke (S) along with Secure Connect hubs. In Site-to-Site VPN prioritize Secure Connect as the primary/secondary hub pair.

Connecting a Meraki SD-WAN hub that requires a Default Route to Secure Connect

While integrating a Meraki SD-WAN hub to Secure Connect, if the hub’s use case is to secure internet traffic along with the private access and there is a need for default route to Secure Connect. The current option is:

  • Connect the Meraki hub to Secure Connect following the above-mentioned steps in the document.

  • For the hub that requires a default route ( advertised by Secure Connect, add the corresponding Secure Connect regional hubs as the EXIT hubs.

  • For example: If the Meraki hub is connected to US-West Region of Secure Connect, then add Secure Connect Los Angeles and Secure Connect Palo Alto as the exit hubs.

As part of adding the Exit hubs, please make sure the primary/secondary exit hubs are the DCs of the same region and with the following ordering as a requirement:

Secure Connect Region Primary Exit hub DC Secondary Exit hub DC
US West Los Angeles Palo Alto
US North East New York Ashburn
US Central Denver Dallas
US South East Atlanta Miami
US Midwest Minneapolis Chicago
Europe-1 London Frankfurt
Europe-2 Paris Marseille
Europe-3 Madrid Milan
Europe-4 Stockholm Copenhagen
Asia-1 Narita Singapore

While configuring Secure Connect HUB as 'Exit Hubs' please make sure there is no asymmetric configuration i.e. For ex: A MX HUB connected to Europe 1 region can only support Europe 1 region DC pairing as its 'Exit Hubs'

Also, A MX HUB connected to Europe 1 region and having Europe 1 region DCs configured as Exit Hubs can only be configured as a HUB to SPOKEs which are connected to Europe 1 Secure Connect region ONLY. 

The failover between EXIT hubs follows the same behavior as that of any Meraki MX hub having another MX hub as EXIT hub.

Connecting a Meraki SD-WAN hub (in Passthrough Mode) with existing BGP Routing configurations

While integrating a Meraki SD-WAN hub to Secure Connect which has downstream connections to Applications or devices using BGP (peering with to a different AS number) then the following would be the supported flow:

Referring to the first supported use case please be aware of the supported Meraki hub designs for Secure Connect. For spoke Sites connected to a different Secure Connect region when compared to a Meraki hub connected SC Region,

  1. The spoke needs to be connected primarily to the Meraki hub and then to Secure Connect regional hubs.

  2. The spoke to Meraki hub communications will currently route directly via AutoVPN to the Meraki hub.

  3. Remote users to Meraki hub communications will route via Secure Connect fabric.

  • Connect the Meraki hub to Secure Connect following the above-mentioned steps in the document.

  • Go to the connected Meraki hub’s Security & SD-WAN > Routing page and enable ‘Allow Transit’ for the subnets that require to be shared across SC (Secure Connect) AS number.

If the above step of connecting hub to Secure Connect fails with the following error:

Unrecognized subnet <subnet/> for Passthrough MX - only Client VPN subnet(s) permitted.


  1. Go to the Meraki hub’s Security & SD-WAN > Site-to-Site VPN page and remove the subnets that are part of the BGP Routing.
  2. Connect the Meraki SD-WAN hub to Secure Connect then,
  3. Go to Meraki hub’s Security & SD-WAN > Site-to-Site VPN page to RE-ADD the previously deleted subnets back to the hub and in Security & SD-WAN > Routing page.

Connecting an organization with ONLY 'hubs' to Secure Connect

If an organization has all sites configured as hubs and the intention is to connect them to Secure Connect, the following are the recommendations and supported design with Secure Connect:

Secure Connect supported scale for this design of a Meraki organization having all of their SD-WAN sites configured as hubs is 60 i.e. In a all hub network infrastructure Secure Connect today supports 60 Hubs integrating at the same time to its fabric.

  • All hubs connected to Secure Connect will not receive a default route. If there exists 'Internet Access' use case for the hubs connected to Secure Connect then enable Secure Connect datacenter regions as their 'Exit Hubs'
  • The branch to branch interconnect between these hubs will always be over the AutoVPN mesh between the hubs and the traffic will not route through Secure Connect. As part of policy enforcement please choose your 'Security & SD-WAN' security policies to secure the branch to branch traffic for this use case only.