Cisco SASE: Sites Connectivity
Overview
Meraki SD-WAN branches integrate with the Secure Access cloud fabric via the SASE > 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. Hub mesh must be enabled for proper hub integration and using MX Hubs as Exit Hubs is currently unsupported. Spokes with eBGP require special support consideration. Organizations with only hubs connected to Secure Access will route branch-to-branch traffic over the Auto VPN mesh, not through Secure Access, and should secure hub-to-hub traffic via firewall policies.
Prerequisites
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 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 Secure Connect Hub integration 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.
- Click SASE > Sites from the Meraki dashboard to navigate to Sites page.
- Click the Add Site button.
- 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.
The 'Newly assigned' tab will show the branches you have selected.
- Click Next to proceed.
Review and confirm page is displayed.
- Click Save and Finish to start the provisioning flow.
The newly enrolled site is displayed on the Sites page.
- 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.
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.
After logging into Secure Access, the Network Tunnel Groups for Meraki sites can be verified.
Clicking on the Meraki MX (AutoVPN) Network Tunnel Group reveals the Meraki networks enrolled in this region.
To return back to Meraki dashboard from Secure Access, administrators can click on the 'Return to Meraki' icon shown on the bottom left side of the Secure Access UI. This option is only available in a stand-alone Secure Access dashboard and not an option when using Security Cloud Control as an application portal.
Detaching a Site
Perform the following steps to detach a Meraki branch from Secure Access.
- Navigate to the SASE > Connect > Sites page.
Sites screen is displayed.
- From the list of sites, select the Meraki branch site you want to unenroll.
- Click the Detach site button associated with that site.
A confirmation screen is displayed.
- 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.
You can change the order of the Secure Access cloud hubs on a spoke. This works like Secure Connect spokes, which select the primary cloud hub closest to their location. Therefore, MX spokes in the same region may use different cloud hubs to send traffic into the cloud fabric and interconnect. Currently, Secure Access cloud hubs are labeled as primary and secondary. The city names are added to the labels as well.
The spoke advertises the subnets enabled for VPN mode under VPN settings on the same page.
Automatic updates optimize the platform and support the flexible network designs introduced in Secure Connect. Customers who optimized their platform in Secure Connect can use the same designs with Secure Access.
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.
Secure Access supports the Hub integration designs described in the Secure Connect documentation. During Secure Access onboarding, platform optimization ensures proper communication between all sites through the cloud fabric.
Prerequisites
Certain features may negatively affect hub integration with Secure Access. 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 Secure Access support to either re-enable the mesh or discuss alternative solutions.
Exit Hubs Are Not Supported
Using an MX Hub as an Exit Hub is not supported with Secure Access. Soon, enrolled hubs will be able to enable a default route toward the cloud fabric using the Remote Routes option.
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 a Hub. The IPv4 default route option should not be used under 'Hub 1' as it will make the cloud hub default routes obsolete. Therefore, such configuration is not supported.
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 > Sites menu, clicking on a Hub site reveals the right side drawer where 'Manage default route' option is available under 'Remote Routes' section.
The screen that pops up allows the administrator to change this Hub settings to receive a default route that points to Secure Access.
MX Hub enrolled in Secure Access will now have specific prefixes and a default route pointing to SSE.
Meraki Sites as Network Tunnel Group Source Objects in Access Policy
Similar to IPSec NTG sites, Meraki AutoVPN sites are available to use as source objects in the Access Policy. Individual sites can be selected as criteria under the Network Tunnel Groups under both Private and Internet rules.
API
Managing integration
https://developer.cisco.com/meraki/api-v1/get-organization-integrations-deployed/ https://developer.cisco.com/meraki/api-v1/create-organization-sase-integration/ https://developer.cisco.com/meraki/api-v1/get-organization-sase-integration/ https://developer.cisco.com/meraki/api-v1/delete-organization-sase-integration/
Managing sites
https://developer.cisco.com/meraki/api-v1/get-organization-sase-regions/ https://developer.cisco.com/meraki/api-v1/create-organization-sase-sites-enroll/ https://developer.cisco.com/meraki/api-v1/delete-organization-sase-sites-detach/ https://developer.cisco.com/meraki/api-v1/get-organization-sase-sites/ https://developer.cisco.com/meraki/api-v1/get-organization-sase-site/ https://developer.cisco.com/meraki/api-v1/update-organization-sase-site/ https://developer.cisco.com/meraki/api-v1/get-organization-sase-connectivity-overview/