Skip to main content
Cisco Meraki Documentation

Meraki SD-WAN Hub Integration with Secure Connect

  1. Last updated
  2. Save as PDF

Overview

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.

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 a hub, the Auto VPN has a full mesh topology.

 

Graphical user interface, text, application, email Description automatically generated

Cisco Secure Connect challenges before the Hub Integration Solution

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

There is a default route (0.0.0.0/0) 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 (0.0.0.0/0) to Secure Connect now propagating via iBGP to all the hubs part of the mesh.

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

Use Cases

 

 

  1. Organizations migrate their network infrastructure to the Secure Connect environment while retaining their Data Centers or hubs in Azure/AWS/GCP/Alibaba/other platforms as they are. This setup exposes all resources or applications behind these hubs to both remote and branch users, allowing them to securely access them through the Secure Connect fabric.

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

  3. Organizations with some resources behind a Meraki SD-WAN hub need secure Internet access via Secure Connect, with Secure Connect regions serving as exit hubs.

Note: When an MX is configured as a hub, then an additional configuration option becomes available: Exit hub. This allows to bind a default route (0.0.0.0/0) 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 some resources behind a spoke branch connected to a Meraki SD-WAN hub via Secure Connect.

  2. 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 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.

If you wish to have the integration enabled, please contact Secure Connect support (How to Contact Cisco Secure Connect support) 

Background Requirements

Make sure the Meraki hub-to-hub mesh feature is not disabled for the organization. If it is disabled, it needs to be re-enabled if the plan is to integrate any Meraki SD-WAN hub to Secure Connect. If unsure, please contact Secure Connect support to help verify if the mesh feature is disabled organization-wide for your organization.

Connecting Meraki SD-WAN hubs

After carefully completing the background requirements, all Meraki hub networks should be visible in the list of Meraki networks in Secure Connect > Sites > Add Sites. The user experience for connecting either a hub or spoke to Secure Connect remains the same.

Select all the hubs that you want to connect to Secure Connect. We have simplified and retained the same user experience for 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 Auto VPN tunnel will be created from the hub to each Secure Connect DC within the region.

Note: There will be no default route (0.0.0.0/0) advertised to the Meraki SD-WAN hub integrated with Secure Connect. Instead, selective routes learned by Secure Connect will be served to the connecting Meraki hub. However, all spokes directly connecting to Secure Connect will still be advertised via the default route (0.0.0.0/0).

 

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 when integrating the Meraki SD-WAN hub with Secure Connect, which involves changing the existing behavior of the Meraki MX hub upon integration with SC. Below are some of the unique transformation use case designs currently supported by Secure Connect and the necessary steps to successfully achieve them, along with the changes 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 routing design supported by Secure Connect:

 

  1. As shown above: If a spoke (S) is connected to a Secure Connect region then it will receive a default route 0.0.0.0/0 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 below 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.

Note: If a spoke (S) is connected to Secure Connect Region 1 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 with Secure Connect, if the hub's use case involves securing internet traffic along with private access and there is a need for a default route to Secure Connect, the current option is as follows:

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

  2. For the hub that requires a default route (0.0.0.0/0) advertised by Secure Connect, add the corresponding Secure Connect regional hubs as the exit hubs.

For example: If the Meraki hub is connected to the 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 hubs as Exit hubs, ensure there is no asymmetric configuration. For example, an MX hub connected to the Europe 1 region can only support Europe 1 region DC pairing as its Exit hubs.

Additionally, an MX hub connected to the Europe 1 region and having Europe 1 region DCs configured as Exit hubs can only be configured as a hub to spokes that are connected to the Europe 1 Secure Connect region exclusively.

Note: 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:

Note: Referring to the first supported use case, 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 Auto VPN 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.

  • Go to the connected Meraki hub’s Security & SD-WAN > Configure > 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."

Then:

  • Go to the Meraki hub’s Security & SD-WAN > Configure > Site-to-Site VPN page and remove the subnets that are part of the BGP Routing.
  • Connect the Meraki SD-WAN hub to Secure Connect.
  • Go to Meraki hub’s Security & SD-WAN > Configure > Site-to-Site VPN page to re-add the previously deleted subnets back to the hub and in Security & SD-WAN > Configure > Routing page.

Connecting a Hubs-only organization to Secure Connect

 

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

Note: Secure Connect supports a scale of 60 for this design, meaning that in an all-hub network infrastructure, Secure Connect currently supports integrating up to 60 hubs simultaneously into its fabric.

  • All hubs connected to Secure Connect will not receive a default route. If there is an '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 occur over the Auto VPN mesh between the hubs, and the traffic will not route through Secure Connect. As part of policy enforcement, choose your Security & SD-WAN security policies to secure the branch-to-branch traffic for this specific use case.