Plan Azure site-to-site VPN deployments with gateway requirements, networking design, BGP, and IPsec guidance
Technical Plan: Migrating 100+ Azure VPN Connections from Cisco ASA to Cisco Meraki MX250
Meraki's headline VPN feature — Auto VPN — cannot be used for a single one of these 100+ tunnels, because Azure VPN Gateway isn't a Meraki device. Every tunnel in this migration has to be built through a different, less-automated mechanism entirely, and that single fact reshapes almost every planning decision in this document.
A migration plan that treats "move VPN tunnels from ASA to Meraki" as a mechanical, one-to-one configuration port is missing the decision that actually determines the shape of the whole project. Meraki's marketing identity is built around Auto VPN — zero-touch, automatically-provisioned tunnels between Meraki appliances — and that feature genuinely doesn't apply here, because Azure VPN Gateway is not, and cannot be, a Meraki device. Every one of the 100+ tunnels in this migration has to be built through Meraki's Non-Meraki VPN Peer mechanism instead: a manually-defined, standards-based IPsec configuration that behaves much closer to the ASA model this project is trying to leave behind than to Meraki's own headline feature. This changes the planning calculus meaningfully — the automation, the failover behavior, and the operational overhead at 100+ tunnel scale all look different than a casual "we're moving to cloud-managed Meraki" pitch might suggest. This plan works through the real architecture, the real constraints, and a genuinely phased approach to executing a migration this size without a flag-day cutover.
Before any configuration work begins, this decision needs to be made deliberately and documented, since it affects nearly every subsequent section of this plan.
| Aspect | Non-Meraki VPN Peer (direct) | Meraki vMX + Auto VPN |
|---|---|---|
| Compatible with existing Azure VPN Gateway | Yes — connects directly, no new Azure infrastructure required | Requires deploying and licensing a vMX instance inside Azure first |
| Tunnel provisioning | Manual — one peer entry, one set of parameters, per tunnel | Automatic — Auto VPN handles route propagation and tunnel establishment |
| Dual-WAN failover | Not automatic — requires scripted intervention, per Section 4 | Native — Auto VPN handles multi-uplink failover as a built-in feature |
| Additional infrastructure to manage | None beyond the MX250 itself | A vMX instance per Azure region/VNet requiring its own licensing and lifecycle |
Given the scale of this migration, silently defaulting to Non-Meraki VPN Peer without evaluating the vMX alternative risks locking in the failover gap covered in Section 4 across all 100+ tunnels without a conscious trade-off decision. If dual-WAN automatic failover is a hard requirement for any subset of these connections — critical production traffic, for instance — evaluate the vMX path specifically for that subset, even if the bulk of the migration proceeds via direct Non-Meraki VPN Peer connections.
Before designing the migration, it's worth confirming the target platform genuinely has headroom for the scale involved — a real, verifiable question rather than an assumption.
| Limit | Published figure | Headroom at 100+ tunnels |
|---|---|---|
| MX250 site-to-site VPN tunnels | 3,000 | Comfortable — roughly 30x the scale being migrated |
| Recommended Dashboard-wide IPsec VPN peers | 1,500 (organization-wide) | Comfortable — this is an org-level ceiling, not per-device |
| MX250 threat protection throughput | 2 Gbps | Worth validating against actual aggregate tunnel traffic during the pre-migration sizing exercise, not assumed sufficient by tunnel count alone |
Cisco's own MX250 datasheet describes it as designed to provide "Secure VPN Concentration services for large VPN Topologies" and datacenter VPN concentration specifically — this isn't a device being stretched beyond its intended role for this migration; VPN concentration at this scale is precisely the scenario it's built for. The genuinely important validation isn't tunnel count capacity, which is comfortable, but confirming aggregate throughput requirements (Section 2's third row) against real traffic volume across all 100+ tunnels combined, since that's the dimension most likely to be the actual constraint rather than the peer count.
This is the single most important technical fact to get right before configuring even one tunnel: Meraki MX and Z-series devices use policy-based routing to communicate with non-Meraki IPsec VPN peers, and Azure VPN Gateway's own connection type directly dictates which IKE version is even negotiable as a result.
| Azure VPN Gateway connection type | Supported IKE version |
|---|---|
| Route-based | IKEv2 only |
| Policy-based | IKEv1 only |
This constraint originates on the Azure side, not the Meraki side — the Azure VPN Gateway's configured type (route-based or policy-based) determines which IKE version it will negotiate, full stop. Before migrating each tunnel, confirm the specific Azure VPN Gateway's connection type and configure the corresponding IKE version on the MX250's Non-Meraki VPN Peer entry to match. A mismatch here means Phase 1 IKE negotiation never completes — the tunnel won't come up at all, and the resulting error won't always make this specific root cause obvious without knowing to check it directly.
Since the ASA being replaced may have been configured for either IKEv1 or IKEv2 depending on when it was originally deployed and against which version of the connecting Azure VPN Gateway, don't assume the existing ASA's IKE version automatically carries over correctly — validate it directly against the current Azure VPN Gateway configuration for each of the 100+ tunnels being migrated, since Azure Gateway configurations can vary tunnel to tunnel if different VNets were provisioned at different times with different defaults.
An ASA HA pair typically presents dual-WAN or dual-device failover as a largely transparent, well-understood operational model. The Non-Meraki VPN Peer mechanism on the MX250 genuinely doesn't replicate that model out of the box — worth planning for explicitly rather than discovering during an actual outage.
| Design option | Trade-off |
|---|---|
| Accept single-uplink-per-tunnel behavior, script failover manually | Preserves the direct Non-Meraki VPN Peer architecture; requires building and maintaining custom failover automation |
| Use Meraki vMX + Auto VPN for tunnels with a genuine HA requirement (Section 1's Path B) | Native, built-in multi-uplink failover; requires deploying and managing vMX infrastructure inside Azure |
| Accept the gap for lower-criticality tunnels, prioritize scripted failover only for production-critical connections | Pragmatic middle ground — reduces automation scope to where it genuinely matters most |
Building genuine scripted failover automation for all 100+ tunnels is a real, non-trivial engineering investment — before committing to that scope, classify the migration's tunnels by actual business criticality. Tunnels carrying production, latency-sensitive, or compliance-relevant traffic are the strongest candidates for either dedicated failover scripting or the vMX/Auto VPN alternative; lower-criticality connections may reasonably accept the single-uplink behavior as-is, particularly if the underlying WAN circuits themselves are already reasonably reliable.
IKE/IPsec parameter mismatches are the most common cause of a tunnel that simply won't establish during any VPN vendor migration — the Meraki Dashboard's built-in Azure preset directly addresses this for the standard case.
| IPsec policy option | Detail |
|---|---|
| Default | Meraki's own default IPsec settings — not tuned specifically for Azure |
| AWS | Preset default settings for connecting to an Amazon VPC — not applicable here |
| Azure | Preset default settings specifically for connecting to a Microsoft Azure instance — the correct starting point for this migration |
| Custom | Manual Phase 1/Phase 2 parameter configuration, for any tunnel that needs settings deviating from the Azure preset |
Starting every one of the 100+ Non-Meraki VPN Peer entries from the Azure preset, rather than manually configuring Phase 1/Phase 2 parameters from scratch each time, is both faster and meaningfully reduces the risk of a parameter-mismatch tunnel failure across the migration. Reserve Custom configuration specifically for tunnels where the corresponding Azure VPN Gateway has a documented, non-default IPsec policy already in place — confirmed during the pre-migration inventory in Section 6, not discovered reactively when a tunnel fails to establish.
| Configurable Phase 1/2 parameter | MX250 supported options |
|---|---|
| Encryption | AES-128, AES-192, AES-256, 3DES |
| Authentication | MD5, SHA1, SHA256 |
| Diffie-Hellman group | Groups 1, 2, 5, 14, 15, 21 |
| Lifetime | Configurable in seconds, Phase 1 and Phase 2 independently |
An Azure VPN Gateway connection configured with a custom IPsec/IKE policy (rather than Azure's own defaults) needs its exact encryption, authentication, DH group, and lifetime values matched precisely on the MX250 side via Custom configuration — the Azure preset alone won't correctly negotiate against a non-default Azure-side policy. This is exactly the kind of detail that belongs in the pre-migration inventory checklist covered next, captured proactively per tunnel rather than discovered reactively during cutover.
At 100+ tunnels, a systematic, spreadsheet-driven inventory pass isn't optional overhead — it's the single highest-leverage step in the entire migration, since almost every subsequent failure mode traces back to a detail that wasn't captured accurately here.
| Field to capture per tunnel | Source |
|---|---|
| Remote peer (Azure VPN Gateway) public IP | ASA running-config, cross-referenced against the Azure portal's VPN Gateway resource |
| Azure VPN Gateway connection type (route-based/policy-based) | Azure portal — determines the required IKE version per Section 3 |
| Current IKE version in use (v1/v2) | ASA running-config — validate against the Azure Gateway's connection type, don't assume it carries over correctly |
| Pre-shared key | ASA running-config or Azure portal connection resource — plan secure handling per Section 7 |
| Local and remote subnets advertised | ASA crypto ACL / access-list entries, cross-referenced against Azure Local Network Gateway address prefixes |
| Custom IPsec/IKE policy parameters, if any | ASA crypto map / IKE policy configuration and the corresponding Azure connection resource, if non-default |
| Business criticality classification | Stakeholder input — feeds directly into the failover design decision from Section 4 |
A handful of specific, documented constraints matter more at 100+ tunnel scale than they would for a handful of connections — worth building explicit checks for each into the migration process.
| Constraint | Detail |
|---|---|
| Reserved UDP ports | Ports 500 and 4500 are reserved for Client VPN and third-party VPN peer communication on the MX — don't allocate these to any other service in firewall/NAT planning |
| Subnet advertisement uniqueness | In Routed mode, all subnets advertised from an MX must be unique within the VPN topology — the same subnet can only be advertised from multiple appliances if all of them are in Passthrough or VPN Concentrator mode |
| Local network requirement | An MX/Z-series device won't attempt to form a tunnel to a peer at all if it has no local network advertised — a real, easy-to-miss cause of a tunnel that silently never attempts to come up |
| PSK management at scale | 100+ unique pre-shared keys need a secure, auditable storage and rotation process — not spreadsheet plaintext, given the scale and sensitivity |
At this scale, particularly if the remote networks connecting through these tunnels were provisioned independently over time (different teams, different eras, inconsistent IP planning standards), genuine RFC1918 overlap between two or more of the 100+ networks is a realistic risk, not a hypothetical one. Validate the full set of advertised subnets for uniqueness across the entire topology as part of the pre-migration inventory pass, since a subnet conflict discovered mid-migration is considerably more disruptive to resolve than one caught during planning.
Given the number of pre-shared keys involved, this migration is a legitimate opportunity to rotate every PSK to a newly-generated, sufficiently complex value rather than simply copying the existing ASA-era keys forward unchanged — particularly valuable if there's any uncertainty about how securely those existing keys have been stored and handled historically. Store the new PSK inventory in a proper secrets management system, not a shared spreadsheet, given both the number of keys involved and their sensitivity.
Complete the full pre-migration inventory across all 100+ tunnels
Capture every field from Section 6's table before any Meraki-side configuration begins — this inventory is the foundation the entire phased plan depends on.
Decide the architectural path (Section 1) per tunnel, based on criticality classification
Default to direct Non-Meraki VPN Peer; reserve the vMX/Auto VPN alternative specifically for tunnels where native dual-WAN failover is a hard requirement.
Validate subnet uniqueness and confirm IKE version compatibility across the full topology
Resolve any overlapping subnets and confirm each tunnel's required IKE version against its Azure VPN Gateway's connection type before configuring anything.
Select and validate a pilot batch — 5 to 10 tunnels representing a range of criticality and configuration complexity
Include at least one tunnel with a custom (non-default) IPsec policy in the pilot batch to validate the Custom configuration path, not just the Azure preset path.
Configure the pilot batch on the MX250 using Non-Meraki VPN Peer entries, starting from the Azure preset where applicable
Rotate PSKs to newly-generated values as part of this step, storing them in a proper secrets management system rather than plaintext documentation.
Cut over the pilot batch during a defined maintenance window and validate thoroughly
Confirm Phase 1/Phase 2 establishment, correct route propagation, and actual application-level connectivity — not just tunnel-up status — before declaring the pilot successful.
Roll out subsequent waves in batches, sized to what can be validated and rolled back confidently within one maintenance window each
Sequence waves by criticality — lower-risk tunnels earlier, building confidence and process refinement before migrating the most critical connections.
For any tunnel requiring dual-WAN failover, implement and test the scripted failover mechanism explicitly before considering that tunnel's migration complete
Don't treat "tunnel is up on the primary uplink" as done for tunnels classified as needing HA — validate the actual failover behavior under a simulated WAN1 outage.
Decommission the corresponding ASA configuration only after each wave's tunnels have been stable in production for a defined observation period
Keep the ASA configuration intact and available as a rollback path until confidence in the new tunnel is genuinely established, not just immediately after cutover.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Assuming Auto VPN applies to these Azure connections because the org is "moving to Meraki" | "Meraki's whole pitch is automatic VPN" | Auto VPN only operates between Meraki devices — Azure VPN Gateway isn't one, so every tunnel requires the manual Non-Meraki VPN Peer mechanism instead |
| Configuring the MX250 side without first confirming each Azure Gateway's route-based/policy-based type | "We'll just try IKEv2 everywhere, it's newer" | Azure's connection type dictates the IKE version, not a preference — a mismatch means Phase 1 never negotiates, regardless of which version seems more modern |
| Assuming dual-WAN failover works the same as the outgoing ASA HA pair | "Meraki is cloud-managed, failover should just work" | Non-Meraki VPN Peer tunnels bind to a single uplink and don't fail over automatically — this needs explicit scripted handling or the vMX/Auto VPN alternative |
| Migrating all 100+ tunnels in a single flag-day cutover | "One clean cutover is simpler to coordinate" | A phased, wave-based approach with a validated pilot batch catches configuration and compatibility issues at small scale before they affect the whole estate |
| Copying existing PSKs forward unchanged instead of rotating them | "Less to change, less that can go wrong" | This migration is a legitimate, low-friction opportunity to rotate every PSK to a newly-generated value and move them into proper secrets management |
| Decommissioning ASA configuration immediately after each tunnel shows as "up" on the MX250 | "The tunnel is established, migration complete" | Tunnel-up status doesn't confirm correct route propagation or actual application connectivity — validate thoroughly and observe stability before removing the rollback path |
Key Takeaways
Frequently Asked Questions
Related FAVORZENITH Articles
- How to Deploy Azure Site-to-Site VPN Prerequisites: Gateway SKUs, Subnets, and IPsec Parameters
- Azure Network Security Group Rules Explained: Inbound, Outbound, Priority, and Default Rules
- Hub-and-Spoke vs Virtual WAN: A Practical Comparison for Enterprise Azure Networking
- Enterprise Network Segmentation Patterns for Azure: Isolation Without Sacrificing Manageability