Fortinet Secure SD-WAN vs. Cisco Meraki MX
Competitive Technical Intelligence & SE Battlecard
Applicable to FortiOS 7.4 / 7.6 on FortiGate platforms with NP7, CP9/CP10, and SOC4/SOC5 silicon.
Section 1 — Technical Competitive Intelligence Notes
1.1 Silicon Architecture: Purpose-Built ASIC vs. Generic Compute
FortiGate platforms are architecturally distinct from virtually every competing SD-WAN edge in the market because data-plane processing is offloaded from the host CPU onto purpose-built silicon. Three families matter for SD-WAN conversations:
- NP7 (Network Processor 7) — Handles IPsec encryption and decryption, session setup and teardown, NAT, routing lookups, and overlay encapsulation entirely in hardware. Tunnel throughput is not bound by general-purpose cores.
- CP9 / CP10 (Content Processor) — Offloads SSL/TLS handshake processing, AES-GCM bulk crypto, and IPS pattern matching against FortiGuard signatures. SSL deep inspection becomes a near-line-rate operation rather than a CPU tax.
- SOC4 / SOC5 (System-on-Chip) — Integrates NP and CP functionality directly into the silicon on branch-class platforms (40F through 200F class). The branch box gets the same architectural advantage that historically only mid-range chassis enjoyed.
The architectural consequence is encryption offloading and signature matching execute on dedicated pipelines, leaving the host x86 cores free for control-plane work (BGP daemon, SD-WAN orchestrator, FortiManager sync, FortiGuard updates). When an SE enables SSL inspection, IPS, AV, and application control on a FortiGate, throughput degradation is measured in single-digit percentages on properly sized platforms.
Cisco Meraki MX appliances run on commodity x86 (Intel) or ARM-class compute with no asymmetric data-plane acceleration. Every feature beyond stateful L4 forwarding (Snort-based IDS/IPS, AMP cloud lookups, content filtering, deep packet application classification) competes for the same general-purpose cores. Meraki’s own published datasheets reflect this: max stateful firewall throughput and “advanced security throughput” are listed as two distinct numbers, with the latter typically representing a 40 to 60 percent reduction. SSL inspection at scale is not a viable on-box function on the MX line; Meraki’s architectural answer for deep TLS work is to redirect traffic to a separate cloud security stack.
This is the central architectural asymmetry that drives every other capability gap.
1.2 Overlay Architecture: ADVPN Dynamic Shortcuts vs. Static Auto VPN
Fortinet Auto-Discovery VPN (ADVPN) is a hub-and-spoke overlay augmented with on-demand spoke-to-spoke shortcut tunnels. The mechanics:
- All spokes maintain a persistent IPsec tunnel to one or more hubs.
- iBGP runs over the overlay, with the hub typically configured as a route reflector. Spokes learn each other’s prefixes via the hub.
- When a spoke originates a flow toward another spoke, the hub injects an ADVPN shortcut offer message. The two spokes perform an IKEv2 negotiation directly and establish a transient site-to-site tunnel.
- Subsequent packets in the flow ride the direct shortcut, bypassing the hub entirely.
- An idle timer tears down unused shortcuts, reclaiming resources.
The operational gains are significant: hub CPU and crypto load stay flat as the spoke count grows, latency for inter-branch traffic collapses to near-direct internet RTT, and the topology scales into the thousands of sites without a redesign. Because BGP is the underlying control plane, route-maps, prefix-lists, AS-path prepending, community matching, and conditional advertisement are all available. Regional hub designs (e.g., NA hub, EMEA hub, APAC hub with inter-region iBGP) are straightforward.
Cisco Meraki Auto VPN is constrained by comparison. The dashboard offers two topology models: hub-and-spoke or full mesh. Full mesh scales as N(N-1)/2 tunnels and runs out of headroom at moderate site counts. There is no dynamic on-demand shortcut establishment, meaning the topology is statically defined at the dashboard layer and instantiated through the cloud. BGP is supported on MX appliances but routing policy granularity is constrained relative to a full Quagga/FRR-style dynamic routing daemon. Complex multi-region routing, selective route leaking between VRFs, or policy-driven path selection based on AS-path or community attributes is where Meraki’s “black-box” simplification stops being a feature.
1.3 SD-WAN Steering, FEC, and Packet Duplication
FortiOS implements SD-WAN as a multi-layered transport remediation stack:
- Active SLA probes measure latency, jitter, and loss per member interface against configurable thresholds. Probe targets can be FortiGuard servers, customer-controlled probe endpoints, or arbitrary IP destinations.
- Passive WAN health monitoring infers underlay quality from in-band session telemetry, useful for asymmetric or one-way path issues.
- Application identification is performed via FortiGuard’s signature library (thousands of applications) augmented with first-packet identification heuristics and TLS SNI inspection.
- Path selection rules can match on application, user, source, destination, schedule, or any combination, and steer to a specific member, a priority list, or based on the lowest-cost SLA-compliant member.
- Forward Error Correction (FEC) generates parity packets across a window of original packets. A receiver experiencing single-packet loss can reconstruct the missing data without triggering a retransmit. This is critical for UDP-based real-time media on lossy circuits.
- Packet Duplication sends identical copies of the same packet across two or more WAN members simultaneously. The receiving FortiGate accepts the first arrival and discards duplicates. The effect is zero perceptible loss on the protected flow even if one underlay experiences brownouts, with the cost being bandwidth.
The combination of sub-second SLA convergence, in-flight FEC, and selective packet duplication produces session-preserving behavior during underlay degradation. Voice calls, RDP sessions, and video conferences ride through events that would otherwise drop.
Meraki MX SD-WAN performs uplink performance metric collection and supports performance-based path selection at flow initiation. Once a flow is pinned to an uplink, mid-flow remediation is limited. There is no equivalent to in-flight packet duplication across members in the MX product line, and FEC support is not a native, generally-deployed feature on par with Fortinet’s. The result is that flow failover on Meraki tends to be observable to the user, particularly for stateful protocols and real-time media.
1.4 Edge-to-SASE Continuity (Hybrid Mastery)
FortiSASE is delivered as a cloud SSE stack (Secure Web Gateway, ZTNA, CASB inline, FWaaS, DLP) built on the same FortiOS components that run on a FortiGate. Customers can design a portfolio of branch postures:
- Thick branch: Full on-box NGFW with SD-WAN, IPS, SSL inspection, application control, and direct internet breakout, with traffic optionally forwarded to FortiSASE only for specific use cases such as roaming user enforcement or SaaS visibility.
- Thin branch: Minimal local enforcement with the FortiGate operating primarily as an SD-WAN edge, forwarding all internet-bound traffic to FortiSASE PoPs for inspection.
- Roaming user: FortiClient on the endpoint enforces ZTNA and tunnels traffic to FortiSASE, with consistent policy constructs to the branch.
The same management surfaces (FortiManager, FortiAnalyzer) and the same policy semantics span both worlds, so a customer can shift the policy enforcement point without rebuilding policy.
Cisco’s equivalent stack involves separate platforms. Meraki MX handles the branch. Cisco Secure Access (the renamed and bundled Umbrella plus successor offering) handles the cloud security plane. Cisco+ Secure Connect attempts to unify the consumption model, but the underlying dashboards, policy objects, and operational tooling are distinct from Meraki’s dashboard. The net effect is a multi-pane operational model where branch policy, cloud security policy, and ZTNA policy are authored in different places with different object models.
Section 2 — Feature & Performance Knockout Matrix
| Capability | FortiGate Secure SD-WAN (FortiOS 7.4 / 7.6) | Cisco Meraki MX |
|---|---|---|
| Custom data-plane silicon (ASIC) | Present — NP7, CP9/CP10, SOC4/SOC5 | Absent — generic x86 / ARM compute only |
| On-box SSL/TLS deep inspection throughput | Multi-gigabit on mid-range platforms via CP9 offload | Heavily throttled; not positioned for high-volume TLS inspection on-box |
| Throughput impact when full UTM stack is enabled | Single-digit to low-double-digit percentage on properly sized platforms | 40 to 60 percent reduction documented in datasheets (“advanced security throughput” line) |
| Overlay topology model | ADVPN with on-demand dynamic spoke-to-spoke shortcuts | Auto VPN with static hub-and-spoke or full mesh, dashboard-defined |
| Dynamic spoke-to-spoke tunneling | Yes — IKEv2 shortcut negotiation triggered by traffic flow | No — topology is statically instantiated |
| Routing protocol depth | Full BGP, OSPF, RIP, IS-IS via dynamic routing daemon with route-maps, prefix-lists, AS-path, community matching | BGP supported with reduced policy granularity; OSPF limited |
| Multi-region / multi-hub scaling | Designed for it — regional hubs, route reflectors, hierarchical iBGP | Constrained by mesh scaling and dashboard topology model |
| Forward Error Correction (FEC) | Native, per-policy, configurable redundancy ratios | Not a native, generally-deployed feature equivalent |
| In-flight packet duplication across WAN members | Native — per-policy enablement on critical apps | Not present in MX product line |
| Application identification breadth | FortiGuard signature library, thousands of applications, first-packet ID | Cloud-curated app library, smaller match surface, slower add cadence |
| Sub-second SLA convergence | Configurable down to sub-second probe intervals with hold-down logic | Coarser failover behavior, observable session impact |
| SASE convergence path | FortiSASE on same FortiOS code base, unified policy semantics | Separate platform (Cisco Secure Access), separate dashboards and object models |
| Management model | FortiManager (on-prem or cloud), FortiAnalyzer for analytics, FortiCloud for lighter footprint | Meraki Dashboard only, cloud-mandatory, no on-prem option |
| Air-gapped / sovereign deployment | Fully supported via FortiManager on-prem | Not supported — cloud dashboard is mandatory |
| Per-flow vs. per-packet steering | Both — per-packet steering available for protected real-time apps | Per-flow only |
Section 3 — Infographic Blueprint
3.1 Visual Headline Concept
Title (top banner): “Converged Performance vs. Compute Compromise”
Sub-headline: “Why the Silicon Underneath Decides the Bake-Off”
3.2 Side-by-Side Edge Architecture Diagram (ASCII Layout)
╔══════════════════════════════════════════╗ ╔══════════════════════════════════════════╗
║ FORTIGATE CONVERGED EDGE ║ ║ MERAKI MX BOTTLENECKED EDGE ║
║ Hardware-Accelerated NGFW + SD-WAN ║ ║ Generic Compute, Software Everything ║
╠══════════════════════════════════════════╣ ╠══════════════════════════════════════════╣
║ ║ ║ ║
║ ┌──────┐ ┌──────┐ ┌──────┐ ║ ║ ┌──────────────────────────────────┐ ║
║ │ NP7 │ │ CP9 │ │ SOC4 │ ASICs ║ ║ │ x86 / ARM GENERAL-PURPOSE CPU │ ║
║ └──┬───┘ └──┬───┘ └──┬───┘ ║ ║ └────────────────┬─────────────────┘ ║
║ │ │ │ ║ ║ │ ║
║ ▼ ▼ ▼ ║ ║ ▼ ║
║ IPsec SSL/TLS Routing ║ ║ Stateful FW + Snort IPS + AMP + ║
║ Offload Inspect Lookup ║ ║ Content Filter + App ID ║
║ @wire @wire @wire ║ ║ ALL share same cores ║
║ ║ ║ ║
║ ┌──────────────────────────────────┐ ║ ║ ┌──────────────────────────────────┐ ║
║ │ Host x86 free for: │ ║ ║ │ Throughput drops 40-60% when │ ║
║ │ • BGP/OSPF daemon │ ║ ║ │ full security stack enabled │ ║
║ │ • SD-WAN orchestrator │ ║ ║ │ │ ║
║ │ • FortiManager sync │ ║ ║ │ No on-box SSL inspection at │ ║
║ │ • FortiGuard updates │ ║ ║ │ enterprise scale │ ║
║ └──────────────────────────────────┘ ║ ║ └──────────────────────────────────┘ ║
║ ║ ║ ║
║ RESULT: Multi-Gbps NGFW + SD-WAN ║ ║ RESULT: Pick speed OR security, ║
║ with full UTM AND SSL inspection ON ║ ║ not both, at scale ║
║ ║ ║ ║
╚══════════════════════════════════════════╝ ╚══════════════════════════════════════════╝
3.3 Overlay Topology Diagram (ASCII Layout)
FORTIGATE ADVPN MERAKI AUTO VPN
Dynamic Shortcuts Static Topology
───────────────── ───────────────
[HUB] [HUB]
/ | \ / | \
/ | \ <-- iBGP / | \
/ | \ route reflector / | \
[S1] [S2] [S3] [S1] [S2] [S3]
\ . / (no shortcuts;
\ . / all spoke-spoke
\ . / <-- on-demand traffic hairpins
\ . / shortcut tunnel through hub OR
\./ (IKEv2 negotiated requires full
[S2] on traffic trigger) mesh which does
not scale)
Spoke-spoke = direct, low RTT Spoke-spoke = hub hairpin
Hub load = flat as N grows Hub load = scales linearly
BGP policy = full route-maps BGP policy = restricted
3.4 Transport Remediation Visual
PROTECTED VOICE/VIDEO FLOW OVER LOSSY LINKS
FORTINET: MERAKI:
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ Flow │ │ Flow │
│ ├─► copy → Link A (MPLS) │ │ └─► Link A (selected) │
│ └─► copy → Link B (LTE) │ │ │
│ │ │ Link A degrades │
│ Receiver: first wins, │ │ Detection │
│ duplicate dropped │ │ Failover │
│ │ │ Session reset / drop │
│ Loss on either link = │ │ on real-time media │
│ zero user-visible impact │ │ │
│ │ │ │
│ + FEC parity for residual │ │ (no native packet dup) │
│ single-packet loss │ │ │
└─────────────────────────────┘ └─────────────────────────────┘
3.5 Sales Engineer Battlecard — Top 3 Technical Kill Shots
┌════════════════════════════════════════════════════════════════════┐
║ SE BATTLECARD: HOW TO DISQUALIFY MERAKI IN A POC ║
║ ║
║ KILL SHOT #1 — DEMAND ON-BOX SSL INSPECTION AT SCALE ║
║ ────────────────────────────────────────────────────── ║
║ Set the POC success criteria as: "Demonstrate sustained ║
║ 1+ Gbps of deep SSL/TLS inspection with IPS, AV, and app ║
║ control enabled on the branch edge." ║
║ ║
║ Why it works: Meraki MX has no CP9-equivalent crypto offload. ║
║ The MX will either fail the throughput target or the Cisco SE ║
║ will pivot to "redirect TLS to Cisco Secure Access," which ║
║ introduces a second platform, second dashboard, and a cloud ║
║ round-trip. The conversation has already left the MX box. ║
║ ║
║ ║
║ KILL SHOT #2 — MULTI-HUB, MULTI-REGION BGP WITH POLICY ║
║ ────────────────────────────────────────────────────── ║
║ Build the POC topology as: 3 regional hubs, iBGP overlay, ║
║ route reflection, selective prefix advertisement between ║
║ regions using route-maps and BGP communities, with dynamic ║
║ spoke-to-spoke shortcuts on demand. ║
║ ║
║ Why it works: ADVPN delivers this natively in FortiOS with ║
║ standard BGP knobs. Meraki Auto VPN's topology model is ║
║ dashboard-driven and policy granularity is constrained. The ║
║ customer's network architect will see the routing depth gap ║
║ immediately. ║
║ ║
║ ║
║ KILL SHOT #3 — INTRODUCE 1-3% PACKET LOSS, RUN VOICE/VIDEO ║
║ ────────────────────────────────────────────────────── ║
║ Use a WAN impairment tool to inject 1-3% loss and 20-50 ms ║
║ of jitter onto one underlay member. Run a Teams or Webex call ║
║ across the SD-WAN, then trigger a brownout event mid-call. ║
║ ║
║ Why it works: Fortinet packet duplication plus FEC preserves ║
║ the call with no user-perceptible impact. Meraki performs a ║
║ per-flow failover that is audibly disruptive on real-time ║
║ media. The end user is the judge, and the result is binary. ║
║ ║
└════════════════════════════════════════════════════════════════════┘
3.6 Closing Callout (footer of infographic)
One OS. One Policy Model. One Vendor. FortiOS spans the branch, the data center, and FortiSASE. The same policy objects, the same management plane, and the same security stack follow the traffic wherever the customer chooses to enforce it. Meraki delivers simplicity at the edge but fragments the moment a customer needs scale, depth, or convergence.
Source: FortiOS 7.4 / 7.6 administration documentation, FortiGate platform datasheets (NP7/CP9/SOC4 architectures), Meraki MX series datasheets (advanced security throughput specifications), and published Auto VPN / ADVPN reference architectures. Performance claims should be validated against the specific platforms quoted in any active opportunity.