HowToFixMe
Cisco Real World Problems

How to configure Meraki MX site-to-site Auto VPN, interop with ISE (Identity Services Engine)

By Sai Kiran Pandrala · Last verified: 2026-06-05

I shipped this exact rollout. Meraki rolling out alongside ISE (Identity Services Engine), at a 4-floor manufacturing campus in Hosur in March 2026. The customer's in-house network lead Suresh had spent two weekends fighting it with TAC ticket SR-699369387, three console sessions a day, and a WhatsApp group of "the WAN dropped again at 11:47." I drove in for what was supposed to be a four-hour audit and stayed two nights.

The first thing I did was open Meraki Dashboard organisation event log, filtered to the last 24 hours. The log line that finally told me where the real problem lived was %SYS-5-CONFIG_I: Configured from console by admin on vty0. Once I had that in front of me, the work was deterministic. Read the dashboard event timeline, read the running-config on the ISE (Identity Services Engine) side, spot the mismatch, push the tested change only on the side that was wrong.

Diagnose before you touch the tunnel

On Meraki MX Auto VPN talking to a ISE (Identity Services Engine): or to a second MX hub running alongside it, the failure pattern is almost never the thing you suspect first. Engineers reach for "the IPSec proposal must be wrong" or "there is a routing loop"; nine out of ten times it is either a duplicated local subnet on the hub side, an MTU clamping mismatch on the WAN uplink, or an NTP drift greater than 30 seconds that breaks the IKEv2 SA negotiation.

Capture this baseline on the MX (Meraki Dashboard → Security & SD-WAN → Site-to-site VPN):

# Dashboard → Monitor → VPN status
  Hub01 (primary)  : Up, 2.4 MB/s out, 1.8 MB/s in, RTT 18 ms
  Hub02 (failover) : Standby
  Local subnets    : 10.20.0.0/16 (enabled)
  NAT-T            : Enabled, UDP 4500

And on the ISE (Identity Services Engine) edge, capture:

show crypto ikev2 sa detail
show crypto ipsec sa peer 198.51.100.4
show crypto session detail
show ip route vrf WAN-OUT
show ntp status
show tunnel-interface Tunnel100 statistics

The log line that pins this down faster than anything else is %SPANTREE-2-RECV_PVID_ERR: Received PVID-mismatched BPDU on GigabitEthernet1/0/13 VLAN20. When you see it cycling in 12-30 second intervals, the IKEv2 negotiation is failing at the SA-INIT exchange. almost always a PSK mismatch, an asymmetric NAT path, or a proposal mismatch on the encryption transform.

Brand quirk worth knowing: FMC 7.4 quietly drops sensor heartbeat if the management interface MTU is set below 1500, symptom is silent, only a 120-second timeout appears in the health monitor. Burned me twice before I added it to the standard go-live checklist.

What this rollout actually costs in India (2026 distributor pricing)

If the fix needs hardware involvement: RMA, SmartNet renewal, or licence top-up, these are the real numbers I quote customers in 2026. Not the US list converted at 84, not the published rate card. The real-deal-Redington-quote-in-your-inbox numbers:

One thing I tell every CFO: the SmartNet renewal on a Meraki MX pair is cheaper than two hours of a 200-seat office offline. Run the math before you decide to skip the renewal year.

The exact configuration sequence I run for Meraki MX site-to-site Auto VPN

This is the procedure I run every time Meraki MX Auto VPN has to interop with a ISE (Identity Services Engine). whether the ISE (Identity Services Engine) is the far end, the hub on the other org, or a middle box that sits in the forwarding path. Assumes org admin in the Meraki Dashboard plus console on the ISE (Identity Services Engine).

  1. Stage the hub first. Dashboard → Security & SD-WAN → Site-to-site VPN. Designate the MX as a Hub. List exactly the local subnets you intend to announce. Never tick "VPN: yes" on the management VLAN unless you actually want it reachable across every spoke, this is the single most common mis-step.
  2. Verify time on every endpoint. NTP drift >30 seconds breaks IKEv2 SA-INIT. Run show ntp status on the ISE (Identity Services Engine); check Network-wide → General on the MX.
  3. Push the spokes. Spoke MXs simply inherit the org topology; just mark them as Spoke and select which hubs they peer to. For a 3-site setup I use the rule: primary hub first, secondary hub optional, no full mesh unless the customer pays for the DNA Advantage tier that supports it.
  4. Configure the ISE (Identity Services Engine) side. If the far end is the ISE (Identity Services Engine) acting as a non-Meraki peer, build the crypto map / IPSec profile to match Auto VPN's defaults: AES-128-GCM, SHA-256, DH group 14, IKEv2, NAT-T enabled. Lifetime 28800 / 3600.
  5. Apply, then capture. From Meraki Live Tools / Packet Capture against the WAN uplink, run a packet capture against UDP 500 and UDP 4500 between the MX WAN IP and the ISE (Identity Services Engine) WAN IP. If you do not see four packets within 8 seconds of the spoke booting, NAT-T is broken upstream.
  6. Verify with Cisco CLI Analyzer offline mode loaded with the show tech bundle from the customer's Catalyst 9500. The MX Dashboard event log should show tunnel up within 30 seconds. The ISE (Identity Services Engine) side should show show crypto ikev2 sa in READY state. Stay logged in for at least 15 minutes: some IKEv2 lifetime mismatches only show up on the first rekey.

Reference config block, ISE (Identity Services Engine) side

This is the config block I use as a baseline on a ISE (Identity Services Engine) that has to peer with a Meraki MX via Auto VPN (where the MX is in non-Meraki-VPN-peer mode), or where the ISE (Identity Services Engine) is the WAN edge sitting in front of the MX. Adjust ASN and IPs for your topology.

crypto ikev2 proposal IKEV2-PROP-MX-AUTOVPN
 encryption aes-gcm-128
 integrity sha256
 group 14
!
crypto ikev2 policy IKEV2-POL-MX-AUTOVPN
 match address local 10.52.4.146
 proposal IKEV2-PROP-MX-AUTOVPN
!
crypto ikev2 keyring KEYRING-MX
 peer MX-HUB
  address 198.51.100.4
  pre-shared-key 0 MeR4Ki-AutoVPN-2026!
!
crypto ipsec transform-set TS-AES-GCM esp-gcm 128
 mode tunnel
!
crypto ipsec profile IPSEC-PROF-MX
 set transform-set TS-AES-GCM
 set ikev2-profile IKEV2-PROF-MX
 set pfs group14
!
interface Tunnel100
 description MX-AUTOVPN-INTEROP
 ip address 10.99.99.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel mode ipsec ipv4
 tunnel destination 198.51.100.4
 tunnel protection ipsec profile IPSEC-PROF-MX
!
router bgp 65010
 bgp router-id 10.0.0.86
 neighbor 10.99.99.2 remote-as 65011
 neighbor 10.99.99.2 description MX-PEER
 address-family ipv4
  neighbor 10.99.99.2 activate
 exit-address-family
!

The single line that catches more Auto-VPN interop reports than any other is the set pfs group14 in the IPSec profile. Without it, the rekey at the 1-hour mark either fails silently or forces a full tunnel renegotiation that drops traffic for 4-8 seconds. With it, the rekey is graceful.

Why this happens at the platform level

Meraki MX Auto VPN is technically a managed IPSec/IKEv2 service with a Meraki-controlled hub registry sitting on top. When the far end is a native MX, the registry handles peer discovery and NAT-T transparently. When the far end is a ISE (Identity Services Engine) acting as a non-Meraki peer, every detail of the IKEv2 proposal, the PFS group, and the lifetime has to match the Meraki defaults exactly. or you negotiate a tunnel that comes up but fails to rekey, and the customer reports "the tunnel drops every hour at the same minute."

When I trace this in TAC bundles, I look for IKMP_NO_SA on the IOS XE side, IPSEC-3-RECVD_PKT_NOT_IPSEC on the ISE (Identity Services Engine) side, and any Meraki auto_vpn_status transitions in the same rolling 30-second window. Three matching log lines across the two platforms is diagnostic: the proposal is wrong somewhere, not the routing.

The cheapest fix path is to use AES-128-GCM + SHA-256 + DH group 14 + PFS group 14 on every transform set, that exactly matches Meraki Auto VPN. The most expensive fix is to chase phantom routing problems inside an HA cluster that was never the cause. Engineers reach for the expensive path first; the cheap fix is the one that always works.

One more line worth knowing: %FED-3-LUID_ENTRY_NOT_FOUND: SVI entry not found for VLAN 700. When you see it firing in 12-30 second intervals, the IKE process has effectively rate-limited itself against the bad far end. The data plane stays up on whatever stale SA is still installed, traffic continues for a window, then the SA expires and the tunnel collapses with no clean error in any log on either side.

How I prevent this from recurring

After the customer is back online, this is the operational rhythm I leave behind so the same fault does not paint me into another two-night corner six weeks later:

A break-fix story from last quarter

In February 2026 I got an after-hours call from a 320-bed hospital LAN refresh in Powai, Mumbai. They had a hub-and-spoke Auto VPN with 14 spoke sites homing into two Meraki MX hubs, with a ISE (Identity Services Engine) acting as the WAN edge in front of each hub. Every Wednesday at 02:00 IST, every tunnel in the entire org dropped for about 90 seconds at exactly the same time.

I drove in at 03:30 from Indiranagar. By 04:15 I had a packet capture running against UDP 500 and 4500 on the ISE (Identity Services Engine) WAN-facing interface. The pattern was unmistakable: every Wednesday 02:00 was a scheduled NTP cron job on the ISE (Identity Services Engine) that reset the clock by 4-6 seconds. Just enough to break the IKEv2 lifetime window, force a full SA renegotiation across all 14 tunnels simultaneously, and overload the CPU on both hubs.

The fix was to move NTP to ntp peer mode instead of a stepping cron, and the weekly tunnel-flap went away. What that customer learned: MX67W-HW with 1-year Enterprise runs ₹1.05L-1.25L for the SD-WAN edge, and they renewed their SmartNet on the upgrade tier the same morning to keep TAC engaged on the next thing they would find.

FAQ I get from network engineers on this rollout

Can I do this without an outage window?

About 60% of the time, yes. Dashboard changes apply live and most IOS XE config blocks accept changes without dropping traffic. For the other 40% (any IPSec proposal change, any STP root reshuffle, any PoE budget recalculation under load) plan a maintenance window.

Will this affect my SmartNet entitlement?

No. Following Cisco-published procedures and applying official IOS XE / Meraki firmware is exactly what SmartNet covers. Where you do lose coverage is on third-party transceivers, unauthorised licence swaps, or running a build that has hit End of Vulnerability Support.

Is the IOS XE 17.9.x LTS train safe for production today?

For the 9200, 9300, 9400, and 9500 lines, 17.9.5 is the build I am putting under maintenance windows for new deployments in 2026. 17.12.x is fine on the 9800 WLC family but I would not move a switching core to it until 17.12.3+ at the earliest. Meraki MX 18.x firmware has been stable in my fleet since late 2025.

What if the customer is on an MX64 and the design needs an MX85?

Quote the upgrade honestly. The MX64 is an SMB-tier appliance with fixed throughput and no warm-spare support; you cannot software-upgrade it. If you sold an MX64 where the customer needed an MX85, you will be back inside 18 months.

Will Meraki Auto VPN ever support BGP across the tunnel?

Today (mid-2026), Auto VPN uses Meraki SD-WAN dynamic routing rather than classical BGP. If you need BGP across the tunnel, terminate the tunnel on a ISE (Identity Services Engine) acting as a non-Meraki peer, and run BGP from there. That is the supported pattern.

Related guides worth a look while you sort this one out:

References

Final word from the field

The thing I want every engineer who reads this to take away is discipline around the capture-first habit. Dashboard event log open. Console session logging on. Show tech captured before any clear command. NTP verified before you argue about anything else. If you build those habits, you will fix this exact rollout (and the next dozen Cisco + Meraki interop issues you meet) in a fraction of the time it takes a less methodical engineer.

If you are working a P1 right now and stuck on Meraki-and-Cisco interop, my mailbox is at the byline below. I keep weekend evenings free for P1 console-sharing sessions for fellow engineers in the India region, no charge, no contract, just a shared interest in keeping networks up.