Auto VPN on IOS XE Based Cisco Secure Routers
Auto VPN Overview
Auto VPN, a seamless fabric and overlay technology, is available for IOS XE Based Secure Routers in Dashboard. For additional information regarding Auto VPN's use cases, configuration within the UI, and respective functions, please visit the Auto VPN Guide.
Auto VPN may be configured via the UI or via API.
- Auto VPN on IOS XE Devices operates in a common manner for VPN Registry enablement.
- Hub to Hub routing is not available for Auto VPN
- When leveraging multiple WAN Uplinks, VPN tunnels will be built across all available uplinks.
- ECMP (Load Balancing) is not currently available. The primary interface, configured statically as the highest ID L3 interface, shall be considered primary WAN. Traffic shall be sent via the primary WAN when available.
- The following configurations are applied relative to MTU:
- ip mtu 1400 and ip tcp adjust-mss 1352.
For a detailed review of Auto VPN Configuration relative to IOS XE, please visit the Auto VPN for IOS XE Configuration Guide.
Auto VPN on IOS XE Devices leverages a standards based IKEv2 Based IPsec implementation. Key Security Association details are below:
IKE SA Parameters:
- Port: 4500 (NAT-T Forced)
- Lifetime: 8 hr
- Encryption: AES-GCM-256
- Pseudo-Random Function: SHA256
- Authentication: Dashboard-derived pair-specific PSK
- Classical key exchange: ECDH group 21 (NIST P-521)
- Post-quantum key exchange: ML-KEM-768
- PQC mode: Hybrid P-521 + ML-KEM-768
- Compatibility: ML-KEM is configured as
optional, permitting classical fallback - UDP/ESP Encap (Tunnel)
- DPD: 10-second interval, 3 retries, periodic
- MTU: 1400, Fragmentation Enabled
IPsec SA Parameters:
- Lifetime: 14,400 seconds (4 hours)
- Encryption and integrity: ESP-GCM-256
- Mode: Tunnel
- Replay Protection: 1024
- Post-quantum PFS: Enabled using
set pfs - Child-SA key exchange: Inherits ML-KEM-768 from the IKEv2 SA when PQC is negotiated
Auto VPN Routing leverages MP-BGP for prefix redistribution.
- Spokes
- A BGP Community string is applied to hubs based upon their selected priority
- A route map applies weight, matching the community string, to prefixes as they are received on the spoke
- Example: Hub Priority 1 - All prefixes received have weight 1000 applied
- Example Hub Priority 2 - All prefixes received have weight 990 applied
.png?revision=1)
- Hub
- Spokes send a community string attribute with routes as they are advertised to hubs
- A route map applies local preference, matching the community string, to prefixes as they are received on the hub.
- Example: Hub Priority 1 - All prefixes received have local_preference 1000 applied
- Example: Hub Priority 2 - All prefixes received have local_preference 990 applied
.png?revision=1)
- Hub eBGP Redistribution
- AS_PATH Prepending is performed when redistributing prefixes into the eBGP Autonomous system.
- The number of prepends is based upon the hub priority configured for the spoke.
- Example: Hub Priority 1 - All prefixes redistributed have no AS_PATH Prepending applied
- Example: Hub Priority 2 - All prefixes redistributed have 1x AS_PATH Prepending applied
Auto VPN Performance Probing
Auto VPN performance probing monitors the health and performance of each Auto VPN tunnel path. Probing measures latency, jitter, and packet loss and maintains the results independently for each traffic queue. These measurements provide the path-health information used to evaluate configured performance thresholds and support path-selection and failover decisions.
Auto VPN uses both passive sampling and active probes: Both methods update the same per-queue performance state. Active and passive measurements are processed within the Auto VPN data plane and do not require clock synchronization between peers.
Passive sampling samples client traffic every 100 ms and adds measurement metadata to selected packets already traversing the tunnel. This measures the performance experienced by live traffic.
Active probing sends synthetic probes at a 1 second interval per wired up-link or a 10 second interval on cellular up-links . Active probes maintain path measurements and reachability when client traffic is insufficient or absent.
Active Probe Intervals
The default active-probe interval depends on the uplink type:
| Uplink type | Default probe interval | Loss update | Unreachable detection |
| Non-cellular | 1 second | Approximately 8 seconds | Approximately 7 seconds |
| Cellular LTE/5G | 10 seconds | Approximately 80 seconds | Approximately 70 seconds |
Loss is updated after eight probe-timer events. A path is marked unreachable after seven consecutive unanswered active probes. Therefore:
- `loss update interval = 8 × probe interval`
- `unreachable detection time ≈ 7 × probe interval`
Changing the active-probe interval changes convergence time and probe frequency. Shorter intervals detect failures and update loss more quickly but generate more probe traffic and processing overhead.
Note: Disabling active probing removes continuous monitoring during idle periods. An otherwise idle failed tunnel might not trigger on-demand Dead Peer Detection (DPD) until user traffic is sent without receiving return traffic.
Performance Measurements
The following measurements are collected:
Latency: Round-trip time (RTT) calculated from timestamp exchanged between Auto VPN peers. The calculation accounts for the time spent processing the probe at the remote peer.
Jitter: Directional variation in packet arrival time. Jitter is calculated by comparing the spacing between packets when sent with their spacing when received.
Packet loss: Directional, per-queue loss calculated from transmitted and received sample counters collected over completed measurement intervals.
Latency and jitter are updated as new samples become available. Packet loss is updated after each complete eight-event monitor interval.
SLA Evaluation and Path Selection
Up to 16 SLA classes can be defined. Each SLA class specifies thresholds for latency, jitter, and packet loss. Auto VPN evaluates tunnel-path measurements against these thresholds and records which SLA classes each path currently satisfies.
Active probe state directly controls reachability of the BGP peering address associated with a tunnel path:
When the probe state is up, the route to the BGP peering address is installed through the corresponding Virtual-Access interface.
When the probe state is down, the route is removed so traffic can converge to another eligible Auto VPN path.
When a valid probe response returns the path to up, the peering route can be installed again.
With PfR integration, a shorter performance moving average can provide more granular policy-based traffic redirection when a path no longer satisfies the applicable SLA. This traffic steering is independent of IKE security-association cleanup.
Performance and Reachability Behavior
Latency, jitter, and packet loss are maintained independently for each of the four traffic queues. Different queues can report different performance on the same tunnel path.
Jitter and packet loss are directional. One direction can report degraded performance while the opposite direction remains healthy.
Tunnel reachability is maintained at the session level. A queue can temporarily lack a current measurement without causing the entire session to be marked unreachable.
Seven consecutive unanswered active probes mark a path unreachable. Detection time depends on the configured per-uplink probe interval.
A subsequent valid response clears the unreachable state and returns the path to a reachable state.
The first completed packet-loss interval establishes the counter baseline. A meaningful loss result is available after a subsequent completed interval.
Note: Transmit and receive counters are updated by different data-plane events and are not expected to match in a single point-in-time snapshot. Packet loss is calculated from counter changes across completed measurement intervals.
On-Demand DPD Recovery
Auto VPN uses on-demand DPD rather than running periodic DPD on every security association. On-demand DPD is triggered when traffic is sent but return traffic is not received.
Periodic path-monitor probes provide traffic when a tunnel would otherwise be idle. If the path fails, the absence of probe responses allows on-demand DPD to detect, clean up, or recover a stale security association. This provides a slower recovery safety net while active probe state supplies faster route withdrawal for traffic convergence.
PQC with Auto VPN
Overview
Post-quantum cryptography (PQC) gives Dashboard-managed IOS XE Auto VPN a stronger foundation for the quantum era without adding operational complexity. Beginning with IOS XE 26.1.1, Auto VPN uses ML-KEM-768 by default to strengthen IKEv2 key establishment and help protect encrypted connectivity against future quantum-computing threats. Customers receive this protection through the existing Auto VPN experience; there is no separate Dashboard control, topology change, or activation workflow.
How PQC Works With Auto VPN
Dashboard automatically provisions the ML-KEM-768-capable IKEv2 configuration used by Auto VPN between supported IOS XE secure routers. ML-KEM-768 strengthens tunnel key establishment while Auto VPN continues to manage topology, authentication, and tunnel operation. PQC does not introduce a separate Dashboard setting or operational lifecycle.
Backward compatibility: PQC is integrated into the existing Auto VPN architecture. IOS XE 26.1.1 is both the Dashboard onboarding minimum and the release in which PQC is enabled by default. PQC is therefore inherent to every Dashboard-managed IOS XE Auto VPN deployment, preserving the existing topology without a migration procedure.
Prerequisites and Limitations
Before operating Auto VPN with PQC, ensure the following requirements are met.
Licensing Requirements
PQC for Auto VPN is included in base Essentials licensing for Dashboard-enabled devices.
Hardware Requirements
Use a supported Dashboard-enabled IOS XE secure router. See Onboarding IOS XE Based Secure Routers into Dashboard for supported platforms and onboarding requirements.
Software Requirements
A deployed and active Auto VPN topology between Dashboard-managed IOS XE secure routers is required.
For Auto VPN deployment and operational guidance, see Auto VPN for Cisco 8000 Series Secure Routers using Cisco Meraki Dashboard.
Firmware Requirements
Post-quantum cryptography is enabled by default in IOS XE 26.1.1 and later. IOS XE 26.1.1 is the minimum release for onboarding a supported IOS XE secure router to Dashboard; therefore, no separate firmware activation or PQC enablement step is required.
Limitations
-
Third-party non-Meraki IPsec VPN & Client VPN are outside this feature scope.
Operations
No separate PQC configuration is required in Dashboard. PQC is enabled by default when supported Dashboard-managed IOS XE secure routers participate in Auto VPN.
Deployment and Validation Resources
- Use Post-Quantum Cryptography on Cisco 8000 Series Secure Routers for IKEv2 Sessions for IOS XE PQC validation and platform-level troubleshooting.