Skip to main content

 

Cisco Meraki Documentation

Cisco SASE: Sites Connectivity

  1. Last updated
  2. Save as PDF
This article is referred to for understanding the integration process and platform optimization features of Meraki SD-WAN branches with the Secure Access cloud fabric, including site enrollment, tunnel establishment, and routing behaviors. It also highlights important considerations and prerequisites for hub and spoke configurations within Secure Access. Explanation includes how to connect Meraki sites or networks using AutoVPN.

Overview

Meraki SD-WAN branches integrate with the Secure Access cloud fabric via the SASE > Connect > Sites menu, using Meraki Auto-VPN tunnels for both spoke and hub appliances. Onboarding a Meraki organization to Secure Access applies platform optimization features automatically. Sites can be enrolled or unenrolled through the Sites page, with VPN status monitored under Security & SD-WAN > Monitor > VPN Status. MX Spokes establish tunnels and iBGP peering with cloud hubs, installing default routes pointing to primary and secondary hubs, while MX Hubs form iBGP peering and install all known prefixes without default routes.

Prerequisites

Hub mesh must be enabled for proper MX hub integration in SASE and using MX Hubs as Exit Hubs is not supported with Secure Access. Spokes with eBGP require routing protocol to be re-enabled after enrolling in Secure Access. Organizations with only hubs connected to Secure Access will route branch-to-branch (hub-to-hub) traffic over the Auto VPN mesh, not through the Secure Access path, and should secure hub-to-hub traffic via MX firewall policies. Refer to CISCO SASE: Getting Started Guide for detailed prerequisites.

SASE Sites

Meraki SD-WAN branches can seamlessly integrate with the Secure Access cloud fabric through the Sites page. Meraki Auto-VPN is used to tunnel traffic from both Meraki spoke or hub mode appliance into Secure Access. Both integration options provide the same Sites page for administrators to use, allowing them to perform multiple provisioning or deprovisioning requests. When a Meraki organization is onboarded to Secure Access, platform optimization features are automatically applied as part of the onboarding process. These features are explained in detail in the Design Best Practices document. It is important to understand what these features do, as they may alter the existing behavior and use cases currently deployed within the Meraki organization.

Enrolling a Site

Perform the following steps to Enroll a Site.

When enrolling a large number of sites, using templates allows the administrator to do so in one step.  If sites are not using templates, it is recommended to enroll sites in batches of 200, allowing the UI to fully complete enrollment before proceeding with enrollment of another batch.

  1. Click SASE > Connect > Sites from the Meraki dashboard to navigate to Sites page.

clipboard_e4089ffa88cfb558eb5f3f73cab229be1.png

  1. Click the Add Site button.

This image illustrates where to find and click the Add Site button in the Sites page.

  1. On the displayed page, select the available Meraki branches for enrollment from the list, and assign the selected branches to the desired Secure Access region.

Branches already enrolled will not appear in this list.

 
This image demonstrates how to select Meraki branches for enrollment and assign them to a Secure Access region.

 

The 'Newly assigned' tab will show the branches you have selected.

This image shows the Newly assigned tab listing the selected branches and highlights the Next button to continue.

  1. Click Next to proceed.

Review and confirm page is displayed.

This image displays the Review and confirm page with the Save and Finish button to begin the provisioning process.

  1. Click Save and Finish to start the provisioning flow.

The newly enrolled site is displayed on the Sites page.

This image shows the Sites page with the newly enrolled site listed.

  1. To verify the enrollment and monitor VPN status, navigate to Security & SD-WAN > Monitor > VPN Status. This page shows the cloud hubs and their VPN registry information, useful for troubleshooting any issues.

This image displays the VPN Status page, where you can verify site enrollment and monitor VPN connectivity and registry details.Established tunnels can also be verified on the Secure Access UI.  Administrators can use the SASE > IPSec Sites (Network Connections) menu option to cross-launch into Secure Access.

clipboard_ece8c7e1e8845218f9c4f2a0da17bbec1.png

After logging into Secure Access, the Network Connection page displays the Meraki Sites tab where AutoVPN tunnels can be verified.

clipboard_eb3c921760a034ec93b52fa2a58971dbe.png

Clicking on the Site Name reveals the AutoVPN tunnel traffic statistics and the link to Meraki Dashboard.

clipboard_e6cc47188e3cc97a46e68a0905ffc32ac.png

Detaching a Site

Perform the following steps to detach a Meraki branch from Secure Access.

  1. Navigate to the SASE > Connect > Sites page.

clipboard_e5160d019649ac814e53904707aa447b2.png

Sites screen is displayed.

clipboard_e4161e8a8d7c0d2f9aa99d5de72083a6d.png
 

  1. From the list of sites, select the Meraki branch site you want to unenroll.
     
  2. Click the Detach site button associated with that site.

This image demonstrates selecting a Meraki branch site from the list and clicking the Detach site button to unenroll it.

A confirmation screen is displayed.

This image shows the confirmation screen that appears before unenrolling a Meraki branch site.

  1. Click the Detach button to confirm.

The Meraki branch site will then be unenrolled from Secure Access.

Meraki MX Spoke Auto-VPN with Secure Access

When an MX Spoke enrolls in Secure Access, it establishes a tunnel and forms an iBGP peering with the cloud hub. Using iBGP, the Spoke installs a default route pointing to the primary cloud hub. The two cloud hubs appear on the Security & SD-WAN > Configure > Site-to-site VPN page.
 

This image displays the Site-to-site VPN configuration page, showing two cloud hubs and the iBGP peering established after an MX Spoke enrolls in Secure Access.

 

Changing the order of the Secure Access cloud hubs on a spoke is allowed. However, due to the close proximity of DC locations, it is unlikely to change their proximity to the spoke itself.  Secure Access cloud hub networks are labeled as primary and secondary, with postfix of the city name.

The spoke advertises the subnets enabled for VPN mode under VPN settings on the same page.

This image highlights the VPN settings page where the spoke advertises subnets enabled for VPN mode.

Meraki MX Hub Integration with Secure Access

When an MX Hub enrolls in Secure Access, it establishes a tunnel and forms an iBGP peering with the enhanced cloud hub. Using iBGP, the Hub installs all known prefixes from the cloud fabric, except the default route. Like spokes, all enrolled Hubs in the region direct their traffic to the primary cloud hub. By default, the hub concentrator priority under Security & SD-WAN > Configure > Site-to-site prefers the primary cloud hub over the secondary cloud hub. Secure Access also allows changing the cloud hub priority to the secondary cloud hub.

This image shows the Site-to-site VPN configuration page, illustrating how MX Hubs use iBGP to route traffic through the primary or secondary cloud hub based on hub concentrator priority.

In order to properly enroll an MX hub with Secure Access, or allow Hybrid Spokes to communicate with both Local (MX) or Cloud Hubs, please review the following features to understand how they interact with hubs enrolled in the cloud fabric.

Hub Mesh Must Be Enabled

Meraki hubs must be able to form a mesh within the organization. This feature is enabled by default but can be disabled with assistance from Meraki support. When disabled, enrolling a hub in the cloud fabric will not work as expected because no routes will be exchanged. Contact Meraki support to either re-enable the mesh or discuss alternative solutions.  Spoke enrollment should still function as expected, even if hub mesh is disabled.

Exit Hubs Are Not Supported

Using an MX Hub as an Exit Hub is not supported when using Secure Access integration.  This setting augments the cloud traffic path with Secure Access.

Enabling Multiple Default Routes

MX Spokes enrolled in the cloud fabric always receive a default route (iBGP) from the cloud hubs. To preserve the cloud path to the Internet, the IPv4 default route feature should not be enabled on the listed MX hubs. In the illustration below, the Spoke’s hub priority list uses 'Hub 1' for direct access to its application subnets over AutoVPN established between a Spoke and this Hub 1.  The IPv4 default route option should not be used under 'Hub 1' as it will backhaul all Internet traffic from this spoke to Hub 1 and make the cloud hub default routes obsolete.  Therefore, such configuration is not supported.

clipboard_e49952a71ef99be9c21a8782fdfd2b1e9.png

Spokes Configured with eBGP 

Organizations that use eBGP on their Meraki MX Spokes should behave as expected after integration with Secure Access. The spokes will receive a default and specific routes from cloud hubs and can exchange those routes with their external peers.  An optional feature referred to as only-default-route for Spokes can be enabled but administrator must be aware that specific routes would not propagate to external peers, as Spokes will no longer learn those from the cloud fabric.  Please review the Platform Optimization section for more info.

Organization with Hubs and No Spokes in Secure Access

If an organization has all sites configured as hubs and intends to connect them to Secure Access, all Hubs should be enrolled.   MX hubs will establish AutoVPN tunnels with Secure Access Cloud Hubs and form iBGP peering.  This will allow RAVPN and ZTA users access to MX Hub application subnets.  MX Hub-to-Hub communication will still occur over the Auto VPN mesh between the hubs, and the traffic will not route through Secure Access. To enforce policies, configure firewall security policies under Security & SD-WAN > Configure > Firewall to secure MX hub-to-hub traffic for this specific use case.

Enabling Default Route on the Hubs

Hubs connected to Secure Access can enable a default route. Under SASE > Connect > Sites menu, clicking on a Hub site reveals the right side drawer where 'Manage default route' option is available under Default Route section.


clipboard_ecf8d0f7a67cdd81c67c93118c988f9f9.png

Default Route option are revealed and can be updated for the selected Meraki Hub.

clipboard_e125f38fb4b1fef17742aad7eba6ae3f8.png

 

MX Hub enrolled in Secure Access will now have specific prefixes as well as a default route pointing to the Cisco SSE.

Meraki Sites as Network Tunnel Group Source Objects in Access Policy

Similar to IPSec NTG sites, Meraki AutoVPN sites can be used as source criteria in the Secure Access Policy.  Individual sites can be selected as under the Network Tunnel Groups under both Private and Internet rules.

clipboard_ec191ed259da7aeae9d6614631738d2f7.png  

  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Article type
    Topic
  2. Tags
    This page has no tags.