Cisco Meraki MX85: SD-WAN, AutoVPN, and Branch Observability

The MX85 sits in the sweet spot of Meraki's security appliance line: enough throughput for a mid-size branch or small campus, dual WAN with fiber options, and the full MX feature set — stateful firewall, SD-WAN, AutoVPN, and (with Advanced Security licensing) IDS/IPS, malware protection, and content filtering. Like everything Meraki, the pitch is operational: the entire fleet is managed and monitored from the Dashboard, and everything the Dashboard shows is available over a clean REST API.

Here's how I approach deploying and operating one.

Placement and Interfaces

The MX85 gives you dedicated WAN uplinks (including SFP ports for fiber handoffs) plus LAN ports you'll typically trunk to a downstream switch. Design notes:

• Routed vs. passthrough: In routed (NAT) mode the MX is the L3 edge — DHCP, NAT, firewall. In passthrough/VPN-concentrator mode it bridges, useful when it sits behind another edge router or acts as a hub concentrator. Branch deployments are almost always routed mode.
• Don't hang users off the MX directly. Use it as the edge and let a switch (Meraki MS or anything else) do access. The MX's job is WAN, security, and VPN.
• Sizing: Meraki publishes recommended user counts and throughput per model — and the numbers assume security services are on. If you're running IDS/IPS and AMP, size against the advanced-security throughput figure, not the stateful-firewall one.

Dual WAN and SD-WAN Policies

With two active uplinks the MX85 does three distinct things people often conflate:

1. Load balancing — distribute new flows across both uplinks proportionally to configured bandwidth.
2. Failover — uplink health is tracked with connectivity tests; when WAN1 degrades, flows move to WAN2. VoIP calls survive failover surprisingly well over AutoVPN.
3. Policy-based SD-WAN — the interesting one. Performance classes define thresholds (latency, jitter, loss), and SD-WAN policies pin traffic classes to the uplink that currently meets the class. Classic setup:
   • Voice/video (or "custom expressions" matching your UC platform) → "best for VoIP" — the MX continuously probes both VPN paths and moves the traffic dynamically.
   • Bulk backup/replication → prefer the cheap circuit.
   • Everything else → load balance.

The probes that power this run inside AutoVPN tunnels between MXs, so dynamic path selection applies to VPN traffic — for plain internet-bound traffic you're choosing uplinks with flow preferences rather than live performance data.

AutoVPN

AutoVPN is still the best thing about the MX line. Site-to-site IPsec that would take an afternoon of crypto-map wrangling elsewhere is a two-minute Dashboard operation:

• Pick hub or spoke per site; spokes list their hubs in priority order.
• Select which VLANs/subnets each site advertises into the VPN.
• The Meraki cloud brokers registration — devices learn each other's public IPs and punch through NAT automatically; keys rotate without you.

Full-mesh, hub-and-spoke, or dual-hub DC designs are all just topology choices in the UI. Behind the scenes routes propagate automatically, and you can layer OSPF/BGP route advertisement at the hubs for integration with the rest of your network. For internet breakout you choose per-spoke: local breakout (split tunnel) or full tunnel through a hub — or hand web traffic to a cloud security layer like Zscaler via IPsec/PBR if that's your architecture (see my Zscaler article).

Security Services

With the Advanced Security license the MX85 runs:

• L3/L7 firewall rules — L7 rules can match applications ("block BitTorrent") and countries, not just ports.
• IDS/IPS — Snort-based, three sensitivity presets; start in detection mode, review hits for a week, then move to prevention.
• AMP — file reputation checks on HTTP downloads with retrospective alerts if a file's verdict later turns malicious.
• Content filtering — category-based URL filtering.

The honest caveat: TLS-heavy traffic limits what IDS and content inspection can see. Treat the MX as solid perimeter hygiene, and pair with endpoint/cloud controls for a real defense-in-depth story.

High Availability

Two MX85s form a warm spare pair using VRRP on the LAN side: same configuration, shared virtual IP (or shared uplink IPs, depending on design), automatic failover when the primary stops responding. Notes from the field:

• The spare needs its own uplink connectivity — a spare with no WAN is decoration.
• Failover is stateful for AutoVPN but sessions through NAT may reset; set expectations accordingly.
• Test it. Pull the primary's power during a maintenance window once a quarter. HA you haven't tested is a rumor.

Observability: Dashboard, API, and Beyond

Day-to-day, the Dashboard's Security & SD-WAN → Appliance status and Uplink pages give you live and historical loss/latency per uplink, per-flow traffic analytics, and VPN health. But the real leverage is programmatic:

# Uplink loss/latency history for a device (5-minute buckets)
curl -s -H "X-Cisco-Meraki-API-Key: $MERAKI_KEY" \
  "https://api.meraki.com/api/v1/devices/$SERIAL/lossAndLatencyHistory?ip=8.8.8.8&uplink=wan1" | jq .

# Org-wide uplink status — one call, every MX
curl -s -H "X-Cisco-Meraki-API-Key: $MERAKI_KEY" \
  "https://api.meraki.com/api/v1/organizations/$ORG_ID/appliance/uplink/statuses" | jq .

Ways to get MX telemetry into a central observability platform:

1. Dashboard API polling — the endpoints above, on a schedule.
2. Webhooks — Dashboard alerts (uplink failover, VPN down, IDS event) POSTed to your alerting pipeline in seconds.
3. Syslog — the MX exports flows, URLs, IDS events, and security events to any syslog collector.
4. NetFlow — traffic reporting to a flow collector.
5. ktranslate's Meraki integration — pulls Dashboard API data straight into New Relic so branch uplink health lands next to your APM data. This combination — MX uplink loss/latency in the same NRQL workspace as application error rates — is the fastest "is it the circuit or the app?" answer I've found. Details in my New Relic network observability article.

Terraform It

The Meraki Terraform provider (and Ansible collection) covers networks, VLANs, firewall rules, and SD-WAN settings, which makes branch bring-up a code review instead of a checklist:

resource "meraki_networks_appliance_vlans" "voice" {
  network_id = meraki_network.branch.id
  vlan_id    = "30"
  name       = "VOICE"
  subnet     = "10.30.0.0/24"
  appliance_ip = "10.30.0.1"
}

Config-as-code plus AutoVPN means a new branch is: rack the MX85, claim it into the network Terraform already built, and watch it join the mesh.

Verdict

The MX85 isn't the deepest packet-processing box you can buy — it's the one that makes a 30-site WAN operable by a small team. Pair the Dashboard for daily driving with API/webhook export into your observability platform, and the WAN stops being the part of the stack you can't see.