Skip to main content

 

Cisco Meraki Documentation

Meraki SD-WAN Hub Integration with Secure Connect

  1. Last updated
  2. Save as PDF

Overview

Meraki SD-WAN MX (local) hubs already configured with Spokes can now be enrolled into the Secure Connect cloud fabric using the Sites page.  Remote workers can then access local Hub resources using Secure Connect.  If required, hub can enable a default route toward Secure Connect.

Currently, if local hubs are enrolled in Secure Connect, all the Spokes must prefer these local hubs in their Hub preference settings.  As a result, the Spokes communicate to each other using the local Hubs, not via Secure Connect.  

In below example, local Meraki Hubs take precedence over Secure Connect hubs (CPSC).

clipboard_eb2a1e820c0a74df24351670fd07ec263.png

The latest enhancements to our solution may enable more flexible designs with hub integration.  They are in the process of being validated to ensure branch to branch, and branch to Hub traffic can traverse the Secure Connect fabric in various scenarios. 

Currently, the above described precedence rule should be implemented with any enrolled Hubs to ensure proper operation of the fabric.  It is the only supported design for Hub integration with Secure Connect.

When in Sites page, MX hubs will show up now and allow attachment to Secure Connect. Note the same applies to Z series.

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 considerations before Hub Integration 

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 (enhanced head-ends), which serve as hubs to the cloud fabric in Umbrella DCs.  

There is a default route (0.0.0.0/0) that can propagate from the head-end. iBGP propagates this default route to the next hop spoke or (enabled) 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 can now enable the default route (0.0.0.0/0) to Secure Connect for iBGP to propagate to desired hubs in the mesh.

Now, the traffic from the hubs can also use the default route to Secure Connect. This means that hub Internet traffic will have strict policies applied in Umbrella and add additional latency between sites.

Use Cases

 

 

  1. Spoke branch users enable secure Internet access via Secure Connect.  Spokes-to-Hub and Spoke-to-Spoke traffic still uses Meraki Hubs with precedence over Secure Connect Hubs (CPSC hub per DC in each region, i.e. US West).  The local Meraki SD-WAN communication in this case is not visible to cloud security services.

  2. Remote Users access resources on both local Hubs and Spokes enrolled in Secure Connect.  Meraki SD-WAN hubs or spokes configured with BGP downstream resources will be accessible to remote workers via Secure Connect.

  3. Hub branch users and resources can access Internet via Secure Connect, after enabling an optional default route setting.  These resources communicate directly to other local Meraki SD-WAN Hubs and Spokes.

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.

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 Secure Connect via Meraki AutoVPN/iBGP. This will direct all Internet and SaaS traffic to route through Secure Connect.

  2. Currently, Spoke (S) can only access the enrolled local Meraki HUB resources directly (connected to a different Secure Connect region) without routing through Secure Connect.

    • As Spoke is enrolled in Secure Connect, the cloud Hubs will be automatically installed with higher precedence then local Hubs.  The precedence needs to be corrected towards local Hubs.

    • CHANGE the priorities for 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 enrolled local Meraki Hub in Secure Connect fabric.  This traffic is governed by the 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.