Skip to main content
Cisco Meraki Documentation

Meraki SD-WAN Hub Integration with Secure Connect

  1. Last updated
  2. Save as PDF

Overview

The existing Meraki SD-WAN MX hubs, just like MX spokes, can now be connected to the Secure Connect cloud fabric using the Sites page.  In order to support the existing Meraki SD-WAN deployments with the Cloud network and security services, we had enabled customers to attach hubs to Secure Connect and if required, install a default route.

When in Sites page, MX hubs will show up now and allow attachment to Secure Connect.

remote routes.png

Selecting the hub site will expose the right side drawer where the new option of Remote Routes will now expose the Default Route setting and allow the user to enable this option and inject a default route via iBGP.

e65772db-499f-4482-b429-fe45433a53f3.PNG

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

Meraki MX hub integration with Secure Connect does not support the Exit Hub configuration.  You must use the above explained Remote Routes option to enable a default route on the MX SD-WAN hub.

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 head-end 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 resources behind a Meraki SD-WAN hub can offer secure Internet access via Secure Connect, where Secure Connect regions receive all traffic using the default route option.

Note: When an MX is configured as a hub, then an additional configuration option becomes available: Remote Routes. This allows an injection of the 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.

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

All Meraki hub networks in your org 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.

clipboard_e0e6651bd8152e8d6a1b47e434092ed7d.png

As with the spokes, the MX hub will use the primary and secondary head-end DCs as shown below.  I.e., for the US West, the Los Angeles is the primary DC, and Palo alto is the secondary DC.  The failover behaviour from primary to secondary head-end DC is the same as for MX spokes.

clipboard_eb5ed75a5f86963edbdabb2a0ca37669e.png

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: The MX hubs will learn the selective routes from the Secure Connect fabric.  The default route (0.0.0.0/0) is injected only if the Remote Routes setting is modified to enable.  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 (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 the user can enable the Default Route for each MX hub under Remote Routes.
  • 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.

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, simply enable the Default Route option under Remote routes.

Note: The failover between Regional DC hubs follows the same behavior as that of any Meraki MX spoke.