Diving Deep Deep Deep into FlexVPN – Part 1

 

Understanding FlexVPN Tunnel Interfaces: Static, Dynamic, and Everything In Between

Cisco FlexVPN offers a flexible and scalable framework for VPN deployments by using per-peer point-to-point (P2P) tunnel interfaces. These interfaces can support a variety of encapsulation modes, including Generic Routing Encapsulation (GRE) and native IPsec, making FlexVPN an ideal choice for complex and scalable secure communication.

 

Static vs Dynamic Tunnel Interfaces

FlexVPN distinguishes between tunnel interface configurations used on initiators versus responders. On FlexVPN initiators, tunnel interfaces such as static GRE and static IPsec VTIs (sVTIs) are explicitly defined and configured. In contrast, FlexVPN responders dynamically instantiate tunnel interfaces using virtual templates, cloning them into virtual-access interfaces at runtime in response to incoming IKEv2/IPsec sessions.

These dynamically created interfaces enable configuration reuse and scalability, as they inherit attributes from the virtual-template interfaces, supporting both IPv4 and IPv6 encapsulated overlay traffic.

 

Tunnel Encapsulation and Security Associations

FlexVPN supports two tunnel encapsulation modes:

• GRE Mode (tunnel mode gre)
  GRE encapsulation uses the tunnel source and destination addresses as the local and remote IPsec peer addresses. For IPsec SA traffic selectors, these same tunnel endpoints are used with GRE (protocol 47) and a host mask. This setup forms a GRE host-to-host SA, which is strict in defining exact endpoints and protocols.
• IPsec Mode (tunnel mode ipsec)
  Native IPsec mode relaxes selector criteria significantly. The IPsec SA uses a more general configuration: all addresses, masks, protocols, and ports are set to any, creating what’s known as an any-to-any SA. This setup is more flexible and better suited for dynamic environments.

 

Tunnel Protection and VRF Integration

All IPsec-based tunnel interfaces in FlexVPN use tunnel protection to bind IPsec profiles to the interface. For enhanced segmentation, FlexVPN supports VRF-aware tunnels by allowing the use of vrf forwarding for the overlay VRF (IVRF) and tunnel vrf for the transport VRF (FVRF). Here’s a sample static tunnel configuration using IPv4 and IPv6 with VRF:

interface tunnel1
vrf forwarding ivrf_1
ip address 192.168.1.1 255.255.255.0
ipv6 address 2001::1:1/120
tunnel source g1
tunnel destination 192.168.2.1
tunnel vrf fvrf_1
tunnel protection ipsec profile default
end

 

Dynamic Interfaces with Virtual Templates

On the responder, FlexVPN dynamically creates virtual-access interfaces for each session, based on virtual templates. The interface gets its IP configuration using ip unnumbered and/or ipv6 unnumbered, which borrows the IP configuration from a physical or logical interface (like a GigabitEthernet interface).

Misconfigurations, such as directly assigning ip address on the virtual-template interface, can cause issues like subnet overlaps. For that reason, use ip unnumbered with care.

Here’s a correct example of a virtual-template-based configuration:

crypto ikev2 profile ikev2_profile
virtual-template 1

interface virtual-template1 type tunnel
ip unnumbered g1
ipv6 unnumbered g1
tunnel protection ipsec profile default

 

Auto-Detection Mode for Encapsulation

FlexVPN supports auto-detection of both the encapsulation type (GRE or native IPsec) and the transport IP protocol (IPv4/IPv6) on the responder. This is made possible via the mode auto command in the IKEv2 profile, enabling the virtual-template to clone the appropriate configuration based on the incoming negotiation:

crypto ikev2 profile ikev2_profile
virtual-template 1 mode auto

This mode ensures flexibility in environments where initiators may use different transport types or encapsulation mechanisms, without requiring separate templates.

 

Advantages of Per-Peer Tunnel Interfaces

By leveraging P2P tunnel interfaces, FlexVPN enables:

• Feature granularity per session: Unlike multipoint configurations, all features are available per tunnel.
• NAPT traversal: Multiple peers behind the same NAT device (even sharing the same public/private IPs) can establish sessions concurrently.
• Session-specific configuration inheritance: Reduces misconfigurations and makes managing dynamic peers more scalable.

 

Verification and Troubleshooting

To verify FlexVPN sessions and tunnel instantiation:

• IKEv2 Debugs:
  • debug crypto ikev2
  • debug template cloning
• Show Commands:
  • show crypto session
  • show derived-config interface virtual-access 1

 

FlexVPN’s ability to scale, interoperate with IPv4 and IPv6, auto-detect tunnel modes, and handle NAT makes it an extremely versatile solution in modern VPN deployments. Whether you’re configuring static initiators or dynamic responders, understanding how these interfaces operate is key to designing resilient and secure FlexVPN architectures.

 

Dive into FlexVPN Tunnel Interface Modes and Deployment Strategies

FlexVPN offers a robust and highly adaptable framework for implementing scalable, secure VPN architectures. Whether you’re deploying tunnels on a branch router or building a hub-and-spoke topology for remote users, understanding the differences between static, dynamic, and hybrid tunnel modes is essential. Let’s explore how Cisco IOS handles tunnel instantiation across these use cases.

 

Static Tunnel Interfaces: sVTI Configuration

FlexVPN supports static tunnel interfaces, commonly referred to as sVTIs (static Virtual Tunnel Interfaces), on both initiators and responders. These interfaces are manually configured and remain persistent, regardless of session state. They support both IPsec and GRE encapsulations and are ideal for predictable, fixed-endpoint deployments. Here’s a sample configuration for a static IPsec tunnel using IPv4:

interface tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source g1
tunnel mode ipsec ipv4
tunnel destination 209.165.200.225
tunnel protection ipsec profile default

When paired with a crypto ikev2 client flexvpn profile, the destination IP address can even be set to dynamic, allowing the peer’s address to be resolved at runtime. This is particularly useful for FlexVPN clients with dynamic IP assignments.

 

Dynamic Tunnel Interfaces: dVTI Templates

Dynamic tunnel interfaces, or dVTIs, are a responder-only feature, leveraging virtual-template configurations. These templates serve as blueprints for on-the-fly tunnel creation in response to IKEv2 negotiations. When a session request arrives, the router clones the virtual-template into a unique virtual-access interface, establishing a secure P2P link for that peer. The cloned interface is ephemeral and is deleted once the tunnel is torn down.

All virtual-template interfaces in FlexVPN are declared as type tunnel, ensuring that the resulting virtual-access interfaces behave identically to static interfaces—they can carry IPv4/IPv6, use VRFs, and apply tunnel protection. Here’s a basic dynamic configuration example:

interface loopback1
ip address 10.0.0.1 255.255.255.255

interface virtual-template1 type tunnel
ip unnumbered loopback1
tunnel mode ipsec ipv4
tunnel protection ipsec profile default

This model supports hub-and-spoke topologies where a single virtual-template at the hub can dynamically service multiple spokes. Each spoke uses a static configuration, but the hub remains unbound to any specific peer IP, simplifying scalability.

To validate active virtual-access configurations, use:

show derived-config interface virtual-access num

Additionally, tunnel mode can be set to auto, enabling the responder to match GRE, IPsec, and transport IP version (IPv4/IPv6) based on the initiator’s proposal.

 

Mixed Tunnel Mode: IPv4 over IPv6 and Vice Versa

FlexVPN also supports mixed-mode tunnels, where overlay and transport protocols differ in IP version. This is particularly helpful in dual-stack environments or when transitioning between IPv4 and IPv6 networks.

IOS allows you to configure an IPv4 overlay over an IPv6 transport or vice versa using the tunnel mode ipsec ipv6 v4-overlay and tunnel mode ipsec ipv4 v6-overlay commands. For example:

IPv4 overlay over IPv6 transport:

interface tunnel0
ip address 192.168.1.1 255.255.255.0
tunnel source g1
tunnel mode ipsec ipv6 v4-overlay
tunnel destination 2001:DB8::2
tunnel protection ipsec profile default

 

IPv6 overlay over IPv4 transport:

interface tunnel0
ip address 2001:DB8::1/112
tunnel source g1
tunnel mode ipsec ipv4 v6-overlay
tunnel destination 192.168.1.2
tunnel protection ipsec profile default

IOS routers acting as remote access VPN headends can support mixed-mode tunnels, provided set mixed-mode is configured in the IPsec profile and the device is running IKEv2.

 

Auto Tunnel Mode: Dynamic Per-Peer Customization

In environments with diverse tunnel requirements, Auto Tunnel Mode offers maximum flexibility. When the IKEv2 responder is configured with mode auto in its profile, the virtual-template will dynamically adapt to match the encapsulation and transport type proposed by the initiator. This means a single template can support IPv4/IPsec, IPv6/IPsec, GRE over IPsec, and more—all without explicit tunnel definitions for each combination.

This approach allows the headend to service multiple remote clients seamlessly, reducing configuration overhead while supporting both IPv4 and IPv6 topologies.

 

VRF Awareness: Routing Segmentation in FlexVPN

Virtual Routing and Forwarding (VRF) is a critical component for routing isolation in VPN environments. Cisco routers support VRF-aware configurations by maintaining separate RIBs, FIBs, and ARP tables per VRF. VRFs can be configured using ip vrf (IPv4-only) or the more modern vrf definition (IPv4/IPv6).

To enable VRF on a tunnel interface:

• Use vrf forwarding name to assign an interface to a VRF.
• Use ip unnumbered or ipv6 unnumbered to borrow an IP from another interface in the same VRF.
• Configure the transport VRF using tunnel vrf name when the underlay interface belongs to a different routing instance.

In VRF-aware environments, FlexVPN ensures both encrypted (payload) and unencrypted (delivery) traffic is isolated accordingly. GRE and IPsec are both VRF-aware, but IPsec configurations vary:

• Legacy crypto maps use IKE profile VRF bindings and route leaking.
• VTIs depend solely on the VRF assigned to the tunnel interface.

 

GRE over IPsec in a VRF-Aware Context

GRE over IPsec adds another layer of abstraction and is common when routing protocols must traverse the tunnel. In FlexVPN, this is achieved by assigning tunnel protection to a GRE-based tunnel using:

tunnel mode gre {ip | ipv6}
tunnel protection ipsec profile name

Although both GRE and IPsec headers appear in the resulting packet, the tunnel interface logic is split: GRE is responsible for encapsulating routed traffic, while IPsec secures the GRE payload. In VRF-aware setups, GRE handles the hop between IVRF and FVRF, and IPsec protects the GRE packet within the FVRF context.

By understanding and applying these tunnel interface models—static, dynamic, mixed-mode, VRF-aware, and GRE over IPsec—you can architect FlexVPN environments that are both scalable and resilient. Whether building a remote-access hub, supporting dynamic clients behind NAT, or segmenting traffic across virtual routing domains, FlexVPN adapts to the complexity of modern enterprise networks.

 

Cisco FlexVPN AAA Integration: Authentication, Authorization, and Accounting Explained

A core part of deploying FlexVPN at scale is integrating it with an AAA (Authentication, Authorization, and Accounting) infrastructure. Cisco IOS supports both local and external AAA databases, giving administrators the flexibility to choose between RADIUS servers, local method lists, and hybrid combinations depending on their security policies and scalability needs.

 

AAA Infrastructure in FlexVPN

FlexVPN relies on external AAA servers, typically RADIUS or TACACS+, to handle user authentication, enforce authorization policies, and track accounting. These servers store user credentials, group memberships, and logging data in a manner that remains transparent to the AAA clients (such as routers or VPN gateways). This externalized model enables centralized policy enforcement and simplifies administrative overhead in large deployments.

 

Supported AAA Operations

FlexVPN supports several AAA operations, each with varying database compatibility:

• EAP Authentication: Uses an external AAA server for standards-based EAP or a combination of external and local AAA for AnyConnect EAP methods.
• Pre-shared Key Authentication: Managed via external AAA servers.
• User & Group Authorization: Can use either external or local AAA sources.
• Implicit Authorization & Accounting: Require external AAA servers.

This modularity lets administrators fine-tune their VPN user access policies by offloading authentication and tracking duties to established identity servers.

 

Step-by-Step Configuration: AAA for FlexVPN

To configure AAA for FlexVPN, follow these structured steps:

1. Enable AAA Services

aaa new-model

This command activates AAA functionality on the router.

 

2. Define Method Lists

Create the method lists for login authentication, authorization, and accounting. These lists link the IKEv2 profile with the appropriate AAA database.

aaa authentication login authen_list_radius group radius_group
aaa authorization network author_list_local local
aaa authorization network author_list_radius group radius_group
aaa accounting network acc_list_radius group radius_group

 

3. Configure the RADIUS Server Group and Server

First, define a server group and then specify the actual server details.

aaa group server radius radius_group
server name radius_server

radius server radius_server
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_key

 

4. Set Up Local AAA Attributes (Optional)

In some cases, especially for lab or fallback purposes, a local AAA database can be used with FlexVPN. Define the authorization policy and address pool:

crypto ikev2 authorization policy author_policy
route set interface
route accept any
pool ip_address_pool
aaa attribute list attr_list

 

Define the attribute list contents:

aaa attribute list attr-list1
attribute type interface-config “ip mtu 1100”
attribute type interface-config “tunnel key 10”

 

5. Bind AAA to the IKEv2 Profile

Finally, tie everything together in the IKEv2 profile:

crypto ikev2 profile ikev2_profile
aaa authentication eap authen_list_radius
aaa authorization user cert list author_list_radius user1
aaa authorization group cert list author_list_local author_policy
aaa accounting cert acc_list_radius

This profile governs the authentication mechanism used during the IKEv2 exchange and binds specific AAA policies to users and groups based on their credentials or certificate information.

With Cisco FlexVPN, the AAA framework becomes a pivotal part of controlling who can connect, what routes they can access, and how sessions are logged. By leveraging both local and external AAA databases, administrators gain the flexibility to implement highly granular access controls without sacrificing scalability or visibility.

FlexVPN’s deep integration with AAA infrastructure also opens the door to advanced policy enforcement, such as per-user route injection, MTU adjustments, and dynamic keying—all configured centrally and applied automatically.

 

Demystifying the IKEv2 Name Mangler in Cisco FlexVPN

One of the key challenges in dynamic VPN environments is aligning identity-based authentication with AAA policy lookups. Cisco FlexVPN addresses this with a powerful but often underutilized feature: the IKEv2 Name Mangler.

The name mangler serves as a translator, extracting a meaningful username string from a peer’s IKEv2 identity, which is then used by the AAA infrastructure for authorization decisions. Whether the identity is in the form of an FQDN, email, distinguished name (DN), or EAP identity, the name mangler provides granular control over how that identity maps to AAA policies.

 

What is the IKEv2 Name Mangler?

The name mangler processes the authenticated IKE identity after peer authentication is successful. It takes the identity string (which could be a DN, FQDN, email, or EAP identity) and extracts a name based on a configured rule. That name is then used as a username for AAA policy lookup.

This extraction mechanism is referenced in the IKEv2 profile using commands like:

aaa authorization ...
keyring aaa ...

 

To create a name mangler, use the command:

crypto ikev2 name-mangler name

You then specify how to parse identities based on their type using subcommands.

 

Supported Identity Types and Extraction Methods

1. FQDN (Fully Qualified Domain Name)

The name mangler can extract:.

• Hostname portion (e.g., from user.domain, it extracts user)
• Domain portion (extracts domain)
• Entire FQDN (passes user.domain as-is)

 

Example configuration:

fqdn hostname
fqdn domain
fqdn all

 

2. Email Identity

The email identity (formatted as user@domain) supports the extraction of:

• Username (user)
• Domain (domain)
• Entire email string

Example configuration:

email username
email domain
email all

 

3. Distinguished Name (DN)

For DNs in X.500 format (like in certificates), the name mangler can extract:

• Common Name (CN)
• Domain
• Organizational Unit (OU)
• Organization (O)
• Locality (L)
• State (S)
• Country (C)
• Entire DN string

Example configuration:

dn common-name
dn domain
dn organization-unit
dn organization
dn locality
dn state
dn country
dn all

 

4. EAP Identity

For EAP identities, you can extract strings based on:

• Prefix or suffix delimiters like ., @, or \
• Distinguished Name fields if the identity is in DN format
• Entire EAP string

Examples:

eap prefix delimiter .
eap prefix delimiter @
eap prefix delimiter \
eap all
eap dn common-name
eap dn organization

 

Sample Profile Using the Name Mangler

Here’s how to apply a name mangler in an IKEv2 profile:

crypto ikev2 profile ikev2_profile
keyring aaa aaa_method_list
name-mangler name_mangler

aaa authorization group psk list aaa_list name-mangler name_mangler
aaa authorization user psk list aaa_list name-mangler name_mangler

This profile will extract the name from the IKE identity and use it for user or group authorization, depending on the peer’s authentication method.

 

Why Use Name Mangler?

• Policy Flexibility: Map identities to specific policies without requiring full string matches.
• Improved Scalability: Allows a single policy to apply across domains or organizations.
• Better Identity Management: Supports parsing identity formats across email, domain names, certificates, and EAP-based methods.

By carefully configuring the name mangler, FlexVPN administrators gain fine-grained control over identity-to-policy mapping in AAA, a critical step for enforcing differentiated access policies in enterprise networks.

 

Cisco IKEv2 Configuration Overview and Proposal Design

When configuring IKEv2 in Cisco IOS for VPNs, including FlexVPN, understanding the layered components of the configuration is essential. While not every element is mandatory due to smart defaults, several components must be explicitly defined depending on your deployment’s security, compatibility, and policy needs.

 

Key Components of IKEv2 Configuration

The IKEv2 Profile is always required. It defines the authentication methods, credentials, and how the router interacts with AAA, keyrings, and authorization policies. In contrast, IKEv2 Proposals, Policies, and Keyrings are optional, though often necessary, when defaults don’t meet operational requirements. Lastly, IKEv2 Global Configuration is used to set system-wide parameters and is rarely mandatory.

Except for the global settings, all IKEv2 configurations are bound to either a profile or policy, and those must be explicitly referenced during setup. The IKEv2 profile sets the scope for identity handling, EAP configuration, and AAA linkage, while the policy governs cryptographic proposals.

 

IKEv2 Proposal Explained

The IKEv2 proposal defines the cryptographic transforms negotiated during the IKE_SA_INIT exchange. These transforms secure the IKE SA itself. The proposal includes:

• Encryption Algorithm
• Integrity Algorithm
• Pseudorandom Function (PRF)
• Diffie-Hellman Group

Importantly, the IKEv2 proposal does not include the authentication method or SA lifetime—those are handled elsewhere in the configuration.

IKEv2 proposals mimic the proposal payload structure in IKEv2 protocol exchanges. A single IKE SA can include multiple proposals, and each proposal can include multiple transforms of each type.

 

Rules for IKEv2 Proposals

• At least one transform per type must be configured unless using a combined-mode cipher, which merges encryption and integrity.
• If multiple algorithms of a type are configured, preference is ordered left-to-right.
• When initiator and responder have conflicting preferences, the initiator’s proposal takes precedence.
• Proposals must be referenced from within an IKEv2 Policy to be considered.
• For negotiation to succeed, the responder must support at least one matching proposal.

 

Configuring an IKEv2 Proposal

Begin by entering global configuration mode:

crypto ikev2 proposal ikev2_proposal

 

Then define the desired transforms:

encryption aes-cbc-256
integrity sha512
prf sha512
group 16

Note: If a proposal lacks any required component, the config will show Proposal Incomplete. Use the command below to verify:

show run | beg ikev2 proposal
show crypto ikev2 proposal

When using a combined-mode cipher like AES-GCM, the integrity setting must be omitted, as GCM handles both encryption and authentication in a single operation.

 

Cryptographic Algorithms

Encryption Algorithms:

 

Integrity Algorithms:

 

Diffie-Hellman (DH) Groups:

Cisco recommends using Group 14 or higher. For stronger protection, use elliptic curve groups such as:

 

Pseudorandom Function (PRF):

Used for key material generation using HMAC, the PRF ensures cryptographic strength and security of the key derivation process.

 

Verifying Default IKEv2 Proposal

IOS provides a default proposal when none is explicitly configured. To view it:

show crypto ikev2 proposal default

It typically includes:

• Encryption: AES-CBC (128, 192, 256)
• Integrity: SHA512, SHA384, SHA256, SHA1, MD5
• PRF: SHA512, SHA384, SHA256, SHA1, MD5
• DH Groups: 1, 2, 5, 14

This default is tied to the default policy and only used if no custom IKEv2 proposal/policy is referenced.

Properly configuring IKEv2 proposals is foundational to VPN security in Cisco IOS. By choosing modern ciphers, strong integrity algorithms, and quantum-resistant DH groups, you ensure your tunnels resist current and emerging threats.

 

Mastering IKEv2 Policy Configuration and Selection in Cisco IOS

In Cisco’s implementation of IKEv2, policies play a central role in controlling how Security Associations (SAs) are negotiated. The IKEv2 policy defines the set of IKEv2 proposals used during negotiation, and its application is determined by the local context—specifically the local address and forwarding VRF (FVRF). This mechanism applies to both initiator and responder roles, allowing for granular policy assignment based on tunnel interface configurations.

 

What is an IKEv2 Policy?

An IKEv2 policy is used during the IKE_SA_INIT exchange and defines one or more IKEv2 proposals to be used for negotiation. It may also contain one or more match statements to limit its applicability based on VRF and local address. When multiple policies match a session, the most specific match is chosen.

IKEv2 policies support:

• Multiple proposals
• Context-specific match statements
• Policy prioritization based on specificity

 

Rules for Using IKEv2 Policies

Some key rules apply when creating and using IKEv2 policies:

• At least one proposal is required per policy.
• Match statements are optional but recommended to control the scope of the policy.
• If no user-defined policy matches, the default IKEv2 policy is used, which matches any FVRF and any local IP address.
• Multiple match statements of the same or different types (FVRF or address) are allowed:
  • If only one type exists, any match triggers the policy.
  • If both types are used, at least one of each type must match.
  • If no match statements are present, the policy applies to all addresses in the global VRF.

 

Configuring an IKEv2 Policy

Here’s how to define a custom policy:

crypto ikev2 policy ikev2_policy
match address local 100.1.125.1
proposal ikev2_proposal

This example binds the policy to a specific local IP and references a previously defined proposal.

 

You can view existing policies with:

show run | beg ikev2 policy
show crypto ikev2 policy

 

Default policy output:

R1#show crypto ikev2 policy default
IKEv2 policy : default
Match fvrf : any
Match local : any
Proposal : default

 

IKEv2 Policy Selection on the Initiator

Policy selection for an outgoing IKEv2 session occurs before the IKE_SA_INIT message is sent. The following elements affect policy matching:

• Tunnel Source Address: Used to determine the local address.
• Tunnel FVRF: Derived from tunnel vrf and must match the WAN-facing VRF.
• Tunnel Destination Address: Used to calculate the remote endpoint.

Because the policy must be selected before negotiation starts, the initiator determines the policy from its own tunnel configuration. Use the following debug commands to troubleshoot:

debug crypto ikev2
debug crypto kmi

 

IKEv2 Policy Selection on the Responder

In contrast, the responder selects the IKEv2 policy after receiving the IKE_SA_INIT message. The selection logic relies on:

• FVRF of the incoming interface
• Destination address in the IKEv2 packet (interpreted as the responder’s local IP)

The policy selected must match this FVRF and destination address, and the responder will use one of the proposals in that policy to respond to the negotiation.

 

Practical Implications

Understanding the separation of policy selection logic between initiator and responder is vital for multi-context VPNs:

• You can apply different IKEv2 policies to different peers by manipulating local tunnel interface addresses and VRFs.
• This enables granular policy control without relying on remote peer IPs.
• You can isolate configurations per service, geography, or tenant in multi-VRF environments.

By mastering IKEv2 policy and match logic, you gain powerful control over VPN negotiation behavior in Cisco IOS. Whether you’re building scalable FlexVPN hubs or per-peer branch tunnels, tailoring the right policy strategy ensures consistent, secure, and compatible negotiations across all endpoints.

 

Cisco IKEv2 Keyrings and Key Lookup Logic Explained

Authentication in IKEv2 can be achieved using public key signatures, EAP, or pre-shared secrets. When using pre-shared keys (PSK), Cisco IOS provides a mechanism called the IKEv2 keyring—a local repository used to associate keys with specific peer identities. While keys can also be stored remotely via RADIUS, the keyring provides a flexible, locally defined method for PSK authentication.

 

How IKEv2 Keyrings Work

IKEv2 keyrings are made up of one or more peer blocks, where each block defines how to match peers based on their IP address, hostname, or identity. The block then specifies the pre-shared key(s) to be used during authentication. These keys can be:

• Symmetric (single key used in both directions)
• Asymmetric (one key for local authentication, another for remote)

Authentication is asymmetric by design in IKEv2—each peer may use a different method to prove its identity. For example, one side might use PSK while the other uses EAP.

 

Keyring Structure and Configuration

To configure a keyring:

1. Create the keyring:

crypto ikev2 keyring ikev2_keyring

 

2. Reference it in the IKEv2 profile:

crypto ikev2 profile ikev2_profile
keyring local ikev2_keyring

 

3. Define peer blocks:

peer peer1
address 192.168.1.0 255.255.255.0
identity fqdn domain abc.com
identity email domain abc.com
pre-shared-key local key1
pre-shared-key remote key2

Each peer block can define:

• An address (with optional wildcard masks)
• A hostname (limited use, only one per block)
• One or more identities (FQDN, email, key-id, IP)

 

Here’s another example with full options:

peer peer2
hostname peer2
address 192.168.2.1 255.255.255.255
identity address 192.168.2.1
identity key-id peer2
identity fqdn peer2.abc.com
identity email peer2@abc.com
pre-shared-key key

Note: You can have overlapping peer blocks, but Cisco recommends avoiding this. If overlaps do occur, the most specific match is always used.

 

Key Lookup Process: Initiator vs Responder

Initiator key lookup occurs before the IKE negotiation begins. Since the peer identity is not yet known (it’s received later in the IKE_AUTH response), the initiator can only match keys based on:

• Peer IP address
• Hostname (if explicitly configured via set peer hostname dynamic)

Responder key lookup happens after the IKE_AUTH request is received. By this point, the responder knows the peer’s:

• IP address (from the incoming packet)
• IKE identity (from IKE_AUTH payload)

Thus, the responder has more options for key matching, including:

• FQDN
• Email
• Key-ID
• IPv4/IPv6 address

 

Key Lookup Matching Order

When performing key lookup:

1. Identity-based matching (FQDN, email, key-id, IP identity) is attempted first.
2. If no match is found, fallback to IP address matching.
3. Most specific match always wins in case of overlap.

*Only supported via crypto map with set peer hostname.

 

Keyring Best Practices

• Each peer block must be unique and contain complete key information.
• A keyring can be reused across multiple IKEv2 profiles.
• Use asymmetric keys (pre-shared-key local/remote) for greater flexibility, especially when one side has stricter identity validation needs.
• For strong security, ensure pre-shared keys meet length requirements:
  • 128-bit strength ≈ 20 base-94 characters
  • 192-bit strength ≈ 30 base-94 characters
  • 256-bit strength ≈ 40 base-94 characters

 

Debugging Key Lookup

For troubleshooting IKEv2 key lookup, use the following commands:

debug crypto ikev2
debug crypto ikev2 internal
debug crypto kmi

These help pinpoint whether key mismatches are due to identity misconfigurations, mismatched key blocks, or lookup limitations (e.g., unsupported hostname lookup on responders).

IKEv2 keyrings are foundational to PSK-based VPN setups. By understanding their structure, scope, and lookup logic, you can configure scalable, secure, and properly authenticated VPN environments, especially when integrating with dynamic IKEv2 profiles and per-peer tunnels.

 

Cisco IKEv2 Profile Deep Dive: Configuration, Matching, and Deployment Best Practices

The IKEv2 profile is the heart of Cisco’s IKEv2 VPN architecture. It defines the peer group and authentication parameters required for establishing secure VPN tunnels. Whether you’re building out FlexVPN servers, remote access headends, or site-to-site VPNs, understanding how to design and apply IKEv2 profiles is critical.

 

What is an IKEv2 Profile?

An IKEv2 profile is a mandatory configuration element in Cisco IOS. It defines peer identity matching, authentication methods, and other operational parameters like dead peer detection (DPD), NAT keepalives, and SA lifetimes. The profile enables advanced features like AAA integration, certificate mapping, and tunnel interface binding, making it a powerful tool for customized peer handling.

IKEv2 profiles must be associated with an interface using the tunnel protection command. Multiple profiles can be created to support different peer groups based on identity, certificate attributes, or VRF bindings.

 

Configuring the IKEv2 Profile

To create a profile:

crypto ikev2 profile ikev2_profile

Within the profile, you configure how peers are matched. This is done using match identity (for identity-based peers) or match certificate (for certificate-based peers using PKI maps). You can also match peers based on FVRF and local IP address.

Example certificate map configuration:

crypto pki certificate map cert_map 10
subject-name co vpn.example.com

 

Identity Matching Methods

IKEv2 supports matching based on:

• Address (IPv4/IPv6)
• FQDN
• Email
• Key-ID

For broad matching, a “catch-all” profile can be created using:

match identity remote any

This is useful for fallback scenarios but cannot be combined with other identity or certificate match statements.

Matching is evaluated as follows:

• If both identity and certificate matches exist, match certificate takes precedence.
• Multiple match statements of the same type use OR logic.
• Multiple match statements of different types (e.g., FVRF + local address) use AND logic.

 

Authentication Methods

IKEv2 supports:

• Pre-shared key (PSK)
• RSA signature
• ECDSA signature
• EAP (used primarily with FlexVPN clients)

Example PSK configuration:

crypto ikev2 profile ikev2_profile
authentication local pre-share key key1
authentication remote pre-share key key2

 

For certificate-based methods:

crypto pki trustpoint ca_server1
enrollment url http://10.1.1.1
subject-name cn=R1
revocation-check none

crypto ikev2 profile ikev2_profile
match identity remote any
authentication local rsa-sig
authentication remote rsa-sig
pki trustpoint ca_server1

 

Advanced Features: DPD, NAT, and Tunnel Binding

Dead Peer Detection (DPD) can be configured per-profile:

dpd interval 10 periodic

• on-demand mode only sends DPD messages when no traffic is seen.
• periodic mode sends messages at regular intervals.

 

NAT Keepalive configuration:

nat keepalive 10

This ensures UDP encapsulated tunnels stay alive across NAT devices by sending periodic keepalives.

 

Tunnel binding is achieved via:

interface virtual-template1 type tunnel
ip unnumbered g1
tunnel source g1
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsec_profile

crypto ikev2 profile ikev2_profile
virtual-template 1

 

Attach the profile to a tunnel interface:

interface tunnel0
tunnel protection ipsec profile ikev2_profile

 

Local and Remote Identity Configuration

Each profile allows you to define the local IKE identity using:

identity local fqdn vpn1.example.com

If not explicitly configured, the router will use the local interface IP as the identity. Supported local identity types include:

• Address
• Distinguished Name (from certificate)
• Email
• FQDN
• Key-ID

This identity is sent during the IKE_AUTH exchange and used to validate the peer’s identity.

 

Certificate Trustpoint Behavior

When using certificate-based authentication, trustpoints determine how certificates are validated and what authorities are trusted. Key behavior includes:

• Initiator: Trustpoints are explicitly configured in the IKEv2 profile. If none match, fallback is allowed.
• Responder: Trustpoints must be selected from the profile that matches the peer identity—no fallback to global trustpoints.

 

Troubleshooting and Monitoring

Useful show commands include:

show crypto ikev2 profile
show crypto ikev2 session detailed
show crypto ikev2 sa detailed

 

Debugging DPD and session matching can be done with:

debug crypto ikev2
debug crypto kmi

 

Notes on Best Practices

• Always bind IKEv2 profiles to tunnel interfaces explicitly.
• Use match identity and match certificate to fine-tune peer grouping.
• For FlexVPN and scalable remote access, leverage virtual-template and DPD/keepalive tuning.
• When using EAP or PSK, make sure keys are prioritized in the profile over keyrings.

IKEv2 profiles are foundational for secure, scalable VPN deployments. Their flexibility allows precise peer control, dynamic session handling, and interoperability with AAA, certificates, and NAT—all critical in enterprise VPN environments.

 

Cisco IKEv2 Global Configuration: Features, Scaling, and Hardening

While most IKEv2 configuration in Cisco IOS happens within profiles and tunnel interfaces, global parameters exist that influence the behavior, performance, and resilience of the entire IKEv2 subsystem. These global settings provide a centralized way to configure features like cookie challenges for DoS mitigation, HTTP-based certificate retrieval, session admission limits, and NAT keepalives.

 

Overview of IKEv2 Global Parameters

 

HTTP URL-Based Certificate Lookup

IKEv2 supports certificate retrieval from an HTTP URL, a useful feature when a certificate is too large to send in-band. This allows the responder to validate the certificate using a retrieved public key instead of requiring the certificate in the AUTH exchange.

To enable:

crypto ikev2 http-url cert
crypto ikev2 certificate-cache 1-2000

 

The client must send the Subject Information Access (SIA) URL instead of its certificate using a certificate map override:

crypto pki trustpoint CA
enrollment url http://10.1.1.100
revocation-check crl
match certificate local override sia 1 http://192.168.1.100/der

 

Verification commands:

show crypto ikev2 stats ext-service
show crypto ikev2 certificate-cache

 

Certificate Maps and Matching

You can configure certificate maps to match peer identities and define behavior such as overriding the SIA:

crypto pki certificate map certmap 10
subject-name eq router1.cisco.com

crypto ikev2 profile default
match certificate certmap
identity local dn
authentication remote rsa-sig
authentication local rsa-sig
pki trustpoint CA

 

Multiple override SIA URLs can be defined:

match certificate local override sia 1 http://192.168.1.1/3.der
match certificate local override sia 2 http://192.168.1.1/subca1.der

 

IKEv2 Cookie Challenge

To defend against IKE_SA_INIT floods from spoofed IPs, IKEv2 implements a cookie challenge. When triggered, the responder replies with a cookie request instead of processing the full exchange.

By default, it’s enabled with:

crypto ikev2 cookie-challenge 0

 

This means all IKE_SA_INIT requests will receive a cookie challenge. You can increase the limit to tolerate more in-progress sessions:

crypto ikev2 cookie-challenge 0-1000

 

IKEv2 Call Admission Control (CAC)

IKEv2 CAC prevents device overload by limiting the number of simultaneous IKEv2 SAs. This protects the crypto engine and CPU by preventing excessive negotiation attempts.

• Default limits: 40 (incoming) / 400 (outgoing)
• Configure global max limit:
  crypto ikev2 limit max-sa 1-9999
• Control active negotiations:
  crypto ikev2 limit max-in-negotiation sa 1-9999 {incoming | outgoing}

 

To monitor CAC statistics:

show crypto ikev2 stats

IKEv2 global configuration allows you to harden your VPN headend, optimize performance, and scale securely. These parameters complement tunnel- and profile-level configurations and are particularly important in high-scale FlexVPN environments where cookie protection, certificate retrieval optimization, and admission control make the difference between a stable service and a denial-of-service vector.

 

Fine-Tuning IKEv2 and IPsec on Cisco IOS: Configuration and Smart Defaults

When deploying IKEv2-based VPNs on Cisco IOS, understanding and optimizing key parameters like window size, dead peer detection, and diagnostics can significantly improve performance and resilience. This post explores critical elements of IKEv2 and IPsec configuration, including how to simplify deployments using Cisco’s smart defaults.

 

IKEv2 Window Size

IKEv2 exchanges operate in pairs: every sent packet is expected to be acknowledged by the receiver. To manage throughput and flow control, Cisco IOS uses the SET_WINDOW_SIZE notification payload in the IKE_SA_INIT exchange. This value determines how many IKEv2 message pairs can be in-flight at any given time. By default, Cisco sets the window size to 5, which allows up to five IKEv2 message exchanges to be outstanding before waiting for an acknowledgment. This is usually sufficient, as it’s rare for more than five exchanges to be pending simultaneously. To adjust the window size, use the following command:

crypto ikev2 window 1-200

 

Dead Peer Detection (DPD)

Dead Peer Detection (DPD) is essential for detecting unreachable peers and removing stale security associations. DPD settings can be configured globally using:

crypto ikev2 dpd R-U-There interval between 10-3600 Retry interval 2-60

This helps maintain tunnel integrity by triggering retries or clearing associations when no response is received from the remote peer.

 

NAT Keepalive

NAT devices often interfere with VPN tunnels unless keepalive packets are sent periodically. Cisco allows global configuration of NAT keepalives using:

crypto ikev2 nat keepalive

This feature ensures that NAT mappings stay alive, especially critical for tunnels traversing NAT boundaries.

 

IKEv2 Diagnostics

IKEv2 diagnostics can be invaluable when troubleshooting VPN failures. Cisco IOS maintains a database of exit paths and error types, which can be enabled with:

crypto ikev2 diagnose error 1-1000

This command defines how many entries the error database will store. You can view diagnostic information using:

• show crypto ikev2 diagnose error

• show crypto ikev2 diagnose error count

• show crypto ikev2 diagnose error count detailed

These outputs provide insight into the nature and frequency of connection issues.

 

IPsec Configuration Overview

Cisco IOS implements IPsec in an interface-centric fashion. This means that the Security Policy Database (SPD) and Security Association Database (SAD) are tied to individual interfaces. Tunnel protection is a modern approach to IPsec configuration and is common in FlexVPN and DMVPN setups.

When configuring IPsec, administrators must define:

1. What traffic to protect (via traffic selectors)
2. How to protect it (protocol, mode, algorithms, SA lifetime, etc.)
3. Whom to protect it with (the remote peer)

The tunnel protection command binds IPsec parameters to a tunnel interface using an IPsec profile. The traffic selectors and peer IP are derived directly from the tunnel interface:

• Local address: from tunnel source IP
• Peer address: from tunnel destination IP
• For GRE tunnels: tunnel mode gre
• For IPsec VTIs: tunnel mode ipsec or tunnel mode gre multipoint

Traffic selectors default to ip gre host src host dst for GRE and ip any any for IPsec VTIs.

 

IPsec Profile Configuration

Key commands in the IPsec profile include:

Here’s an example IPsec configuration:

crypto ipsec transform-set tset esp-aes esp-sha-hmac mode transport

crypto ipsec profile ipsec_profile
set transform-set tset
set ikev2-profile ikev2_profile

interface tunnel0
tunnel protection ipsec profile ipsec_profile

 

Leveraging Smart Defaults

To streamline configuration, Cisco IOS provides smart defaults for IKEv2 proposals, policies, and IPsec profiles. These defaults cover the most common use cases and reduce complexity, allowing users to deploy secure tunnels quickly with minimal configuration.

With smart defaults, the user only needs to specify the IKEv2 profile (authentication methods and keyring or trustpoint), then apply the default IPsec profile to the tunnel. This makes it much easier to get up and running.

You can view the defaults with:

• show crypto ikev2 proposal defaults

• show crypto ikev2 policy default

• show crypto ipsec profile default

By understanding how each component works and when to use smart defaults, administrators can streamline VPN deployments and maintain secure, efficient tunnels across Cisco IOS infrastructure.

 

Understanding IKEv2 Fragmentation on Cisco IOS

IKEv2 uses UDP as its transport protocol, and most IKEv2 messages are small, typically under 500 bytes. However, the IKE_AUTH exchange is an exception. When using digital certificates, the IKE_AUTH payload can grow significantly in size, sometimes exceeding the path Maximum Transmission Unit (MTU), which can lead to issues during transmission across the network.

When a packet exceeds the MTU, the IP layer has a few options: the packet can be dropped (with or without notifying the sender), or it can be fragmented into smaller pieces. However, fragmented packets are susceptible to being dropped by intermediate security or NAT devices, which can prevent the successful establishment of the IKEv2 Security Association (SA). This challenge is addressed by IKEv2 fragmentation, a method that breaks down large IKE messages at the IKE layer—before they are encapsulated in UDP and IP—ensuring that the resulting IP packet stays below the minimum link MTU between peers.

To avoid fragmentation-related issues, hosts typically rely on Path MTU Discovery (PMTUD). This technique allows a device to determine the smallest MTU on a path and set the “Don’t Fragment” (DF) flag accordingly. If a device along the path cannot forward a packet due to size limitations and the DF flag is set, it will drop the packet and ideally return an ICMP message indicating the issue. However, some devices drop oversized packets silently, without returning ICMP unreachable messages, thereby breaking PMTUD and leading to failed connectivity.

RFC 7383 defines the mechanism for advertising IKEv2 fragmentation support. Peers signal their capability to fragment IKEv2 messages during the IKE_SA_INIT exchange by sending the IKEV2_FRAGMENTATION_SUPPORTED notification payload. If both peers support this capability, then IKE_AUTH and subsequent encrypted messages can be fragmented at the IKE layer rather than the IP layer, preventing problems caused by intermediate fragmentation and security devices.

Fragmentation at the IKE layer occurs only if the message exceeds a certain size threshold and only after the capability has been negotiated in the IKE_SA_INIT exchange. Cisco IOS supports two types of IKEv2 fragmentation: a Cisco proprietary method and the IETF standard method. The key difference lies in when fragmentation happens relative to encryption. Cisco’s method fragments the encrypted payload, while the IETF method performs fragmentation before encryption using a special Encrypted Fragment payload. The IETF version includes fragment numbering fields in cleartext, simplifying reassembly without requiring decryption for verification.

Cisco IOS is capable of interoperating with peers that support either fragmentation method or both. If both the Cisco and IETF fragmentation methods are advertised during negotiation, the IETF method will be chosen. The table below shows the active fragmentation type selected based on peer capability:

By default, IKEv2 fragmentation is disabled on Cisco IOS. To enable it, use the global configuration command:

crypto ikev2 fragmentation

 

The default IKEv2 fragmentation MTU size is set to 576 bytes for IPv4 and 1280 bytes for IPv6. You can customize this threshold using:

crypto ikev2 fragmentation mtu mtu-size

The allowable MTU size range is 68 to 1500 bytes.

 

To verify whether an IKEv2 session is actively using fragmentation, issue the command:

show crypto ikev2 sa detailed

This feature is essential for robust VPN deployment in environments where certificate-based authentication and intermediate security devices may otherwise disrupt large IKEv2 messages. Proper configuration of IKEv2 fragmentation ensures reliable tunnel negotiation, even across restrictive network paths.

 

Integrating SGT Tags into IPSec with IKEv2: Cisco CMD Header Explained

In Cisco environments, Security Group Tags (SGTs) play a critical role in policy enforcement, especially in identity-based networking. When using IPSec with Cisco IOS, devices can transmit SGT information securely across the network by embedding it into the IPSec Security Association (SA) via the Cisco Meta Data (CMD) header.

The CMD header is a Cisco-specific extension inserted immediately after the ESP (Encapsulating Security Payload) header in IPSec packets. This header carries the SGT information in an encrypted and integrity-protected form, ensuring that the identity metadata remains secure throughout transit.

SGT capability negotiation between peers happens during the IKE_SA_INIT exchange. Devices advertise their support for the CMD header using a Vendor ID (VID) payload labeled CISCO-CTS-SGT. This VID is private to Cisco and should be ignored by non-supporting devices. If both peers support the CMD header, they can include SGT information in the IPSec SA.

However, if one peer includes the CMD header but the other does not support or understand it, the receiving device will be unable to process the decrypted payload, causing the traffic to be dropped. The ESP header will indicate the presence of the CMD header by using a next header value of 99 (reserved for private encryption schemes), signaling that the next layer contains the CMD metadata.

It’s important to note that SGT tagging in IPSec is only supported when using Virtual Tunnel Interfaces (VTIs). This is because, with GRE tunnels, traffic is encapsulated in GRE before encryption, meaning only GRE source and destination IPs are visible to the tunnel. Since SGTs rely on identifying end-host IP addresses, GRE mode lacks visibility into the payload and cannot support SGT tagging in transit.

Another limitation arises with packet fragmentation. If fragmentation occurs, whether before or after encryption, only the first fragment will contain the inline SGT tag. This makes it essential to manage MTU and fragmentation behaviors carefully in networks relying on SGT enforcement.

To verify whether an IPSec SA includes the SGT tag, use:

show crypto ikev2 sa detailed

 

And for real-time troubleshooting of SGT metadata:

debug crypto ipsec metadata sgt

By leveraging the CMD header and SGT negotiation capabilities, Cisco IOS enables secure, policy-driven segmentation across IPSec tunnels—particularly in environments utilizing TrustSec or identity-based access controls.

 

Managing IKEv2 Session Authentication, Revocation, and Lifetime on Cisco IOS

IKEv2 offers robust authentication mechanisms, primarily relying on certificates to validate the identity of peers during VPN establishment. When a certificate is presented, the IKEv2 process performs multiple checks. These include verifying the cryptographic signature of the certificate authority (CA), checking the certificate’s validity period, and—if configured—conducting a revocation check to ensure the certificate has not been blacklisted. However, IKEv2 has a critical limitation: it does not natively support certificate revalidation during an active session. Unlike IKEv1, which performs re-authentication during session rekeying, IKEv2 treats authentication as a one-time event for the session duration.

 

Disconnecting Sessions on Certificate Revocation

To handle certificate revocation dynamically, Cisco IOS provides a mechanism to disconnect peers whose certificates have been revoked. This is achieved with the command:

crypto ikev2 disconnect-revoked-peers

 

This command enables the router to actively terminate sessions when a certificate is found to be invalid due to revocation. To optimize revocation handling, administrators can tune how and when Certificate Revocation Lists (CRLs) are downloaded and refreshed. Useful options include:

• Scheduling regular CRL downloads:
  crypto pki crl download schedule time
• Pre-publishing CRL updates before expiry:
  crypto pki crl download schedule prepublish
• Refreshing cached CRLs periodically:
  crypto pki crl download trustpoint
  crypto pki crl refresh-cache

 

These steps help minimize the window of exposure during which a revoked certificate might still be trusted.

 

Certificate Expiry Enforcement

Modern versions of IOS support tying the IKEv2 SA lifetime to the certificate’s validity period. This means that if a certificate expires, the associated IKEv2 SA will be torn down automatically. Any attempt to re-establish the session will fail unless a new valid certificate is presented. This behavior is enabled by default in Cisco IOS. However, it can be disabled by using the command:

no lifetime certificate

This allows some flexibility for scenarios where certificate expiration policy enforcement is not required.

 

Session Lifetime Management

IKEv2 treats authentication as a one-time event for the life of the session. Once an IKEv2 SA is established and the authentication is complete, the session persists without revalidation. However, administrators can define a specific lifetime for the IKEv2 session using either CLI configuration or RADIUS-based authorization.

To configure the session lifetime locally:

session-lifetime 120–25920000

Alternatively, the session timeout can be controlled via RADIUS using attribute 27 (Session-Timeout). When returned in the RADIUS Access-Accept message, this value will dictate how long the IKEv2 SA and associated IPSec SAs remain active before being torn down.

 

Using Smart Defaults with Pre-Shared Keys

Cisco IOS supports a streamlined approach for establishing IKEv2 sessions using smart defaults. When enabled, smart defaults allow a VPN tunnel to be created using just two configuration elements: the IKEv2 profile and the IKEv2 keyring. This greatly reduces configuration complexity, especially in environments where certificate-based authentication isn’t required.

With these options, Cisco provides network administrators powerful tools to manage IKEv2 security lifecycles, from certificate validation and revocation handling to defining session timeouts and minimizing configuration overhead.

 

IKEv2 with Elliptic Curve Digital Signature Algorithm (ECDSA) Authentication on Cisco IOS

For high-security VPN deployments, Cisco IOS allows the use of Elliptic Curve (EC) certificates to authenticate IKEv2 peers using the Elliptic Curve Digital Signature Algorithm (ECDSA). This approach ensures both strong cryptographic integrity and performance, leveraging modern cryptographic primitives like AES-GCM and SHA512. Below is an overview of the algorithm suite used in this configuration:

 

Step 1: Create a Certificate Map

A certificate map anchors peer authentication by matching a specific subject name in the certificate. In a point-to-point site-to-site VPN, this map can be made highly specific (e.g., by matching a peer’s Distinguished Name):

crypto pki certificate map name num
subject-name co contains

 

Step 2: Define the IKEv2 Proposal

Create an IKEv2 proposal specifying the encryption and integrity algorithms:

crypto ikev2 proposal nge
encryption aes-gcm-256
prf sha512
group 21

 

Step 3: Define the IKEv2 Policy

Next, create a policy that references the proposal and enables compatibility with any VRF:

crypto ikev2 policy default
match vrf any
proposal nge

 

Step 4: Configure the IKEv2 Profile

The profile defines how certificates are used and ties in the certificate map. It uses the DN from the certificate for peer identity, specifies ECDSA authentication, and links to a trustpoint. Dead Peer Detection (DPD) is also configured:

crypto ikev2 profile nge
match certificate certmap
identity local dn
authentication remote ecdsa-sig
authentication local ecdsa-sig
pki trustpoint ecdsa_tp
dpd 10 2 on-demand

 

Step 5: Create the IPsec Transform Set

The transform set defines how traffic will be encrypted. Since AES-GCM-256 is a combined cipher, it includes both encryption and integrity protection, so no separate HMAC is required:

crypto ipsec transform-set nge-transform esp-gcm 256
mode transport

 

Step 6: Create the IPsec Profile

This profile ties the IKEv2 profile and transform set together and enables Perfect Forward Secrecy (PFS) with Group 21:

crypto ipsec profile nge-profile
set transform-set nge-transform
set pfs group21
set ikev2-profile nge

 

Step 7: Configure Interfaces

Set up a loopback interface to act as the logical source or destination for tunnel traffic:

interface loopback0
ip address 192.168.10.1 255.255.255.0

 

Then configure the tunnel interface, binding it to the physical source and peer destination. Apply the IPsec profile for tunnel protection:

interface tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel source g1
tunnel destination 10.10.10.2
tunnel protection ipsec profile nge-profile

 

Step 8: Verification

After deployment, verify tunnel status and cryptographic association using:

show crypto sockets
show crypto ikev2 sa detailed

Using ECDSA with IKEv2 enables secure, certificate-based VPNs with a high assurance of authenticity, privacy, and integrity. With these configurations, you’re aligning your VPN infrastructure with modern cryptographic best practices.

 

IKEv2 Authorization Policies and AAA Integration in Cisco IOS

IKEv2 authorization policies play a crucial role in managing VPN behavior by applying policy attributes sourced from an external AAA server. These policies determine how traffic is handled during and after the VPN establishment, especially in Cisco FlexVPN deployments.

 

Defining IKEv2 Authorization Policy

An IKEv2 authorization policy is configured globally on the router using the crypto ikev2 authorization policy command. This policy can reference attribute lists created via the IOS AAA configuration model. These attribute lists can include various RADIUS-type directives, such as interface-specific MTU settings or tunnel key assignments:

aaa attribute list attr-list1
attribute type interface-config "ip mtu 1100"
attribute type interface-config "tunnel key 10"

 

To enable AAA and associate the policy list locally, use:

aaa new-model
aaa authorization network aaa_list1 local

 

A helpful command to verify policy application is:

show crypto ikev2 authorization policy

Policies defined via AAA can include local attributes (applied on the router’s interface/session) and remote attributes (sent to the peer via IKEv2 Configuration Exchange). Cisco IOS supports three types of IKEv2 authorization:

Enabling Cached or Implicit Authorization

When you want to re-use previously authenticated attributes for authorization (known as implicit authorization), you can use the cached keyword:

aaa authorization user psk cached

 

Alternatively, define a name string or name-mangler that pulls identity information from the peer’s IKE identity (e.g., hostname, FQDN):

aaa authorization user psk list aaa_list name-mangler name_mangler password password

 

User Authorization Configuration Using External AAA (RADIUS)

User authorization allows per-user policies based on IKE identities such as FQDNs or hostnames. The IKEv2 name mangler extracts relevant identity portions to perform AAA lookups. Here’s a complete configuration example using RADIUS:

1. Enable AAA and define server groups:

aaa new-model

aaa group server radius radius_group1
server name radius_server1

aaa group server radius radius_group2
server name radius_server2

 

2. Define AAA method lists for user authorization:

aaa authorization network aaa_list1 group radius_group1
aaa authorization network aaa_list2 group radius_group2

 

3. Configure individual RADIUS servers:

radius server radius_server1
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_server1_key

radius server radius_server2
address ipv4 172.16.1.4 auth-port 1645 acct-port 1646
key radius_server2_key

 

4. Define IKEv2 name manglers:

crypto ikev2 name-mangler name_mangler1
fqdn hostname

crypto ikev2 name-mangler name_mangler2
dn common-name

 

5. Apply user authorization in the IKEv2 profile:

crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
authentication remote rsa-sig
aaa authorization user psk list aaa_list1 name-mangler name_mangler1
aaa authorization user cert list aaa_list2 name-mangler name_mangler2

 

Debugging IKEv2 Authorization

For troubleshooting AAA and IKEv2 authorization behavior, the following debug commands are useful:

debug crypto ikev2
debug aaa subsys
debug radius authentication

By tightly integrating AAA policies with IKEv2, Cisco IOS allows administrators to enforce fine-grained access control, policy injection, and session attributes dynamically. Whether you’re building user-based VPNs or scaling FlexVPN deployments, proper authorization policy setup ensures both security and flexibility.

 

IKEv2 Group Authorization in Cisco FlexVPN: Local and External AAA Configuration

In Cisco FlexVPN deployments, IKEv2 group authorization provides a scalable way to apply common policy attributes across a set of peers. These policies are tied to shared identity characteristics—such as domain names or other common segments of the authenticated IKE identity—making them ideal for scenarios involving multiple peers with similar roles or requirements.

The group authorization process typically uses the IKEv2 name mangler, which extracts a specific portion of the IKE identity (like the domain part of an FQDN) to perform policy lookups. This allows the system to map identity to policy with precision and consistency.

 

Local AAA Configuration for Group Authorization

To configure group authorization using the local AAA database, follow these steps:

1. Enable AAA:

aaa new-model

 

2. Define the AAA method list:

aaa authorization network aaa_list1 local

 

3. Create the IKEv2 name mangler:

crypto ikev2 name-mangler name_mangler1
dn domain

 

4. Define the local IKEv2 authorization policy:

crypto ikev2 authorization policy domain1
route set interface
route set remote ipv4 192.168.2.0 255.255.255.0

 

5. Apply group authorization within the IKEv2 profile:

crypto ikev2 profile default
match identity remote any
identity local dn
authentication local rsa-sig
authentication remote pre-share
authentication remote rsa-sig
pki trustpoint ca_server1
aaa authorization group cert list aaa_list1 name-mangler name_mangler1

This setup allows a router to enforce consistent policy across multiple peers based on shared identity characteristics without requiring individual mappings.

 

External AAA Server Configuration for Group Authorization

When scaling across large networks, group authorization can also be offloaded to external RADIUS servers. Here’s how to configure it:

1. Enable AAA:

aaa new-model

 

2. Define RADIUS server groups:

aaa group server radius radius_group1
server name radius_server1

 

3. Define AAA method list using the RADIUS group:

aaa authorization network aaa_list1 group radius_group1

 

4. Configure individual RADIUS servers:

radius server radius_server1
address ipv4 172.16.1.4 auth-port 1645 acct-port 1646
key radius_server1_key

 

5. Create the name mangler for domain-based matching:

crypto ikev2 name-mangler name_mangler1
dn domain

 

6. Apply external group authorization in the IKEv2 profile:

crypto ikev2 profile default
match identity remote any
identity local dn
authentication local rsa-sig
authentication remote pre-share
authentication remote rsa-sig
pki trustpoint ca_server1
aaa authorization group cert list aaa_list1 name-mangler name_mangler1

This configuration leverages external policy logic while maintaining the flexibility of IKEv2 identity-based mapping through name manglers.

 

Debugging Group Authorization

To troubleshoot group authorization issues, use these debug commands:

debug crypto ikev2
debug crypto ikev2 internal
debug aaa subsys
debug radius authentication

These outputs can help diagnose policy mismatch, identity parsing, or RADIUS communication problems.

With group authorization, FlexVPN administrators can manage policy at scale, either from the router itself or via an external AAA infrastructure, while retaining the granularity needed for secure, identity-aware VPN sessions.

 

IKEv2 Implicit Authorization in Cisco FlexVPN: Leveraging Cached AAA Attributes

In Cisco FlexVPN deployments, implicit authorization is a powerful feature that streamlines the policy application process by using cached policy attributes from an external AAA server, most commonly a RADIUS server. This approach significantly reduces overhead by eliminating the need for an explicit user authorization round trip, especially when using pre-shared key or EAP-based authentication.

 

What Is Implicit Authorization?

When a peer authenticates using a username tied to a pre-shared key or EAP credentials, the external AAA server (e.g., RADIUS) may send back a full set of policy attributes along with the authentication response. These attributes are stored locally and used for session authorization. This method is triggered by configuring the following option:

aaa authorization user psk cached

Once enabled, any unsolicited attributes returned during authentication are treated as authorization attributes. Without the cached keyword, these attributes are ignored, and explicit user authorization would need to be configured manually.

 

Benefits of Implicit Authorization

• Reduces AAA traffic by skipping explicit user authorization lookups.
• Speeds up VPN connection time by using already-received policy attributes.
• Works seamlessly with AAA-based pre-shared keys and EAP authentication.

 

Configuring Implicit Authorization for FlexVPN

Below is a complete configuration example using an external RADIUS server to support implicit authorization.

1. Enable AAA:

aaa new-model

 

2. Define the RADIUS server group:

aaa group server radius radius_group1
server name radius_server1

 

3. Create the AAA method list using the group:

aaa authorization network aaa_list1 group radius_group1

 

4. Define the RADIUS server:

radius server radius_server1
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_server1_key

 

5. Define the IKEv2 name mangler to extract the hostname from the FQDN:

crypto ikev2 name-mangler name_mangler1
fqdn hostname

 

6. Configure the IKEv2 profile with pre-shared key authentication and enable implicit authorization:

crypto ikev2 profile default
match identity remote any
authentication local pre-share
authentication remote pre-share
keyring aaa aaa_list1 name-mangler name_mangler1
aaa authorization user psk cached

Once this setup is complete, the IKEv2 profile will use the pre-shared key and automatically apply any policy attributes (like routes, QoS, IP pool assignments, etc.) returned by the RADIUS server during authentication, without needing a separate authorization request.

By enabling implicit authorization, Cisco IOS allows you to simplify FlexVPN deployments, particularly in environments with large numbers of users or where minimizing AAA server load is a priority. It’s a highly efficient mechanism that ensures flexibility and speed without compromising on policy control.

 

FlexVPN Authorization Types: Coexistence and Precedence in Cisco IOS

Cisco FlexVPN provides administrators with powerful tools to enforce session-based policies using AAA authorization. In a FlexVPN deployment, three types of authorization—user, group, and implicit—can coexist within a single IKEv2 profile. Each of these mechanisms provides a different layer of policy control, and understanding how they interact is crucial for building scalable, secure VPN environments.

 

Coexistence of Authorization Types

All three authorization types can be configured together. When an IKEv2/IPsec session is established, the attributes from these different types are merged in a specific order. The final set of merged attributes is applied locally and optionally sent to the remote peer using the IKEv2 Configuration Exchange.

The attribute merging process happens in the following sequence:

• Step 1 – User + Implicit Authorization:
  • Attributes from user authorization and implicit authorization are merged.
  • In case of duplicate attributes, user attributes take precedence.
  • This produces the merged user attributes.
• Step 2 – Merged User + Group Authorization:
  • Group attributes are combined with merged user attributes.
  • By default, merged user attributes take precedence, unless group override is explicitly configured.
• Step 3 – Final Policy Application:
  • The fully merged attributes are sent to the peer (via Configuration Exchange) and also applied locally to the session.

This merging hierarchy ensures that conflicting policy attributes are handled in a predictable manner.

 

Configuration Example

Below is a complete configuration that enables all three authorization types with the ability to manage attribute precedence.

Step 1: Enable AAA and Define Authorization Sources

aaa new-model

aaa group server radius radius_group1
server name radius_server1

aaa authorization network aaa_psk_list group radius_group1
aaa authorization network user_author_list group radius_group1
aaa authorization network group_author_list local

radius server radius_server1
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_server1_key

Step 2: Configure Name Manglers

crypto ikev2 name-mangler aaa_psk_name_mangler
fqdn all

crypto ikev2 name-mangler user_author_name_mangler
fqdn hostname

crypto ikev2 name-mangler group_author_name_mangler
fqdn domain

 

Step 3: Define Group Authorization Policy

crypto ikev2 authorization policy domain1
pool pool3
def-domain domain1

 

Step 4: Configure the IKEv2 Profile with All Authorization Types

crypto ikev2 profile default
match identity remote any
authentication local pre-share
authentication remote pre-share

keyring aaa aaa_psk_list name-mangler aaa_psk_name_mangler

aaa authorization group psk list group_author_list name-mangler group_author_name_mangler
aaa authorization user psk cached
aaa authorization user psk list user_author_list name-mangler user_author_name_mangler

This setup ensures that the IKEv2 peer gets a policy enriched by user, group, and implicit authorization attributes.

 

Optional: Give Group Authorization Higher Precedence

If you want group authorization attributes to override user attributes, use the override keyword in the group authorization command:

crypto ikev2 profile default
match identity remote any
authentication local pre-share
authentication remote pre-share

keyring aaa aaa_psk_list name-mangler aaa_psk_name_mangler

aaa authorization group override psk list group_author_list name-mangler group_author_name_mangler
aaa authorization user psk cached
aaa authorization user psk list user_author_list name-mangler user_author_name_mangler

 

Summary of Attribute Precedence

• By default, User > Implicit > Group
• With group override, Group > User > Implicit
• Final attributes are applied both locally and sent to the peer (if using configuration exchange)

 

Troubleshooting Tips

Use these commands to troubleshoot and verify attribute resolution and session setup:

debug crypto ikev2
debug crypto ikev2 internal

Understanding and properly configuring the interaction between these authorization types allows network engineers to implement scalable and flexible VPN solutions that support both individual user access and group-based policy enforcement.

 

FlexVPN Configuration Exchange: Using IKEv2 to Dynamically Deliver Session Attributes

Cisco FlexVPN leverages the power of the IKEv2 protocol not just for secure peer authentication and SA negotiation, but also for dynamic configuration delivery using the Configuration Payload (CP) mechanism. This mechanism allows VPN peers to exchange configuration attributes such as IP addresses, routes, DNS servers, and other session-specific policies during IKE_AUTH or later informational exchanges.

How Configuration Exchange Works in FlexVPN

In IKEv2, configuration information is exchanged using special payloads like CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. These are carried in either the IKE_AUTH or INFORMATIONAL message exchanges. FlexVPN supports three key IKEv2 profile commands to manage configuration exchange behavior:

• config-exchange request: Enables the IKE initiator to send a CFG_REQUEST during the IKE_AUTH exchange. The responder replies with a CFG_REPLY. This command is enabled by default.
• config-exchange set send: Allows either party (initiator or responder) to push configuration data using CFG_SET messages. This is useful when information needs to be pushed, regardless of whether a request has been made. Typically occurs during informational exchanges.
• config-exchange set accept: Allows a device to accept a CFG_SET payload and send back a CFG_ACK. If disabled, any received configuration data via CFG_SET is ignored.

All three commands are enabled by default on Cisco IOS.

 

Types of Configuration Attributes in FlexVPN

FlexVPN supports several categories of configuration attributes that can be exchanged through this mechanism:

These attributes can be dynamically assigned and pushed during tunnel negotiation, allowing the VPN infrastructure to remain flexible and policy-driven.

 

Configuration Example: Using IKEv2 Configuration Exchange

To illustrate how configuration exchange fits into a FlexVPN deployment, consider the following example that uses a local AAA policy and pushes interface routes dynamically:

aaa new-model
aaa authorization network default local
crypto ikev2 authorization policy default
route set interface
route accept any

 

Then, in the IKEv2 profile:

crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
aaa authorization group psk list default default

config-exchange set send
config-exchange set accept
config-exchange request

This configuration:

• Enables dynamic assignment of routing information through route set interface
• Accepts any configuration attributes offered by the peer (route accept any)
• Uses config-exchange set and request to initiate and accept configuration data

IKEv2’s configuration exchange capabilities make Cisco FlexVPN highly dynamic and responsive to policy changes. Whether you’re provisioning routes, IP addresses, or advanced session policies, the ability to push and pull attributes via IKEv2 payloads ensures that VPN sessions are efficient and policy-compliant from the moment they’re established.

 

Automating Route Injection in FlexVPN with IKEv2 Group Authorization

One of the most powerful capabilities of Cisco FlexVPN is its ability to dynamically inject routes into the routing table based on authorization attributes received during IKEv2 negotiation. Through group authorization, a FlexVPN responder can push specific route information to the initiator, ensuring that traffic destined for protected subnets is automatically redirected through the secure IPSec tunnel.

This approach simplifies routing and policy enforcement, especially in large-scale VPN deployments where centralized control of subnet reachability is critical.

 

How It Works: Route Injection via AAA Attributes

When group authorization is used, remote subnets are learned and injected into the local routing table using attributes defined on the AAA server (or local AAA database). The supported route attributes follow this structure:

IPv4 Route Example:

route-set = ipv4 address mask next-hop address tag tag distance distance

 

IPv6 Route Example:

route-set = ipv6 address mask next-hop address tag tag distance distance

These attributes can be pushed from an external AAA server or defined locally via authorization profiles in IOS.

 

Configuration Example: Local Group Authorization with Route Injection

Here’s a working configuration example using the local AAA database to push route information:

aaa new-model
aaa authorization network default local

crypto ikev2 authorization policy default
route set local ipv4 192.168.6.0 255.255.255.0 tag 5000 distance 5
route set interface

In this setup:

• route set local injects a specific IPv4 route with administrative distance and tag
• route set interface enables dynamic routing over the FlexVPN tunnel interface

 

Then, define the IKEv2 profile to use pre-shared key authentication and apply the group policy:

crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
aaa authorization group psk list default default

 

Advanced Tips

• Multiple Prefixes:
  To push multiple prefixes, use the route set access-list command. This allows an access control list to define all desired prefixes for dynamic installation.
• Prefix Restrictions for Security:
  For increased security, especially in multi-tenant environments, use route set local to restrict the routes installed for a particular peer. This prevents unauthorized or unintended route propagation.

By using IKEv2 group authorization and AAA-integrated route injection, Cisco FlexVPN can dynamically and securely manage routing across IPsec tunnels. This capability reduces manual configuration overhead and supports scalable, policy-driven VPN deployments with centralized control over routing behavior.