FlexVPN is Cisco’s unified framework for configuring all overlay VPN technologies, including GRE over IPsec, DMVPN, and SVTI. By standardizing around tunnel interfaces, FlexVPN simplifies the deployment and management of VPN infrastructures. At its core, FlexVPN is built on the powerful and flexible IKEv2 protocol, which provides enhanced security and functionality over its predecessor, IKEv1.

 

Why Choose FlexVPN?

FlexVPN offers a unified solution for deploying multiple types of VPN topologies using a consistent configuration approach. It simplifies the complexity of traditional VPN deployments by standardizing command structures, making it easier to manage and scale.

FlexVPN supports a wide range of VPN use cases, including:

  • Site-to-Site VPNs
  • Hub-and-Spoke topologies
  • Spoke-to-Spoke (Dynamic Mesh)
  • Remote Access VPNs, including support for AnyConnect clients, Windows native VPN clients (like Windows 7 and newer), and many others.

One of the key benefits of FlexVPN is that all of these models can be deployed with nearly identical configuration logic. This is a significant improvement over earlier Cisco VPN implementations, where different VPN types often required vastly different configurations and syntaxes. That complexity often led to interoperability issues when combining technologies like DMVPN, EZVPN, or traditional site-to-site IPsec VPNs.

FlexVPN was designed by Cisco’s Technical Assistance Center (TAC) in Brussels, aiming to consolidate and modernize VPN configuration practices. While supported on ISR G2 and ASR routers, FlexVPN is not compatible with older ISR G1 models.

 

Flexible Tunnel Deployments with FlexVPN

FlexVPN supports both SVTI (Static Virtual Tunnel Interfaces) and DVTI (Dynamic Virtual Tunnel Interfaces). This flexibility allows for dynamic peer initiation while maintaining a static configuration at the hub, a common requirement in scalable remote-access and hub-and-spoke designs.

Additionally, FlexVPN integrates seamlessly with NHRP (Next Hop Resolution Protocol), enabling spoke-to-spoke communication in dynamic mesh topologies similar to DMVPN. This is particularly useful in large-scale deployments where direct communication between spokes is needed without routing everything through a central hub.

Deployment models supported by FlexVPN include:

  • SVTI to DVTI (Static hub with dynamic remote sites)
  • Spoke-to-Spoke (Dynamic mesh VPN, like DMVPN)
  • Server-to-Client (like Cisco EZVPN)

Perhaps the most powerful feature of FlexVPN is its ability to unify all these models—site-to-site, remote access, and spoke-to-spoke—under a single configuration paradigm. By using a consistent command set, network engineers can deploy, troubleshoot, and scale VPNs more easily across diverse scenarios.

 

Why IKEv2?

IKEv2, defined by RFC 5996, introduces a number of improvements over IKEv1. These enhancements include better NAT traversal, integrated Dead Peer Detection (DPD), and support for advanced authentication mechanisms. Additionally, IKEv2 incorporates features that were either limited or unavailable in IKEv1, such as Config Payloads (Mode-Config replacement), which allow attributes to be dynamically sent to the client during the negotiation process.

Key IKEv2 Features:

  • Stronger security: IKEv2 supports Next Generation Encryption (NGE), offering robust cryptographic algorithms.
  • Authentication flexibility: It can authenticate peers using PSK, RSA signatures, EAP methods, or even hybrid modes.
  • Built-in NAT traversal: Uses UDP ports 4500 and 500 to navigate NAT devices seamlessly.
  • Reliable message handling: Each exchange includes an acknowledgment, improving message reliability.

 

IKEv1 vs. IKEv2 Message Exchange

IKEv1 operates in two main phases: Main Mode (used for establishing the initial secure channel) and Quick Mode (used for negotiating IPsec parameters). These phases involve multiple message exchanges and are separated clearly.

IKEv2 streamlines this process by collapsing the negotiations into a two-message exchange for SA and key setup, followed by the AUTH phase, which may also include a Config Payload (CP). This more efficient structure simplifies state tracking and reduces complexity.

 

The Role of Config Payload (CP) in IKEv2

In IKEv2, the Config Payload allows network attributes (e.g., IP addresses, DNS servers) to be exchanged during the IKE_AUTH phase. This is especially useful for remote access VPNs, where the client may need to receive these attributes to participate in the VPN.

The CP exchange typically occurs within the third or fourth packet of the IKE_AUTH exchange. It’s encrypted and provides an elegant method of conveying configuration parameters without requiring a dynamic routing protocol.

 

Configuration Differences Between IKEv1 and IKEv2

While both protocols aim to establish secure tunnels, their configuration syntax and architecture differ significantly:

IKEv1 Configuration:

  • ISAKMP Policy: Defined with sequence numbers.
  • ISAKMP Key: Set globally.
  • ISAKMP Profile: Tied to tunnel groups (especially relevant on ASA appliances).

 

IKEv2 Configuration:

  • IKEv2 Proposal: Similar to ISAKMP policy but without sequence numbers.
  • IKEv2 Policy: Associates with an IKEv2 Proposal and can include parameters like VRF. This allows multiple peers to use distinct proposals—something IKEv1 couldn’t do.
  • IKEv2 Keyring: Replaces the static ISAKMP key from IKEv1.
  • IKEv2 Profile: Replaces the ISAKMP profile, acting as the main policy attachment point.
  • IKEv2 Authorization: Ties into the Config Payload, defining which attributes can be sent to clients during negotiation.

A major advantage of IKEv2 is its flexibility. It supports multiple peers with different proposals under the same configuration and allows the use of modern encryption standards like AES while still interoperating with peers using older methods like 3DES.

Importantly, even though IKEv2 brings significant architectural improvements, the IPsec configuration itself remains consistent between IKEv1 and IKEv2 deployments.

 

FlexVPN IKEv2 Phases: IKE_SA_INIT and IKE_AUTH

Understanding FlexVPN begins with examining its foundational phases – IKE_SA_INIT and IKE_AUTH – which form the basis of the IKEv2 negotiation process. These stages establish a secure channel, authenticate peers, and ultimately lay the groundwork for dynamic and scalable VPN connectivity.

 

IKE_SA_INIT – Establishing the Secure Channel

The IKE_SA_INIT phase is responsible for negotiating the cryptographic algorithms that will protect the IKEv2 session. This phase starts by exchanging the IKEv2 Proposal and the IKEv2 Policy.

  • The IKEv2 Proposal includes the encryption algorithms, integrity methods, pseudo-random functions (PRFs), Diffie-Hellman groups, and session lifetime parameters. Cisco allows multiple proposals with a wide range of supported algorithms, giving flexibility to match with different peer configurations.
  • The IKEv2 Policy dictates where and how these proposals are applied. It includes the local interface (or front-door VRF) and supports associating multiple proposals. While the proposals define the cryptographic capabilities, the policy is what actually ties them to the physical or logical interface used for VPN connectivity.

The router will automatically evaluate available proposals and use the most secure match when multiple are defined.

 

IKE_AUTH – Authentication and Tunnel Profile Configuration

Once the secure channel is established, the IKE_AUTH phase takes over. Here, the IKEv2 Profile plays a central role—it defines peer identities, authentication methods, and ties everything together through tunnel interfaces or crypto maps.

Key elements in this phase include:

  • Peer Identity & Authentication: The profile defines what identity to offer (e.g., domain, IP subnet) and what method to use – PSK, RSA signatures, or EAP. It can be as broad or specific as needed.
  • IKEv2 Keyring (Optional): This allows specifying peer identities and preshared keys in scenarios where each peer may use different credentials.
  • Trustpoints & AAA Auth-Lists: If digital certificates or EAP are used, these components must be referenced.
  • Virtual-Templates & FVRFs: These allow scalable, dynamic assignment of interfaces and route separation for larger deployments.

 

Deployment Options in FlexVPN

FlexVPN supports several deployment models, all using the same configuration logic and IKEv2 Profile. These models are tied together using IPSec profiles and transform sets.

Option 1: Virtual Tunnel Interface (VTI)

This is the preferred method for FlexVPN. It allows dynamic routing protocols to be run over secure tunnels, eliminating the need for static crypto ACLs.

  • 1.1 SVTI (Static VTI): Used in static site-to-site deployments where the peer IPs are predefined. The interface tunnel command creates a persistent tunnel interface.
  • 1.2 DVTI (Dynamic VTI): Ideal for dynamic remote access or client-initiated tunnels. The interface virtual-template command creates a tunnel template that dynamically spawns a new tunnel per peer. These interfaces (e.g., Virtual-Access) are created and destroyed as peers connect and disconnect. This works across IPv4, IPv6, and even MPLS.

 

Option 2: Crypto Map (Legacy)

Crypto maps are the older method of configuring VPNs and should generally be avoided unless compatibility with third-party devices (like Cisco ASA) is required. It involves manually tying together crypto ACLs, peer IPs, IPSec transform sets, and the IKEv2 profile. While still supported, it’s more static and cumbersome compared to VTI deployments.

 

FlexVPN Smart Defaults

One of the advantages of using FlexVPN is its reliance on sensible smart defaults, which simplify initial configuration and reduce the potential for misconfiguration, especially useful when setting up lab environments or deploying standardized VPN templates. To simplify deployments, Cisco provides a robust set of smart defaults that minimize manual configuration:

  • IKEv2 Proposal: Comes with strong encryption, integrity, PRF, and DH group defaults.
  • IKEv2 Policy: Automatically associates proposals to front-door interfaces or VRFs.
  • IPSec Transform Set: Predefined sets for encryption and integrity (e.g., esp-aes esp-sha-hmac).
  • IPSec Profile: Ties together the transform set and IKEv2 profile, with defaults available for rapid deployment.

These defaults allow engineers to bring up FlexVPN quickly while still maintaining security best practices. Of course, they can be customized when higher compliance or interoperability is needed.

 

Default IKEv2 Proposal

When you run the command show crypto ikev2 proposal, Cisco IOS will display the default IKEv2 proposal, which includes a robust set of cryptographic parameters:

  • Encryption algorithms: AES-CBC-256, AES-CBC-192, and AES-CBC-128
  • Integrity checks: SHA512, SHA384, SHA256, SHA1, SHA96, and MD596
  • Pseudorandom functions (PRF): SHA512, SHA384, SHA256, SHA1, and MD5
  • Diffie-Hellman groups: Group 5 (1536-bit MODP), Group 2 (1024-bit MODP)

These settings strike a balance between compatibility and robust cryptographic standards, supporting both legacy and next-generation encryption (NGE). The platform automatically negotiates the best standard parameters between peers based on this list unless explicitly overridden.

 

Default IPsec Transform-Set

Similarly, the IPsec transform set uses secure defaults, as shown by the ‘show crypto ipsec transform-set’ command. By default, you’ll see transform sets such as:

  • esp-aes esp-sha-hmac — for encryption and integrity protection.
  • Transform sets may support both Transport and Tunnel modes, depending on the use case.

The transform-set defines how the IPsec tunnel encrypts and authenticates data. These default configurations allow seamless interoperation between peers unless your environment requires specialized algorithms or stricter compliance policies (e.g., FIPS-only crypto).

By leveraging these built-in defaults, FlexVPN simplifies the initial setup while still offering the flexibility to customize proposals and transform-sets for more complex enterprise scenarios.

 

Verifying FlexVPN Defaults with CLI

When deploying FlexVPN, it’s helpful to understand the default values that Cisco IOS XE provides out of the box. These defaults are not only secure and well-structured but also allow engineers to bring up a functional VPN quickly. Let’s walk through the key commands to view these defaults and what each output means.

 

Viewing the Default IKEv2 Proposal

To inspect the currently configured IKEv2 proposals, use the following command:

show crypto ikev2 proposal

This command reveals the default cryptographic parameters the router will offer during the IKE_SA_INIT phase. A sample output might include:

  • Encryption: AES-CBC-256, AES-CBC-192, AES-CBC-128
  • Integrity: SHA512, SHA384, SHA256, SHA1, MD5, SHA96, MD596
  • PRF (Pseudo-Random Function): SHA512, SHA384, SHA256, SHA1, MD5
  • DH Group: Group 5 (1536-bit MODP), Group 2 (1024-bit MODP)

These algorithms are used to negotiate a secure IKEv2 tunnel with the peer, and the router will automatically select the strongest mutually supported configuration during the handshake.

 

Inspecting the IKEv2 Policy

The IKEv2 policy determines when and where the associated proposals will be applied. To view it:

show crypto ikev2 policy

In the default configuration, you’ll typically see:

  • Match FVRF: Any
  • Match Address Local: Any
  • Proposal: Default

This configuration tells the router to use the default proposal regardless of interface or VRF, unless otherwise specified. It provides flexible, global coverage for VPN connections unless you define a more specific policy.

 

Checking the Default IPsec Transform Set

Transform sets define how IPsec will encrypt and authenticate traffic once the tunnel is established. To view what’s configured by default:

show crypto ipsec transform-set

 

The default transform set usually appears as:

esp-aes esp-sha-hmac

This indicates that AES is used for encryption and SHA for integrity. The mode will default to transport, though tunnel mode is typically applied in FlexVPN deployments using VTIs.

 

Viewing the IPsec Profile Defaults

Lastly, the IPsec profile ties together the transform set, IKEv2 profile, and session handling behaviors. To see the default settings:

show crypto ipsec profile

You might see output similar to:

  • Security Association Lifetime: 3600 seconds / ~4608000 kilobytes
  • Responder-Only: No
  • Perfect Forward Secrecy (PFS): Disabled
  • Mixed Mode: Disabled
  • Transform Sets: esp-aes esp-sha-hmac

These default profiles are sufficient for most basic deployments and help ensure interoperability with other Cisco FlexVPN-enabled devices.

Cisco’s smart defaults provide a solid baseline configuration, allowing engineers to get up and running with minimal effort while maintaining strong security practices. When greater customization is required, these commands offer a starting point to refine and enhance VPN policies.

 

Advanced IKEv2 Options (a.k.a. Nerd Knobs)

Cisco’s FlexVPN implementation of IKEv2 offers a powerful suite of optional configuration commands—sometimes referred to as “nerd knobs”—that allow engineers to fine-tune behavior at a granular level. These options are accessible via the crypto ikev2 configuration mode and include everything from dead peer detection to certificate cache sizing and advanced NAT handling.

Here are some of the most notable options:

  • authorization policy name: Pushes IKEv2 authorization policies to remote sites, typically in remote-access deployments.
  • certificate-cache num: Limits the number of certificates stored (range: 1–2000), useful when fetching certificates from remote URLs.
  • client flexvpn name: Defines FlexVPN client behavior for remote access use cases.
  • cluster: Provides load-balancing settings for high-availability clusters.
  • cookie-challenge num: Limits in-progress IKE SA negotiations to protect against DoS attacks.
  • cts sgt: Enables TrustSec tagging for identity-aware networking.
  • diagnose error num: Helps debug IKE error paths.
  • disconnect-revoked-peers: Forces session termination if the peer’s certificate is revoked.
  • dpd num num: Configures Dead Peer Detection intervals and retry limits. Also supports on-demand and periodic modes.
  • fragmentation mtu num: Enables IKE fragmentation to work around packet size limitations.
  • http-url cert: Enables certificate fetch from a URL, reducing config size and improving flexibility.
  • keyring word: Launches keyring sub-configuration mode.
  • limit {max-in-negotiation-sa | max-sa} num: Controls maximum number of allowed SAs.
  • name-mangler name: For customizing how peer names are resolved or altered.
  • nat keepalive num: Ensures NAT entries stay alive, useful when peers are behind NAT.
  • policy name / profile name / proposal name: Begin configuration modes for each respective IKEv2 component.
  • reconnect: Enables automatic reconnection in a FlexVPN cluster setup.
  • redirect: Enables SA-based IKEv2 redirection for load balancing.
  • window num: Limits the number of overlapping requests per peer.

To reset a smart default (for example, if you want to disable the default proposal), you can use:

no crypto ikev2 proposal default

 

To re-enable it:

default crypto ikev2 proposal

 

The FlexVPN Value Proposition

FlexVPN is more than just a new way to configure VPNs—it represents a complete evolution in Cisco’s VPN architecture, aligning with the IKEv2 standard and AAA framework while unifying legacy VPN models like DMVPN, EzVPN, and SVTI/DVTI into one consistent CLI model.

Key Benefits of FlexVPN:

  • Standards-based: Fully interoperable with non-Cisco IKEv2 implementations.
  • Flexible topology support: Works with point-to-point, hub-and-spoke, full mesh, and remote-access scenarios.
  • Unified CLI structure: Reduces training time and simplifies operations by using the same commands for all VPN types.
  • Multiple VPN types under one umbrella: Supports site-to-site, client-server, spoke-to-spoke, and dynamic overlays.
  • Dynamic overlay routing: Easily integrates with routing protocols thanks to tunnel interfaces.
  • Per-user or per-peer policy support: Useful in large-scale or multi-tenant environments.
  • AAA integration: Leverages Cisco’s AAA infrastructure for flexible user-based access control.
  • Encapsulation flexibility: Supports both GRE and native IPsec encapsulation.
  • IPv4/IPv6 compatibility: Fully supports overlay and underlay in dual-stack environments with automatic IP transport selection.

FlexVPN leverages the IKEv2 exchange to dynamically push policy and routing information between peers. This capability is particularly valuable in client/server VPN setups, where the server can define the client’s configuration on-the-fly, including IP address assignment, split tunneling, DNS servers, and route injection.

FlexVPN is a modern, scalable, and secure VPN framework that consolidates the best elements of Cisco’s legacy VPN technologies while introducing IKEv2-powered efficiency and flexibility. Whether you’re deploying a full mesh for branch connectivity, a remote access solution for a mobile workforce, or a site-to-site tunnel across data centers, FlexVPN provides a streamlined and powerful platform to do it all.