Site-to-site VPN connections between MX Security Appliances and/or Z1 Teleworker Gateways will automatically form a mesh topology between all VPN-enabled peers in the same Dashboard organization by default. This is often undesirable because such connections establish unnecessary IPSec tunnels between remote sites and create performance-degrading networking overhead.
In these cases it is best to configure Site-to-site VPN topology for Hub and spoke, which designates the datacenter MX as the "hub" and all remote sites as the "spoke". This model can be useful in organizations where several auxiliary sites require a connection to the HQ or datacenter-located concentrator, pictured below.
Figure 1. Split tunnel w/ Hub-and-Spoke (connect directly to one peer). VPN connections (blue) are established to only one peer (top). Traffic to the internet (black) goes out locally from each site.
Figure 2. Full tunnel w/ Hub-and-Spoke (connect directly to one peer). VPN connections (blue) are established to only one peer (top). Traffic to the internet (black) goes out from a central concentrator/hub (top).
Although each remote location is not connected directly in this method, remote sites can still connect with each other via the hub by default. This article covers:
Note: Hub and spoke topologies are currently only supported between Meraki MXes, non-Meraki VPN peers cannot be configured as spokes.
The MX features a hub-and-spoke option for its MX to MX VPN. To implement Hub-and-spoke the network administrator needs to follow these steps:
Once Saved, the MX set as "Spoke" will form a VPN tunnel with the specified hub(s).
In the event you need to limit branch office communication, configure Site-to-site firewall rules. You can edit the Site-to-site firewall from any MX network. This can be done at Security appliance > Configure > Site-to-site VPN > Organization Wide Settings > Site to Site Firewall Rules.
This will allow you to limit the communication between spokes in the way you desire. In this particular example we have prevented site A from communicating with B and C in either direction, while allowing sites B and C to talk through the hub. If you want to deny the traffic from each spoke, you must set up a rule both ways (from hub sub net to hub sub net).