Direct answer: what Cisco Meraki Site-to-Site VPN is and when it fits

Understanding the Meraki approach to branch-to-branch and branch-to-data-center VPN

Traditional site-to-site VPN projects can become operationally difficult because every location may require individually matched crypto parameters, peer addresses, access rules, routing statements and troubleshooting steps. Cisco Meraki’s approach is attractive to many multi-site buyers because the Meraki Dashboard centralizes the configuration and orchestration of Meraki WAN appliances. When Auto VPN is used between supported Meraki peers in the same Dashboard organization, each participating appliance can advertise the local subnets intended for VPN use, share WAN reachability information through the Meraki cloud process and obtain the routing information needed to reach the rest of the Auto VPN domain. The result is a deployment model that reduces the amount of repetitive, peer-by-peer configuration normally associated with a large IPsec estate.

That simplification does not remove the need for design. A VPN can come up correctly and still deliver a poor business outcome if the branch IP plans overlap, the wrong subnets are advertised, Internet-bound traffic is backhauled unnecessarily, the hub is undersized, the WAN circuits cannot carry the expected workload, application flows are blocked by policy, or there is no credible failure path. A successful Meraki project therefore separates two questions: “Can the tunnel be created?” and “Does the resulting network behave the way the business needs?” FourTeck treats the second question as the more important one because it affects usability, resilience and the cost of future expansion.

Auto VPN is Layer-3 and IPsec based. It is intended to connect routed IP networks rather than extend a Layer-2 broadcast domain between sites. That distinction matters for buyers who have older applications or server clusters that assume a common subnet across two locations. In most modern branch designs, routed site-to-site connectivity is desirable because it contains broadcasts, simplifies failure domains and allows each site to keep a clear local addressing plan. Where an application genuinely depends on Layer-2 adjacency, that requirement should be identified before procurement because it may point to a different network design rather than a normal Meraki site-to-site VPN.

The value of Meraki is also operational. Network teams can manage VPN participation, monitor peer status and review connectivity information from the Dashboard rather than maintaining a separate configuration interface for every branch. This can be particularly useful for UAE businesses with many small offices, retail points, clinics, warehouses, hospitality sites or service locations where local technical staff may not be available. Zero-touch deployment concepts can reduce branch rollout effort, but the organization still needs controlled addressing, device ownership, licensing, template strategy, change management and documented handover procedures.

Two distinct VPN paths: Auto VPN and configured IPsec peers

Choosing between hub-and-spoke, mesh and selective connectivity

Topology is one of the most important design decisions in a Meraki Site-to-Site VPN. The right answer depends on who needs to communicate with whom, where shared services live, how Internet traffic should leave the network, what resilience is expected and how much direct branch-to-branch traffic actually exists. Meraki provides hub and spoke roles that can be combined into practical multi-site designs. A hub participates broadly in the Auto VPN domain, while a spoke establishes VPN tunnels to specified hubs. Other spokes can normally be reached through those hubs unless policy prevents the traffic.

A common mistake is to select a topology because it is familiar rather than because it matches traffic. If branches regularly exchange large files directly, hairpinning all of that traffic through a distant hub can add latency and consume hub bandwidth. On the other hand, a broad mesh may be unnecessary where branches only use central applications and have no legitimate need for lateral communication. The buyer should start with an application-flow map: which source networks need which destination networks, on what ports, at what expected volume and with what availability target.

For Dubai organizations with operations spread across the UAE, the WAN carrier mix also matters. A head office with dual business-grade circuits may be a good hub candidate, while a small location behind a limited broadband or cellular service may be better as a spoke. The technical design should reflect real access conditions rather than treating every branch as identical.

Auto VPN mechanics that matter to the buyer

Auto VPN is often described as simple because the Dashboard reduces the number of settings an administrator must manually coordinate. That description is accurate operationally, but a buyer should still understand the conditions behind that simplicity. Each participating Meraki appliance needs working connectivity to the Meraki cloud services involved in orchestration. The appliance advertises the local subnets selected for VPN participation and its WAN reachability information, while Dashboard-generated information allows peers to establish encrypted paths. This cloud-assisted orchestration is not the same thing as sending all private application traffic through the Meraki cloud. The VPN traffic is carried between the relevant VPN peers according to the established path; the cloud provides the management and connection-brokering functions.

Automatic NAT traversal is part of the Meraki-to-Meraki experience. This helps when appliances sit behind upstream devices performing NAT. Cisco documents the use of the Meraki VPN registry process to assist peers in learning the public address and UDP port information needed to establish the tunnel. However, NAT traversal is not magic. Restrictive upstream firewalls, symmetric NAT behavior, carrier-grade NAT or unusual port translation can interfere with the peer relationship. Cisco’s current guidance identifies outbound UDP 9350–9381 for Auto VPN registry communication as a requirement that upstream policy may need to allow.

Carrier-grade NAT deserves specific attention in mobile and some broadband environments. When an ISP changes the effective public translation behavior in a way that makes the return path asymmetric, Auto VPN establishment can become unreliable. Cisco documents manual NAT traversal and obtaining a real public IP from the provider as possible approaches in relevant scenarios. The practical procurement lesson is straightforward: if an important branch depends on LTE, 5G, managed broadband or another service that may use CG-NAT, ask the carrier about public addressing and NAT behavior before the migration window. It is far easier to resolve this as a circuit design issue than during an outage.

Local subnet selection is another essential detail. Advertising a subnet into Auto VPN makes that route part of the VPN domain, so the IP plan must be unique and intentional. Overlapping networks between branches are a recurring source of migration difficulty. Two acquired businesses may both use 192.168.1.0/24, for example, or many small branches may have been built from the same unmanaged router template. A Meraki VPN project is a good time to identify those collisions. Sometimes NAT can be used in specific scenarios, but long-term branch standardization usually benefits from a structured non-overlapping addressing plan.

Route behavior should be reviewed at the same time as firewall policy. Auto VPN creates routes for the included networks, while separately configured IPsec peers also create reachability to defined remote subnets. The design must account for static routes, local VLAN interfaces, default routes and any dynamic routing used at hubs or data centers. A route that exists does not automatically mean a flow is allowed; a VPN firewall rule, host firewall, server ACL or upstream segmentation control can still block the traffic.

Third-party IPsec peering: what must match before the change window

Third-party IPsec is appropriate when a Meraki MX or compatible endpoint needs to connect to a non-Meraki firewall, router, cloud VPN gateway or another Meraki environment that sits in a separate Dashboard organization. This mode is standards based, but interoperability still depends on both peers being configured consistently. The technical worksheet should be exchanged and agreed before implementation rather than assembled during the live cutover.

Cisco currently recommends using its default IPsec policy where the remote endpoint can match it. Custom policy is available when the peer has a defined requirement, but modifying crypto parameters without a specific interoperability reason increases the number of settings that can mismatch. For buyers, the goal is not to choose the most complicated cipher list possible; the goal is to implement a mutually supported, policy-compliant configuration that can be operated reliably.

IKE version also affects scale and behavior. Cisco documents both IKEv1 and IKEv2 for IPsec peers, and its guidance explains that IKEv1 can create more security associations as the number of subnet pairs grows. For a new integration, the remote vendor’s documentation, current firmware capability and security policy should be checked rather than blindly copying parameters from an older tunnel.

Another limitation to understand is that a Meraki MX does not simply become a generic transit router between any two manually configured IPsec peers. Cisco’s routing guidance states that routing between two IPsec VPN peers using static routing is not supported; where peer-to-peer transit is needed, dynamic routing with BGP over IPsec is required. This matters in data-center consolidation projects where a buyer may expect the Meraki appliance to connect several legacy partner tunnels and route all of them through one another. The intended traffic relationships should be reviewed before deciding that a Meraki peer architecture can replace a previous firewall design unchanged.

Licensing: Auto VPN is included, but the appliance license still matters

Cisco’s current Meraki MX/Z licensing documentation states that Auto VPN functionality is included as part of the platform feature set and does not require a separate VPN add-on license. That is an important distinction when a buyer is comparing an appliance bill of materials. However, every participating device still needs the appropriate Meraki licensing arrangement, and the selected MX license tier affects the wider security, SD-WAN and analytics capabilities available to the organization.

Current MX license options include Enterprise, Advanced Security and Secure SD-WAN Plus in the relevant licensing models. Enterprise is positioned for essential connectivity and basic security use cases that include site-to-site VPN. Advanced Security adds broader unified threat-management capabilities such as IDS/IPS, content filtering and malware-related security functions supported by the platform. Secure SD-WAN Plus builds further on the feature set for organizations that require richer analytics and application experience functions. The exact edition should therefore be chosen around the full security and WAN requirement, not merely the fact that a VPN tunnel is needed.

Licensing architecture has also evolved across Meraki. Organizations may use different Cisco Meraki licensing models, including subscription or co-termination/per-device arrangements depending on the estate and contract. Those models have their own rules about how devices and editions are assigned. A quotation should identify the appliance model, intended term, existing Dashboard organization, current license model and desired feature tier. This avoids a common procurement problem in which hardware arrives but the licensing entitlement does not line up with the organization’s existing structure.

Warm-spare high availability has its own licensing implications. Cisco documentation notes that in the per-device licensing model, an MX warm-spare pair consumes a single license for the pair. Commercial rules can depend on the licensing model and current Cisco policy, so the quotation should still be checked against the actual Dashboard organization rather than relying on a historical license assumption.

The most useful way to quote Meraki Site-to-Site VPN is therefore to treat “VPN” as one capability inside a larger WAN platform purchase. FourTeck asks what Internet security, application control, analytics, SD-WAN policy, high availability and support functions are required at each site. This produces a more accurate selection than quoting the lowest license tier only because it is technically capable of forming Auto VPN tunnels.

Sizing the Meraki appliances for VPN traffic

There is no single appliance called “Cisco Meraki Site-to-Site VPN.” The feature runs on supported Meraki WAN appliances, and the correct hardware must be selected for the site. This is a critical procurement point because a VPN design can be logically correct but underperform if the appliance is chosen only by office headcount or Internet line speed. Buyers should consider actual encrypted traffic, security inspection requirements, number of active users, concurrent sessions, application mix, port requirements, WAN redundancy, expected growth and the role the site plays in the topology.

A small branch acting as a spoke has a different sizing profile from a central hub aggregating traffic from many sites. The hub may need to handle branch-to-data-center application flows, spoke-to-spoke transit, central Internet breakout, security inspection, dynamic path decisions and local users at the same time. If the design places multiple critical services behind one hub pair, the sizing margin should reflect failure conditions as well as normal operation. An appliance that appears adequate while both data centers are healthy may be insufficient if it must temporarily carry traffic from a failed peer location.

Published throughput values are useful for comparing models, but they should not be treated as guaranteed application performance in every environment. Real throughput depends on packet size, enabled security features, firmware behavior, WAN quality, encryption, traffic mix and the number of simultaneous services being processed. FourTeck therefore asks for the expected WAN speed and the expected business VPN load separately. A branch with a 1 Gbps Internet circuit may only send 100 Mbps of private application traffic; another branch with a 200 Mbps circuit may need nearly all of that bandwidth for a central ERP system.

Interface requirements can eliminate an otherwise suitable appliance. Confirm whether the site needs dual WAN Ethernet, SFP or higher-speed interfaces, local switching ports, cellular capability, external modem integration or connection to a separate switch stack. Data-center concentrator roles may use a one-armed design rather than acting as the Internet edge firewall, which changes the port and routing requirements. An exact hardware shortlist should follow the topology drawing, not precede it.

Growth also matters. Meraki makes adding branches operationally easier, which means a successful deployment often expands. The hub sizing exercise should include the expected number of sites during the planned hardware lifecycle, not only the branches being migrated in phase one. Buyers should also identify any expected cloud migration, new SaaS reliance, mergers or new UAE locations that could change traffic patterns during the same period.

WAN, NAT and Internet-circuit considerations in the UAE

A site-to-site VPN is ultimately dependent on the WAN beneath it. Meraki can automate tunnel creation and monitor path quality, but it cannot create bandwidth that the carrier does not provide or remove delay caused by geography and congestion. For each Dubai or UAE site, record the provider, circuit type, committed or expected bandwidth, handoff type, public IP behavior, NAT arrangement and whether a second independent path exists.

Public IP addressing is particularly important for data-center hubs and third-party IPsec peers. Auto VPN can work behind NAT in many common scenarios through automatic NAT traversal, but a known static public address or controlled NAT policy can still simplify a critical hub design. If an upstream firewall sits in front of the Meraki appliance, the network team must ensure that it permits the connectivity the Meraki appliance requires. A security policy that blocks Meraki’s registry communications can prevent Auto VPN from establishing correctly even though normal web browsing from the site appears to work.

Dual uplinks improve resilience only if they are genuinely diverse enough for the business requirement. Two circuits delivered over the same physical route, building riser or provider aggregation point may fail together. When VPN availability is important, ask what a “second circuit” actually means: separate carrier, separate last-mile medium, separate termination equipment, separate building path or simply another logical service on the same underlying infrastructure. Meraki can fail over between available uplinks, but the physical and carrier design determines whether the alternate path survives the incident.

For cellular backup, confirm data allowance, carrier-grade NAT behavior, signal quality and whether the applications are usable at the reduced bandwidth. A cellular path may be excellent for transaction continuity, cloud access and essential remote administration while being unsuitable for large backups or high-quality video. Traffic-shaping and SD-WAN policy can prioritize critical applications during degraded operation, but those policies must be defined in advance.

DNS, NTP and cloud reachability should also be included in the readiness check. Troubleshooting teams often focus on the tunnel itself when the actual failure is a dependency used by an application after routing is restored. A cutover test should therefore validate representative business services rather than relying only on a successful ping between appliance interfaces.

Resilience and failover: design for the failure you actually need to survive

Meraki Auto VPN supports resilient designs that combine multiple WAN uplinks, multiple hubs and high-availability appliance pairs. Cisco documents monitoring of VPN tunnel loss, latency and jitter, and SD-WAN policy can use configured performance classes and flow preferences to move traffic between VPN paths. This is valuable for applications that need better continuity than a simple primary/backup Internet circuit can provide.

Uplink redundancy and appliance redundancy solve different problems. Dual WAN circuits protect against an access-path failure but do not protect against an appliance hardware failure. A warm-spare pair protects the appliance role but does not protect against both units losing the same upstream circuit or power source. A robust hub may therefore need dual circuits, redundant switching paths, stable power and a warm-spare pair. Cisco requires the warm-spare MX to be the same model as the primary, so the hardware bill of materials must reflect a matched pair.

A one-armed VPN concentrator design can be used at a data center where another firewall already handles the Internet edge. In this architecture, the Meraki appliance concentrates Auto VPN traffic and integrates with the existing routed core. This can be useful during migration because the business can adopt Meraki branch connectivity without replacing the incumbent data-center security stack on the same day. The tradeoff is that routing between the concentrator, core and data-center services must be engineered carefully, including route advertisement, return paths and any high-availability protocols.

Datacenter redundancy should also consider what happens to branch traffic when an entire hub site becomes unavailable. Multiple hubs can be defined for spokes, and route priority can be designed so that a secondary data center takes over. The secondary site must have enough compute, application availability and WAN capacity to be useful. Sending traffic successfully to a disaster-recovery network does not help if the application itself is not running there.

For third-party IPsec peers, failover is less automatic because the remote peer must also know how to reach the alternate Meraki public address or failover destination. Cisco specifically notes that the third-party device needs the ability to designate a backup peer IP if the Meraki site is expected to re-establish the IPsec tunnel over its secondary uplink. This is why mixed-vendor failover should be tested as an end-to-end feature, not assumed from the fact that both devices individually have two WAN ports.

Security policy, segmentation and VPN firewall behavior

Encryption protects traffic in transit between VPN peers, but it does not decide whether every device should be allowed to communicate. Site-to-site VPN policy should therefore follow least-privilege principles. A retail point-of-sale subnet may need access to payment or inventory services but not to office user networks. A building-management or OT network may require a narrow set of management destinations. Guest Wi-Fi usually should not be advertised into the corporate VPN at all.

Meraki provides site-to-site outbound firewall rules for VPN traffic. Cisco’s current documentation emphasizes an important behavior: these rules are applied to outgoing traffic, with the recommendation to stop unwanted traffic as close as possible to the originating client. This reduces unnecessary use of the VPN link and gives clearer policy ownership. Buyers migrating from another firewall platform should review whether their old rule base relied on inbound tunnel rules, zone semantics or policy objects that do not map one-for-one to Meraki’s behavior.

Another documented constraint is that FQDN, wildcard FQDN and network groups containing FQDN objects cannot be applied to site-to-site VPN outbound firewall rules in the same way as IP-based objects. If the existing security design uses large numbers of domain-based controls for private traffic, that should be discovered during assessment. Application traffic that resolves to changing cloud addresses may be better handled through a different policy mechanism rather than forcing it into a static site-to-site rule model.

Segmentation decisions also affect route propagation. Meraki’s newer routing and segmentation capabilities can support advanced designs, but the exact features available depend on the platform, firmware and license tier. Buyers should define the segmentation outcome first: which users or devices belong to which security domains, which shared services can be reached, where inspection happens and who owns exceptions. From there, the Meraki configuration can be selected deliberately.

Logging and operational visibility should be included in the design. A network team needs enough information to answer whether a VPN peer is reachable, which path is in use, whether packet loss or latency is excessive and whether a policy is dropping the traffic. The Meraki VPN Status page provides peer status and connection information for Auto VPN and IPsec peers. For business-critical deployments, those Dashboard views should be complemented by alerting, application testing and an escalation procedure so that an outage is detected by operations rather than reported first by users.

Migration planning from legacy site-to-site VPN

Replacing an existing VPN estate is often harder than building a new one because the old network contains undocumented assumptions. The migration plan should start with discovery. Export or document each existing site, peer address, local subnet, remote subnet, IKE policy, authentication method, route, NAT exception, firewall rule, WAN circuit and application dependency. Then separate the connections that can move to Auto VPN from the connections that must remain as third-party IPsec.

Branch renumbering should be identified early. If two sites have overlapping subnets, moving both into the same Auto VPN domain may expose the conflict. A temporary migration workaround may exist, but it is usually better to assign a clean structured address plan before all branches are dependent on the new design. DHCP scopes, static servers, printers, cameras, access-control systems and local management addresses all need to be considered when changing a branch subnet.

The migration sequence should preserve a rollback path. A common approach is to stage the Meraki appliance and Dashboard network first, verify licensing and cloud connectivity, configure the intended VPN role, predefine the branch subnet and policies, and then move the WAN/LAN connections during an agreed window. If a legacy firewall must remain for another function, a parallel or one-armed architecture may be possible, but asymmetric routing risks must be evaluated carefully.

Testing should be application based. The cutover checklist can include DNS resolution, authentication, ERP transactions, file access, remote desktop, voice signaling, printing, monitoring, backup, management tools and Internet access. For each test, identify a source, destination and expected result. A successful tunnel status is necessary but not sufficient; a routing or host-level firewall issue can still break an application after the tunnel is green.

Phased rollout is usually safer for a large branch estate. Start with one or two representative sites rather than only the easiest branch. A representative pilot should include the same upstream NAT, circuit type and application dependencies found elsewhere. Lessons from the pilot can then be incorporated into templates, standard operating procedures and the final rollout package.

The handover should document who owns Meraki Dashboard administration, how changes are approved, which alerts are enabled, how support cases are raised, where configuration backups or exports are maintained, how licenses are tracked and what information a branch technician should gather before escalating. The goal is a repeatable operating model, not merely a one-time tunnel migration.

Deployment journey for a new Cisco Meraki Site-to-Site VPN

Common business use cases in Dubai and the UAE

When Cisco Meraki Site-to-Site VPN may not be the right first choice

A balanced design process should identify cases where another architecture deserves comparison. Meraki is strongest when centralized cloud management, standardized branches and integrated SD-WAN/security operations are important. If the business requires a feature that depends on a different routing model, a highly specialized encryption policy, deep custom scripting on the appliance, or non-Meraki technologies that do not interoperate cleanly, an alternative platform or hybrid design may be more appropriate.

Very high-throughput data-center encryption can also change the hardware shortlist. The right question is not whether Meraki supports VPN; it does. The question is whether a specific appliance model can deliver the required encrypted and inspected throughput under the intended feature set with enough headroom for growth and failover. Large hubs should therefore be compared against higher-capacity MX models or other Cisco security/SD-WAN options where the traffic profile warrants it.

A third-party VPN estate with hundreds of bespoke partner tunnels may not gain the same operational advantage as a Meraki-to-Meraki Auto VPN deployment. Cisco documents support for a large number of configured IPsec peers, but every manual peer still carries its own interoperability and lifecycle burden. If the primary requirement is partner extranet termination rather than branch networking, the buyer should evaluate which platform offers the best operational model for that specific workload.

Finally, a VPN is not a substitute for application modernization. If users experience poor performance because an application was designed for a LAN and performs many sequential transactions over a high-latency WAN, increasing tunnel capacity may not solve the problem. The application protocol, server placement and user workflow may need to be addressed alongside the network.

Buyer questions FourTeck recommends answering before quotation

Procurement guidance for Dubai and UAE organizations

A useful RFQ for Cisco Meraki Site-to-Site VPN should request a complete solution rather than a generic “VPN license.” Because Auto VPN is included with the supported Meraki appliance feature set, the commercial items usually revolve around the required MX or other supported WAN appliance, its license tier and term, optional high-availability unit, transceivers or interfaces if relevant, installation services, migration work and ongoing support. If the buyer already owns Meraki hardware, the scope may instead focus on licensing, design, configuration and professional services.

For a new branch, provide the Internet circuit speed, user/device count, expected VPN bandwidth, number of VLANs, required LAN/WAN ports, whether cellular backup is needed and whether the branch will act as a spoke. For a hub, provide the aggregate branch count, peak private traffic, central Internet egress requirement, routing environment, data-center switch interfaces and resilience design. This allows the supplier to shortlist an appliance based on the role instead of quoting a model by guesswork.

If the estate already uses Meraki, include the current license model and expiration information. This is important because Meraki licensing may be managed under subscription, co-termination or per-device frameworks, and the procurement route needs to align with the actual organization. The device serial number and Dashboard organization should be handled securely and provided only where necessary for entitlement checks.

For third-party IPsec, attach the peer worksheet if policy allows. Remove secrets from documents that do not need them. The supplier needs the peer platform, public IP/FQDN, IKE version, proposed crypto policy, protected subnets, NAT information, redundancy method and change-window contacts. A pre-shared key can be exchanged separately through the approved secure channel at implementation time.

FourTeck UAE can support product supply, design clarification and implementation scoping for organizations in Dubai and across the UAE. Buyers can use the FourTeck UAE site for regional company information and the contact page below for a project-specific Meraki VPN quotation.

Technical reference points to keep in the project document

The following points are useful because they affect design and troubleshooting. They should be recorded in the low-level design or handover document rather than left as informal project knowledge.

Frequently asked questions about Cisco Meraki Site-to-Site VPN

Decision recap before you choose the design

What FourTeck needs from the buyer for an accurate quotation

Plan the Meraki VPN around your real branch traffic, not a generic template

Cisco Meraki Site-to-Site VPN can make multi-site connectivity much easier to deploy and operate, especially when branches are standardized on Meraki. The strongest result comes from combining that automation with correct appliance sizing, a clean IP plan, suitable license selection, deliberate hub/spoke roles, resilient WAN circuits, tested security policy and a documented migration path. Share your site count, WAN details and application requirements with FourTeck for a Dubai/UAE solution proposal that separates hardware, licensing and professional services clearly.