Diving Deep Deep Deep into FlexVPN – Part 3: FlexVPN Server Operations

 

FlexVPN Server-Side Workflow: IKEv2 Tunnel Setup Sequence

When an IKEv2 initiator (typically a client or branch router) starts a session with a FlexVPN server, a series of well-defined steps unfold during the IKE_AUTH exchange. Understanding this flow is essential for debugging and optimizing dynamic FlexVPN deployments, especially when using virtual-access interfaces for tunnel instantiation.

 

FlexVPN Server Sequence of Events

Below is a breakdown of the FlexVPN server’s IKE_AUTH response workflow:

1. Peer Authentication
   Once the IKE_AUTH request is received, the server begins by authenticating the peer. This authentication is based on pre-configured credentials, such as pre-shared keys, EAP, or certificates, and the peer’s presented identity.
2. User & Group Authorization and Attribute Merging
   After authentication, authorization is performed using AAA policies. The system validates the user or group identity and merges the relevant attributes (from RADIUS, local user database, etc.). If the authorization step fails, the session is immediately terminated.
3. CFG_REQUEST Processing
   If the initiator includes a CFG_REQUEST payload (used to request address assignment), the server evaluates it. Based on the request, the server can assign IPv4, IPv6, or both (dual-stack) addresses. These addresses are derived from the merged AAA attributes. If the address allocation fails, the session is dropped.
4. Per-Session Interface Creation
   A virtual-access interface is dynamically created from a configured virtual-template. This P2P tunnel interface inherits settings from both the template and the AAA authorization response (especially interface-config attributes). This design gives FlexVPN its agility by allowing scalable, per-peer tunnel contexts.
5. IPsec SA Proposal Processing
   The server then evaluates the IPsec proposal offered by the peer. If accepted, the IPsec SA is bound to the just-instantiated virtual-access interface, integrated with the crypto engine, and enabled in the data plane.
6. CFG_REPLY Construction
   Finally, a CFG_REPLY payload is built and sent back to the initiator. This payload may include assigned IP addresses, DNS information, or other configuration attributes—concluding the IKE_AUTH exchange.

 

Summary of Key Behaviors

• Authorization precedes configuration: Without successful user or group authorization, no session is established, even if authentication succeeds.
• Virtual template cloning allows per-tunnel configuration without static interface provisioning.
• Dynamic address allocation is dependent on the successful processing of CFG_REQUEST.
• Per-session IPsec policies are attached after tunnel instantiation and allow scalability and customization across peers.

This dynamic and modular architecture makes FlexVPN a powerful choice for large-scale deployments requiring flexible, policy-based per-peer tunnel creation.

 

FlexVPN and EAP Authentication: Methods, Identity, and Configuration

When building scalable and secure VPN services with Cisco FlexVPN, EAP plays a pivotal role, especially when integrating with RADIUS-based AAA environments. FlexVPN supports EAP as a remote authentication method only, meaning the server must rely on an external EAP-capable AAA server, such as RADIUS.

 

EAP Authentication Flow

The FlexVPN server first performs a local authentication, typically using certificates. Once that’s successful, it delegates user authentication to an external EAP server via EAP. It does not support EAP as a local method, so you’ll always need to configure an external authenticator.

 

EAP Methods

There are two main categories of EAP methods in FlexVPN:

• Key-generating methods, which derive a Master Session Key (MSK) during authentication. This key is used between the client and the server as a shared secret during the final IKE_AUTH exchange.
• Non-key-generating methods, which do not derive a shared key. Instead, authentication falls back on using IKEv2 session keys (SK_pi and SK_pr) derived from Diffie-Hellman, treating them like pre-shared keys.

 

EAP Message Flow

EAP messages between the IKEv2 client and the FlexVPN server are embedded in the IKE_AUTH exchange. The FlexVPN server, acting as the EAP authenticator, relays these to the backend RADIUS EAP server using RADIUS attributes (EAP-Message, Access-Request, Access-Accept, etc.).

Key message behaviors:

• EAP-Request is used by the server to challenge the client.
• EAP-Response is used by the client to answer.
• EAP-Success / EAP-Failure indicate final result of authentication.

 

EAP Identity Handling

By default, the FlexVPN server uses the peer’s IKE identity as the EAP identity. However, many clients (e.g., AnyConnect or Microsoft IKEv2 clients) expect an explicit EAP-Identity Request. To handle this, enable the query-identity option:

authentication remote eap query-identity

If the IKE identity is an IP address, the EAP identity must be explicitly queried—otherwise, authentication may fail. This small setting is critical when interoperating with third-party clients.

 

EAP Timeout

You can control how long the FlexVPN server waits for an EAP response from the client before aborting. This is done with:

authentication remote eap timeout seconds

The default is 90 seconds. Adjust this based on expected client responsiveness and network latency.

 

EAP Configuration on Cisco FlexVPN

Here’s a step-by-step FlexVPN EAP configuration example:

1. Enable AAA:

aaa new-model
aaa authentication login authen_list_radius group radius_group

 

2. Define the RADIUS Server and Group:

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

 

3. Configure the IKEv2 Profile for EAP:

crypto ikev2 profile ikev2_profile
aaa authentication eap authen_list_radius
authentication remote eap query-identity
authentication remote eap timeout 120
authentication local rsa-sig
aaa authentication eap authen_list_radius

This configuration enables:

• Certificate-based local authentication
• RADIUS-based EAP for remote authentication
• Identity query for compatibility with modern IKEv2 clients
• A timeout window for EAP response
• Defined RADIUS keying and authentication flow

 

Summary

FlexVPN’s EAP support adds powerful, scalable, and flexible authentication capabilities, especially when integrated with RADIUS and identity-aware policies. Key items to remember:

• Use query-identity when dealing with external clients.
• Always use certificate-based local auth if EAP is the remote method.
• Be aware of timeout behavior and properly tune for reliability.

 

AAA-Based Pre-Shared Keys (PSK) in FlexVPN

When managing a large number of IKEv2 VPN initiators, hardcoding pre-shared keys (PSKs) per-peer doesn’t scale. Instead, FlexVPN supports AAA-based PSKs, enabling you to host both symmetric and asymmetric keys on an external RADIUS server. This approach allows for dynamic key lookup and is ideal for flexible, large-scale VPN deployments.

 

Configuring AAA-Based PSKs

The configuration takes place within the IKEv2 profile using the keyring directive:

keyring aaa aaa-list-name

 

If needed, you can apply a name mangler to transform the IKEv2 peer identity before passing it to the RADIUS server for lookup:

keyring aaa aaa_list name-mangler name_mangler1

If no mangler is applied, the full peer identity is used as the RADIUS lookup key.

 

RADIUS Attributes for AAA-Based PSKs

RADIUS provides multiple attributes to support PSK handling:

• Tunnel-Password (standard IETF) holds the symmetric PSK string.
• IKEv2-password-local (Cisco AV pair) is used for local authentication (i.e., to authenticate FlexVPN server to the client).
• IKEv2-password-remote (Cisco AV pair) is used for remote authentication (i.e., to authenticate client to server).
• You can cache the AAA-based PSKs and related attributes to reduce repeated RADIUS queries and speed up tunnel setup.

 

AAA-Based PSK Configuration Example

Here’s a full configuration workflow:

1. Enable AAA and define RADIUS method list:

aaa new-model
aaa authorization network aaa_list1 group radius_group1

2. Define RADIUS server and group:

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

 

3. Define name mangler (optional):

crypto ikev2 name-mangler name_mangler1
fqdn hostname

 

4. Configure IKEv2 Profile:

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

This configuration allows the FlexVPN server to dynamically retrieve pre-shared keys based on peer identities and simplifies administration by centralizing key management in RADIUS.

 

FlexVPN AAA Accounting Integration

Beyond authentication, FlexVPN can report session statistics like tunnel up/down events, encryption counts, and byte usage to a RADIUS server using AAA accounting. This is critical for organizations that need detailed auditing, billing, or policy enforcement.

1. Configuring AAA Accounting

Define an accounting method list:

aaa accounting network acc_list
action-type start-stop
group radius_group1

 

2. Enable accounting 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 accounting psk acc_list

This ensures that every time an IKEv2/IPSec session starts or ends, an accounting record is sent to the RADIUS server.

 

Summary

AAA-based pre-shared keys and accounting greatly enhance the manageability and observability of a FlexVPN deployment:

• Pre-shared keys are centrally managed in RADIUS, with optional name mangling and attribute caching.
• Session events and stats are reported via accounting, enabling tight integration with monitoring, compliance, or billing systems.

These features help scale FlexVPN for enterprise and service provider environments without sacrificing security or control.

 

FlexVPN Virtual-Access Configuration Using Virtual-Templates

In FlexVPN, when a session is established with a new peer, the server dynamically spawns a virtual-access interface based on a pre-configured virtual-template. This interface of type tunnel inherits all of the settings from the template and is used to encapsulate the IPSec tunnel for that specific peer.

 

Configuring a Virtual-Template

The virtual-template must be of type tunnel, and is configured using the ip unnumbered or ipv6 unnumbered command for IP addressing. For example:

interface virtual-template 1 type tunnel
ip unnumbered g1
tunnel protection ipsec profile default

 

A few things to note:

• Do not configure tunnel destination since peer addresses are unknown in advance.
• Optionally, configure tunnel source, but if omitted, it will inherit this from the IPSec peer.
• This template is later referenced in the IKEv2 profile with:
  virtual-template 1

Once a virtual-access instance is cloned from this template, it becomes immutable—no CLI modifications can be made until the session ends.

 

AAA-Driven Virtual-Access Configuration

Rather than creating a unique virtual-template per peer (which isn’t scalable), FlexVPN supports AAA-based virtual-access customization using RADIUS. This allows session-specific interface configurations via the interface-config attribute.

The interface-config attribute (a Cisco VSA) is pushed by the AAA server during authorization. These string-based CLI snippets are directly applied to the spawned virtual-access interface.

 

Interface-Config Precedence Order

By default, the server applies AAA-based attributes in this order:

1. Group Authorization
2. Implicit Authorization
3. User Authorization

However, if you configure:

aaa authorization group override

…then this order is reversed:

1. Implicit
2. User
3. Group

This gives fine-grained control over which configuration overrides the others.

 

Session-Based Configuration via IKEv2

If the virtual-template number mode auto option is used in the IKEv2 profile, FlexVPN derives the tunnel mode and IP family from the incoming IKE/IPSec session. This eliminates the need to statically configure tunnel encapsulation, further simplifying deployment.

 

Virtual-Access Cloning Configuration Example

Here’s how you can implement full AAA-driven interface customization using name manglers, attribute lists, and virtual-templates:

Step 1: Define AAA Method Lists

aaa authorization network aaa_list1 group radius_group1
aaa authorization network default local

 

Step 2: Define IKEv2 Name Manglers

crypto ikev2 name-mangler name_mangler1
fqdn hostname

crypto ikev2 name-mangler name_mangler2
fqdn domain

These transform the peer identity into a RADIUS username string for user or group lookups.

 

Step 3: Define AAA Attribute List

aaa attribute list attr_list1
attribute type interface-config “tunnel key 1”
attribute type interface-config “ip mtu 1000”

 

Step 4: Reference in 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 name-mangler name_mangler2
aaa authorization user psk list aaa_list1 name-mangler name_mangler1
virtual-template 1

This setup supports:

• Group and user AAA lookups
• Per-peer CLI-based customization
• Session-specific configuration without interface bloat

 

Step 5: Define the Virtual Template

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

 

Useful Verification Commands

To troubleshoot and inspect FlexVPN interface cloning:

show crypto session
show derived-config interface virtual-access 1

These commands let you verify the derived configuration of virtual-access interfaces and confirm the application of interface-config attributes.

 

Summary

FlexVPN’s use of virtual-templates and AAA-driven interface-config attributes gives you the power to deploy truly per-peer customized tunnels without needing one physical interface per peer. With name mangling, interface inheritance, and auto-detection support, your FlexVPN hub can scale cleanly across hundreds or thousands of clients.

 

 

Auto Detection of Tunnel Transport and Encapsulation in FlexVPN

FlexVPN supports automatic detection of tunnel encapsulation mode (GRE/IPSec, IPv4/IPv6) and transport protocol (IP, UDP, etc.), which is vital when supporting a variety of IKEv2 initiators that might use different tunnel modes or IP address types. Instead of statically configuring multiple virtual templates or manually enforcing tunnel encapsulation, the server can adapt dynamically per session.

 

How It Works

When an IKEv2 session is initiated, the server evaluates the encapsulation and transport type based on the IPsec traffic selector and initiator’s negotiation parameters. If the configuration uses mode auto, FlexVPN will override any tunnel mode configuration derived from AAA or the virtual-template and automatically select the proper mode for that session.

This is especially useful in situations like:

• Supporting both IPv4 and IPv6 remote peers
• Supporting both GRE and IP-in-IP encapsulation
• Handling AnyConnect clients vs. site-to-site routers without separate profiles

 

Enabling Auto-Detect Mode

To enable auto-detection, use the virtual-template <num> mode auto command within the IKEv2 profile. For example:

crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
virtual-template 1 mode auto

This configuration ensures that the FlexVPN server intelligently adapts to the encapsulation requirements of each session without requiring hardcoded tunnel mode definitions.

 

Useful Show Command for Verification

After a session is up, use this command to verify the encapsulation and transport protocol used by the virtual-access interface:

show interfaces virtual-template 1 | include protocol|transport

This command confirms the dynamically chosen transport type and encapsulation protocol used during session establishment.

 

Summary

Auto-detection of tunnel transport and encapsulation allows FlexVPN to maintain a single, scalable configuration while supporting a wide range of peer types and capabilities. This makes deployment easier, reduces template sprawl, and simplifies ongoing management—especially in hybrid networks with both site-to-site and remote access VPN users.

 

RADIUS Dynamic Authorization in FlexVPN: PoD & CoA Explained

Modern VPN infrastructures demand not just secure tunnel establishment but also real-time control over session behavior. FlexVPN supports this via RADIUS Dynamic Authorization Extensions, enabling centralized control of tunnel lifecycle events using:

• Packet of Disconnect (PoD) – to terminate sessions
• Change of Authorization (CoA) – to dynamically update session policies

 

RADIUS Packet of Disconnect (PoD)

PoD enables a RADIUS server to send an unsolicited disconnect-request to a Network Access Server (NAS) – in this case, the FlexVPN server. This feature is especially useful to:

• Force user re-authentication on long-lived sessions
• Apply a new policy to a reconnecting client
• Free up resources by terminating idle or stale sessions

 

Configuration Steps

1. Enable dynamic authorization on FlexVPN:

aaa server radius dynamic-author

 

2. Specify the DAC (Dynamic Authorization Client):

client radius-ip
server-key shared-key

 

3. On the DAC (RADIUS server), send a Disconnect-Request to the DAS (FlexVPN server) using the audit-session-id to uniquely identify the session to be terminated.

 

Show/Debug Commands

Find session identifiers:

show aaa user all | begin username

 

Verify action:

show crypto session
show derived-config interface virtual-access 1

 

RADIUS Change of Authorization (CoA)

Unlike PoD, CoA allows updating session policies (not terminating them) in real time. The FlexVPN server supports session-specific updates to:

• interface-config (commands applied directly to virtual-access interface)
• QoS policies using sub-policy-in and sub-qos-policy-in
• ACLs using inacl and outacl

All changes are targeted using the audit-session-id.

 

CoA Setup Example

1. Enable dynamic authorization on FlexVPN:

aaa server radius dynamic-author
client radius-ip
server-key shared-key

 

2. Push CoA updates from RADIUS server with:

audit-session-id

Updated policy attributes (e.g., ACLs, service-policies)

 

Applying QoS via CoA

1. Define QoS policies:

policy-map Input-QoS-policy-1
class class-default

policy-map Output-QoS-policy-1
class class-default

 

2. Apply to virtual template:

interface virtual-template1 type tunnel
ip unnumbered g1
tunnel protection ipsec profile default
service-policy input Input-QoS-policy-1
service-policy output Output-QoS-policy-1

3. Verify application:

show crypto session
show derived-config interface virtual-access 1

 

4. Trigger CoA from RADIUS server and confirm with:

debug aaa coa
debug vtemplate cloning

 

Updating Session ACLs Using CoA

To dynamically update access control policies:

1. Trigger CoA with updated ACL using inacl or outacl.

2. Use:

show ip interface virtual-access 1 | include access

…to confirm application.

 

Summary

With PoD, administrators can remotely terminate sessions on demand. With CoA, they can dynamically apply new ACLs, QoS policies, or interface attributes—all in real time. These features empower dynamic policy enforcement without tearing down existing tunnels.

FlexVPN’s support for dynamic authorization transforms your VPN infrastructure into a highly adaptable, centrally managed platform.

 

IKEv2 Auto-Reconnect in Cisco FlexVPN

In mobile or fluctuating network environments, it’s common for VPN tunnels to drop due to temporary loss of connectivity. FlexVPN addresses this with IKEv2 auto-reconnect, which allows Cisco AnyConnect clients to re-establish the IKEv2 session automatically, without prompting the user, when the network becomes available again.

This feature is especially useful when clients:

• Switch between Wi-Fi and cellular
• Enter sleep/hibernate mode
• Experience brief network outages

 

How It Works

During the initial IKEv2 session establishment, the FlexVPN server assigns a session token and other reconnect attributes to the AnyConnect client. If the session drops, the client reuses this data to reconnect quickly and securely.

The reconnect process is:

• Lightweight (no full IKE re-negotiation)
• Transparent to the end-user
• Authenticates using previously issued reconnect-token-id

 

Benefits of IKEv2 Auto-Reconnect

• Faster reconnections without full tunnel rebuilds
• Reuse of AAA attributes, avoiding round-trips to the RADIUS server
• Improved user experience—no need to re-login or click “Reconnect”
• Preserves session security with consistent identity and authentication
• Works seamlessly even if the user wakes their device from sleep/hibernate

 

Limitations

Auto-reconnect is not supported with pre-shared key (PSK) authentication. It requires:

• EAP or certificate-based authentication
• The FlexVPN server to authenticate using a certificate-only

The feature also fails (reverts to full IKEv2 negotiation) in these cases:

• User manually disconnects the VPN session
• AnyConnect client or FlexVPN server reboots
• The reconnect timeout expires and session data is discarded

 

Key Auto-Reconnect Attributes

These attributes are issued by the FlexVPN server during the initial session and reused for all reconnection attempts by the client.

 

Configuring Auto-Reconnect

The reconnect timeout can be adjusted with:

reconnect timeout seconds

This controls how long the server retains session state after disconnect due to network failure.

Additionally, AnyConnect XML profiles can be used to control reconnect behavior from the client side, enabling fine-tuned reconnect policies for enterprise environments.

 

Summary

FlexVPN’s IKEv2 Auto-Reconnect provides a seamless and secure experience for AnyConnect users, allowing always-on connectivity even in the face of network interruptions. While limited to certificate/EAP authentication, it drastically improves tunnel stability and user satisfaction in dynamic environments.

 

Smart DPD and IKEv2 Auto-Reconnect: Session Resilience in FlexVPN

Cisco FlexVPN integrates an intelligent Smart Dead Peer Detection (Smart DPD) mechanism to complement the IKEv2 Auto-Reconnect feature. This combination allows the server to identify temporary disconnects and preserve session state, enabling clients to seamlessly reconnect without renegotiating the tunnel from scratch.

 

How Smart DPD Works

When DPD is not explicitly configured, the FlexVPN server automatically enables Smart DPD. It monitors DPD probes from the client to determine if the peer is still reachable. If probes stop arriving, the server will begin sending its own probes to verify client availability.

• If the client responds, the session continues.
• If no response is received, the FlexVPN server preserves the session and moves it to an inactive state, awaiting client reconnection.

This minimizes unnecessary teardown/rebuild cycles, particularly in mobile scenarios (e.g., Wi-Fi loss, switching networks, sleep mode).

 

The IKEv2 Auto-Reconnect Flow

The FlexVPN server and AnyConnect client exchange reconnect attributes during the initial IKE_AUTH exchange, including:

• session-id

• token-id

• dpd-interval

• cleanup-interval

If the session becomes unreachable:

1. Smart DPD triggers session preservation.
2. The session moves to an inactive state.
3. The client later reconnects using the saved session-id and token-id.

The reconnect request uses PSK-based authentication, despite the initial session possibly using certificates or EAP.

 

Reconnect Behavior Summary

• The FlexVPN server uses certificate-based auth initially and issues reconnect attributes in the CFG_REPLY.
• The AnyConnect client, with reconnect support enabled, uses those attributes (session-id and token-id) to resume sessions.
• The reconnect works only if both client and server are up, and the reconnect timeout has not expired.
• If successful, the server restores the session using cached AAA attributes, skipping round-trips to RADIUS.

 

Reconnect Limitations

• Reconnect fails if:
  • The user manually disconnects
  • Either device reboots
  • The reconnect-timeout expires (default is 30 minutes)

 

Configuration: Enabling Auto-Reconnect and Timeout

To enable auto-reconnect in the IKEv2 profile:

crypto ikev2 profile default
authentication local rsa-sig
authentication remote eap
reconnect
reconnect timeout seconds ! Default is 1800 (30 min)

Note: Auto-reconnect cannot be used if either side is configured for pre-shared key (PSK) auth during initial IKEv2 negotiation.

 

Verifying Reconnect Status
You can validate and monitor reconnect behavior using:

show crypto session detail
show crypto ikev2 sa detail
show crypto ikev2 stats reconnect

 

Look for:

• Capability flag R (reconnect)
• Auth verify method = PSK (for reconnect phase)
• Session IDs matching the preserved session

FlexVPN’s Smart DPD and Auto-Reconnect features create a robust, high-availability VPN experience. Clients can recover quickly from disconnects, while servers intelligently maintain session state and authentication context. Together, these features minimize downtime, reduce AAA load, and enhance user transparency.

 

AnyConnect-EAP in FlexVPN: Authentication, Aggregation, and Dual-Factor Integration

Cisco FlexVPN supports AnyConnect-EAP, a proprietary EAP method designed for use between Cisco AnyConnect clients and security gateways like ASA or IOS routers running FlexVPN. This mechanism enables both user and device authentication using a flexible XML-based configuration protocol, similar in purpose to XAUTH in IKEv1, but significantly more powerful and secure in IKEv2.

 

What Is AnyConnect-EAP?

When a FlexVPN server uses AnyConnect-EAP:

• It queries the client for credentials and validates those credentials using either local AAA or RADIUS-based authentication.
• The authentication process is XML-aggregated, allowing the server to receive multiple credentials in a structured format.
• This is similar to XAUTH, but designed for IKEv2 and better suited to modern credential handling.

 

For local AAA, credentials are provisioned on the router with:

username name-string password password-string

 

Configuration Overview

In IKEv2, AnyConnect-EAP is only supported as a remote authentication method. The local method must be certificate-based:

authentication local rsa-sig
authentication remote anyconnect-eap aggregate

 

To authenticate AnyConnect-EAP credentials via RADIUS, link to a AAA method list:

aaa authentication anyconnect-eap list-name

 

You can also enable group and user authorization, and AAA accounting:

aaa authorization group anyconnect-eap
aaa authorization user anyconnect-eap
aaa accounting anyconnect-eap

The show crypto ikev2 session detail command helps confirm that AnyConnect-EAP is the authentication method in use.

 

Matching the Client IKE Identity

When using AnyConnect-EAP, clients will present an IKE identity as part of the XML payload. On the FlexVPN server, ensure this is matched using:

match identity remote key-id AnyConnect-IKE-ID

The key ID must match what’s defined in the AnyConnect XML profile.

 

Dual-Factor Authentication with AnyConnect-EAP

AnyConnect-EAP supports dual authentication, allowing both device and user validation through:

1. RFC 4739 – Multiple Authentication Exchanges in IKEv2
   This standard permits different authentication mechanisms (e.g., certificate for device, EAP for user) in one IKEv2 exchange sequence.
2. Aggregate Authentication with XML
   AnyConnect-EAP supports sending both device certificates and user credentials in a structured format, enabling layered authentication logic at the gateway.

 

Dual-Factor Configuration:

To enable dual authentication using XML aggregation and device certificate:

authentication remote anyconnect-eap aggregate cert-request

 

Also, ensure the corresponding AAA list is defined:

aaa authentication anyconnect-eap aaa-list

AnyConnect-EAP brings advanced authentication capabilities to FlexVPN, including:

• Support for both user and device authentication
• XML-driven credential aggregation for AnyConnect clients
• Compatibility with local and RADIUS AAA
• Native support for dual-factor authentication, leveraging RFC 4739 or AnyConnect’s built-in XML schema

It’s a must-have for secure enterprise deployments using AnyConnect clients with FlexVPN hubs.

 

RADIUS Attributes in FlexVPN: Local and Pushed Configuration Explained

Cisco FlexVPN supports a robust set of RADIUS AV pairs (Attribute-Value Pairs) that can either be:

• Processed locally by the FlexVPN server to configure sessions based on the peer identity
• Pushed by the server to the client during the IKEv2 configuration exchange (CFG_REPLY)

These AV pairs allow for centralized control of authentication, IP address allocation, routing, ACLs, DNS settings, and more.

 

Locally Processed RADIUS AV Pairs

These attributes are used by the FlexVPN server itself to apply session-specific settings:

Authentication Keys

• Tunnel-password=key-string: IETF attribute for symmetric PSK (pre-shared key)
• ipsec:ikev2-password-local=key-string: Cisco AV for asymmetric local PSK
• ipsec:ikev2-password-remote=key-string: Cisco AV for asymmetric remote PSK

 

IP Address Management

• Framed-Pool=pool-name: Specifies IPv4 pool for INTERNAL_IP4_ADDRESS allocation
• ipsec:ipv6-addr-pool=pool-name: Specifies IPv6 pool for INTERNAL_IP6_ADDRESS

 

DHCP Integration

• ipsec:group-dhcp-server=ipv4: Specifies DHCP server IP
• ipsec:dhcp-giaddr=ipv4: Specifies source IP used to reach DHCP server
• ipsec:dhcp-timeout=seconds: Wait time for DHCP response

 

Static Routes and Routing Policies

• ipsec:route-set=local ipv4 …: Adds static IPv4 route on the virtual-access interface
• ipsec:route-set=local ipv6 …: Adds static IPv6 route on the virtual-access interface
• ipsec:route-accept=any: Accepts routes received from peer, optionally with tag and distance

 

Interface and Flow Control

• ip:interface-config=string: Applies CLI configuration to virtual-access interface
• ipsec:ipsec-flow-limit=limit: Limits number of IPSec SAs per session (multi-SA control)

 

RADIUS Attributes Pushed to Clients

These AV pairs are dynamically sent to the IKEv2 client during configuration exchange:

IP Assignment

• Framed-IP-Address=ipv4: Assigns internal IPv4 address
• Framed-IP-Netmask=mask: Assigns subnet mask
• ipsec:prefix-len=length: IPv6 prefix length for assigned address
• ipsec:addrv6=ipv6: Assigns IPv6 address

 

Routing and Subnet Definitions

• ipsec:route-set=interface interface: Pushes route based on FlexVPN interface
• ipsec:route-set=remote ipv4 address mask: Pushes protected IPv4 subnet to client
• ipsec:route-set=remote ipv6 prefix/length: Pushes protected IPv6 subnet
• ipsec:route-set=access-list acl: Pushes protected subnets via ACL (IPv4 or IPv6)

 

DNS and WINS Configuration

• ipsec:dns-servers=ipv4 ipv4: Pushes DNS servers
• ipsec:wins-servers=ipv4 ipv4: Pushes WINS servers
• ipsec:ipv6-dns-servers-addr=ipv6 ipv6: Pushes IPv6 DNS servers

 

Client-Specific Cisco AV Pairs

These are used only when the FlexVPN server is communicating with Cisco clients such as AnyConnect or another FlexVPN peer:

• ipsec:banner=banner-text: Pushes login banner
• ipsec:default-domain=domain: Sets default DNS domain
• ipsec:split-dns=name: Defines split-DNS policy
• ipsec:backup-gateway=name: Backup VPN gateway
• ipsec:pfs=value: Perfect Forward Secrecy setting
• ipsec:include-local-lan=value: Controls local LAN access
• ipsec:smartcard-removal-disconnect=value: Enforces disconnect on smartcard removal
• ipsec:configuration-url=url: Configuration script source
• ipsec:configuration-version=version: Pushes configuration version to client

 

Example Usage in IKEv2 Authorization Policies

RADIUS attributes are tied into IKEv2 using commands like:

pool pool-name
dhcp server 10.1.1.1
dhcp timeout 10
route set access-list acl_vpn
dns 8.8.8.8 8.8.4.4
wins 192.168.1.100 192.168.1.101

These map directly to AV pairs provided via RADIUS, reducing the need for local config and enabling scalable, dynamic per-user policy control.

FlexVPN’s RADIUS support, spanning both locally consumed and dynamically pushed AV pairs, offers an unparalleled level of flexibility and control for IKEv2 sessions. From IP allocation and route injection to DNS and device behavior enforcement, these attributes form the backbone of any large-scale, centrally-managed VPN deployment.