Meraki SD-WAN Secure Access Design Guide
This guide covers supported design topologies for Meraki SD-WAN integration with Secure Access. There are currently two ways to onboard a Meraki SD-WAN site into Secure Access.
- Native Primary and Secondary tunnels - for Internet access use cases.
- Internet access refers to Internet bound traffic
- Internet access refers to Internet bound traffic
- BGP over IPsec tunnels - Private Access + Internet access use cases.
- Private access refers to Site-to-Site and Remote access traffic
Private access is not currently supported with native MX primary & secondary tunnels. This is due to the differences in failover behavior between Secure Access (DPD) and Meraki SD-WAN (L7 Health check). For Private Access use cases, use BGP over IPsec tunnels.
Use Case One - Secure Internet Access for Branch + Secure Private Access for Remote users
This use case covers Secure Internet access for branches, and private access for remote access users. With this use case all Site-to-Site traffic uses the Meraki SD-WAN fabric, while Internet access goes to the SSE directly from the branch and remote access travels from the SSE to the Hub, then Spoke.
Configuration
- MXs are deployed in Hub and Spoke on the AutoVPN fabric
- Hub to Hub communication must be disabled to avoid routing loops. (can only be disabled by Meraki Support)
- Hubs peer with Secure Access via BGP over IPsec (Routing option in Secure Access is configured as dynamic, with default route advertisement disabled)
- Spokes form static 0.0.0.0/0 tunnels to Secure Access (Routing option is configured as NAT in Secure Access, while private subnet field is configured as 0.0.0.0/0 on Meraki SD-WAN)
- Remote Access users connect through Secure Access for private access
Routing and traffic flow
- Hubs will advertise all connected spoke routes via eBGP to Secure Access with adjusted AS path numbers to accurately represent spokes traffic priorities (Refer to BGP documentation to learn more about route propagation behavior)
- Meraki uses one BGP AS per Meraki Org to enable iBGP communication for AutoVPN peers. Hence, if the US and EU regions are in the same Meraki Org, they will share one BGP AS, and as a result, routes from the EU region will be filtered out when received at the US region Hubs and vice versa. This is a default BGP behavior.
- As a result spokes/Hubs in US Region will not learn routes or communicate with spokes/Hubs in EU Region.
- To enable communication/route propagation between the US and EU regions, keep each region in separate Meraki Orgs, and use a different BGP AS number per region
- Since Secure Access learns all routes through the BGP exchange via the hubs, private VPN access from remote user will travel as follows, from the SSE > then to the Hub > then the Spoke
- Spoke to Hub and Spoke to Spoke communication will ride the AutoVPN fabric
- Spokes will ride the static 0.0.0.0/0 tunnel in blue for Internet access through Secure Access
- Static 0.0.0.0/0 tunnels configured from Spokes towards Secure Access will NOT be used for private access because they are configured as NAT tunnels in Secure Access (only the NAT option in Secure Access is currently supported with static native primary & secondary tunnels on the MX)
Firewalling
- SSE Cloud Firewall will be used for:
- Internet bound traffic; and
- Private access from remote users
- MX Firewall will be used for:
- Spoke to Hub traffic,
- Spoke to Spoke traffic; and
- Traffic excluded from the VPN tunnel or exiting the MX locally
Use Case Two - Secure Internet Access + Secure Private Access for Branch & Remote users
This use case covers Secure Internet access, as well as private access for branches and remote access users. With this use case all Site-to-Site traffic, Internet traffic and remote access travels through the SSE fabric.
Configuration
- Branches are deployed in Hub mode on AutoVPN, with Hub to Hub communication disabled to avoid routing loops.
- Branches peer with Secure Access via BGP over IPsec (Routing configured as dynamic in Secure Access)
- Datacenter Firewalls peer with Secure Access (with default route advertisement disabled in Secure Access)
- If Datacenter Firewalls are MXs, deploy them in a different Org to allow for unique BGP AS configuration from Branches for route propagation
- Remote Access users connect through Secure Access for private access
Routing and traffic flow
- Branches and DC Firewalls will advertise all local routes via eBGP to Secure Access
- Meraki uses one BGP AS per Org to enable iBGP communication in AutoVPN. However, AutoVPN is not needed in this scenario, since the SSE is the Firewall for all traffic. Hence, considering Branches are in the same Meraki Org, they will share one AS, and as a result, routes from other branch 1 will be filtered out when received at any branch 2, and vice versa. This is a default behavior of BGP.
- Branch to Branch communication will succeed due to the default route advertised from Secure Access to the Branches.
- To enable route propagation between Branches and Datacenter (if using Meraki at Datacenter), keep Datacenter in a different Meraki Org, and use different BGP AS numbers. If your Datacenter Firewall is not Meraki, just use a different AS number.
- Private access from remote user will travel as follows - SSE > Branch/Datacenter
- Branch to Datacenter and Branch to Branch communication will ride the Secure Access SSE fabric
- Branches will ride BGP over IPsec tunnel for all traffic through Secure Access
Firewalling
- SSE Cloud Firewall will be used for:
- Internet bound traffic through SSE
- Branch to Branch/Datacenter
- Private access from remote users
- MX Firewall will be used for:
- Traffic excluded from the VPN tunnel or exiting the MX locally
Use Case Three - Secure Internet Access + Hybrid Secure Private Access for Branch & Remote users
This use case covers Secure Internet access, as well as private access for remote access users and select branch-to-branch communication via AutoVPN and Secure Access. With this use case some Site-to-Site traffic travel on the AutoVPN fabric, and others travel on the SSE fabric. Internet traffic and remote access traffic travel through the SSE fabric.
Configuration
- Some Branches are deployed in Hub mode on the AutoVPN fabric, with Hub to Hub communication disabled to avoid routing loops
- Branches 5 & 6 are deployed as Spokes, connecting to Branch 3 Hub
- Branches 5 & 6 can only connect to Secure Access directly for Internet access only via static 0.0.0.0/0 tunnel (configured NAT tunnels in Secure Access)
- This is because iBGP routes are automatically redistributed into eBGP and Secure Access already knows about Branch 5 & 6 spokes via Branch 3 Hub, hence, Do NOT form BGP tunnels from Branch 5 & 6 spokes to Secure Access, as this will cause undeterministic routing within Secure Access
- Branch Hubs peer with Secure Access via BGP over IPsec (Routing configured as dynamic in Secure Access)
- Datacenter Firewalls will peer with Secure Access (with default route advertisement disabled in Secure Access)
- If Datacenter Firewalls are MXs, deploy them in a different Meraki Org to allow for unique BGP AS configuration from Branches for route propagation
- Remote Access users connect through Secure Access for private access
Routing and traffic flow
- Branch Hubs and DC Firewalls will advertise all local routes via eBGP to Secure Access
- Meraki uses one BGP AS per Org to enable iBGP communication in AutoVPN. Hence, considering Branches are in the same Meraki Org, they will share one AS, and as a result, routes from Branch hub 1 will be filtered out when received at Branch hub 2, and vice versa. This is a default behavior of BGP. However, Branch Hub to Branch Hub communication will succeed due to the default route advertised from Secure Access to the Branches.
- To enable route propagation between Branch Hub and Datacenter (if using MXs at Datacenter), keep Datacenter MXs in a different Meraki Org, and use different BGP AS number. If your Datacenter Firewall is not Meraki, a different AS number will suffice.
- Branch 5 & 6 Spoke will use AutoVPN for Private access, including private access though Branch Hub to endpoints connected via Secure Access
- Branch 5 & 6 Spoke will use static 0.0.0.0/0 NAT tunnels for Internet access through Secure Access
- A default route will also be learned from Branch 3 hub via iBGP, but this will be less preferred than the static 0.0.0.0/0 tunnel
- Private access from remote user will travel as follows - SSE > Branch Hub/Datacenter OR SSE > Branch Hub > Branch Spoke
- Branch Hub to Datacenter (using specific routes) and Branch hub to Branch hub (using default route) communication will ride the Secure Access SSE fabric
- Branch Spokes to Datacenter will ride the AutoVPN fabric first to its Branch Hub before reaching Secure Access SSE fabric
- Branch Spokes to Branch 3 hub communication will ride the AutoVPN
- Branch Spokes will NOT communicate with non AutoVPN Branch hubs (i.e. Branch hub 1, 2 & 4), because they are all in the same BGP AS. Routes from Branch hub 1, 2 & 4 will not be learned at Branch 5 & 6 Spokes or Branch 3 hub
- For Branch 5 & 6 spokes to communicate with other non AutoVPN Branch hubs, Branch 5 & 6 Spokes along with its connected AutoVPN Branch Hub need to have a different BGP AS (which means different Meraki Org)
- Branch Hubs will ride BGP over IPsec tunnel for all internet bound traffic through Secure Access
Firewalling
- SSE Cloud Firewall will be used for:
- Internet bound traffic from all sites going through SSE
- Branch hub to Branch hub/Datacenter
- Private access from remote users
- MX Firewall will be used for:
- Traffic excluded from the VPN tunnel
- Traffic between Branch spokes and directed connected Hubs (i.e Branch 5 & 6 spokes and Branch 3 Hub)