Chapter 9. FlexVPN Server
This chapter introduces the Cisco IOS FlexVPN server. The FlexVPN server acts as a VPN headend for the remote-access and hub-spoke VPN topologies. The FlexVPN server leverages the IKEv2 configuration and the FlexVPN building blocks discussed in the earlier chapters. It dynamically instantiates a point-to-point tunnel interface for every peer session and leverages AAA to support EAP authentication, AAA-based pre-shared keys, session accounting, and for authorization to derive session policy attributes that are sent to the peer via configuration exchange and/or applied on the session interface. The chapter discusses the features that are relevant to FlexVPN server.
The chapter covers the following main topics
Per session interface creation
Auto detection of tunnel transport and encapsulation
RADIUS change of authorization
User authentication using AnyConnect-EAP
Dual-factor authentication using AnyConnect-EAP
RADIUS attributes supported by the FlexVPN server
Remote access clients supported by the FlexVPN server
Sequence of Events
Figure 9-1 illustrates the high-level sequence of events on FlexVPN server. Understanding the sequence of events helps one better understand the various features and troubleshoot any issues related to the FlexVPN server.
A high-level description of the sequence of events on the FlexVPN server follows:
1. After successful peer authentication, the configured authorizations are performed, based on the authenticated peer identity, and the attributes from the various authorization types are merged. If the group or user authorization fails, the session is terminated.
2. If the CFG_REQUEST payload is received, it is then processed to specifically check whether the peer has requested an IPv4 and/or IPv6 address. Either IPv4/IPv6 address or both addresses are allocated from the merged authorization attributes, depending on whether the IPsec session being negotiated is single or dual stacked. If the required addresses cannot be allocated, the session is terminated.
3. The virtual-access interface (P2P tunnel interface) is then instantiated for the incoming session, from the virtual-template configured in the IKEv2 profile. The configuration for the virtual-access interface is cloned from the virtual-template and from the AAA authorization attributes (interface-config attributes) as configured.
4. The incoming IPsec Security Association proposal is then processed, and if the proposal is acceptable, the IPsec Security Association is attached to the virtual-access interface and installed in the crypto engine and the data plane.
5. The CFG_REPLY payload is then constructed from the merged authorization attributes if the CFG_REQUEST payload was received.
EAP Authentication
The FlexVPN server supports EAP only as a remote authentication method, using an external EAP server, and does not support EAP as a local authentication method. In EAP terminology, the FlexVPN server acts a pass-through authenticator that relays EAP messages between an EAP server and the IKEv2 clients that, in turn, act as EAP supplicants/peers. When authenticating IKEv2 clients using EAP, the FlexVPN server must authenticate, using a certificate-based authentication method.
Figure 9-2 illustrates the use of EAP authentication in IKEv2 with the FlexVPN server. The FlexVPN server first authenticates, using a certificate-based method after which the IKEv2 client authenticates, using EAP. The IKEv2 client and the FlexVPN server then perform mutual authentication with the pre-shared key method, using the EAP shared secret if available or the Diffie-Hellman shared key-based SK_pi, and SK_pr as the pre-shared key.
EAP Methods
FlexVPN server acts a pass-through authenticator. Thus, the EAP method negotiated and used between the IKEv2 client and the EAP server for authentication is transparent to the FlexVPN server. There are two types of EAP methods that are relevant to IKEv2 EAP authentication: key-generating methods and non key-generating methods.
The key-generating EAP methods create a shared key known as master session key (MSK) as a side effect of authentication. After successful authentication, the EAP server communicates this MSK to the FlexVPN server. The IKEv2 client and the FlexVPN server use this EAP shared secret (MSK) as a pre-shared key to authenticate each other in the final IKE_AUTH exchange.
The non key-generating EAP methods do not create a shared key as part of EAP authentication. In this case, the IKEv2 client and the FlexVPN server use SK_pi and SK_pr derived from the Diffie-Hellman shared secret as a pre-shared key to authenticate each other in the final IKE_AUTH exchange.
Note that the use of non key-generating EAP methods is not recommended as they are susceptible to man-in-the-middle attacks.
The EAP methods that use transport layer security (TLS), such as EAP-TLS or EAP-TTLS, will use additional cryptographic processing in addition to the cryptographic processing for IKEv2. EAP tunneled methods, such as EAP-TLS and EAP-PEAP, incur more processing than nontunneled methods.
EAP Message Flow
Figure 9-3 illustrates the EAP message flow between an IKEv2 client, the FlexVPN server, and the RADIUS-based EAP server.
The EAP messages between the IKEv2 client and the FlexVPN server are embedded within the IKEv2 EAP payload and are carried in the IKE_AUTH request and response messages.
The EAP messages between the FlexVPN server and the RADIUS-based EAP server are embedded within the RADIUS EAP-Message attribute and are carried in the RADIUS Access-Request, Access-Challenge, and Access-Accept messages.
The FlexVPN server, acting as EAP authenticator, relays the EAP messages between the IKEv2 client and the EAP server by translating between the IKEv2 EAP payload and the RADIUS EAP-Message attribute.
The EAP server uses EAP-Request message to request information from the IKEv2 client (EAP supplicant), and the IKEv2 client uses EAP-Response message to provide the requested information.
The EAP server uses EAP-Success/EAP-Failure messages to convey the authentication result.
EAP Identity
Figure 9-4 illustrates the EAP identity that the FlexVPN server uses for EAP authentication and subsequent user and group authorization.
The FlexVPN server allows for querying EAP identity from the IKEv2 client, which is enabled using the query-identity configuration option. With the query-identity option, the FlexVPN server sends an EAP-Request message to the IKEv2 client, requesting the EAP identity. When the IKEv2 client sends an EAP-Response with its EAP identity, the FlexVPN server relays this EAP identity to the EAP server to kick off the EAP authentication. Note that some IKEv2 clients, such as AnyConnect and Microsoft Windows IKEv2 client, expect an EAP-identity request before any other EAP request. Thus, they require that the query-identity option be configured on the FlexVPN server.
When the query-identity configuration option is not enabled, FlexVPN server uses the peer IKE identity as EAP identity and relays it to the EAP server. However, the peer IKE identity of type IP address is not supported as an EAP identity, and the negotiation is terminated if the peer IKE identity is of type IP address and the query-identity option is not enabled.
After successful EAP authentication, the authenticated EAP identity returned by the EAP server, along with the EAP success message, is used to derive the AAA username for user and group authorizations. It should be noted that in some circumstances, the identity returned in the Access-Accept message will be different to that sent in the EAP exchange.
EAP Timeout
Depending on the EAP method, EAP authentication might involve prompting the user on the IKEv2 client side to enter EAP credentials of username and password. This can cause the IKEv2 client to take longer to respond to EAP request messages from the FlexVPN server, compared to other protocol exchanges. The FlexVPN server allows defining the duration for which FlexVPN server will wait for EAP-Response from the IKEv2 client before timing out and aborting the negotiation. This timeout value is configured using timeout option in the EAP authentication configuration in the IKEv2 profile. Figure 9-5 illustrates EAP timeout.
EAP Authentication Steps
Figure 9-6 illustrates the detailed steps involved when the FlexVPN server authenticates IKEv2 clients, using EAP with a RADIUS-based external EAP server.
The following is a description of the steps involved.
The IKEv2 client indicates its intent to authenticate, using EAP, by leaving out the AUTH payload in the IKE_AUTH request.
If the FlexVPN server is configured to authenticate this client, using the EAP method with the query-identity option, the FlexVPN server sends an EAP-Request message to the IKEv2 client, requesting the EAP identity. On receiving the EAP identity from the IKEv2 client, FlexVPN server relays the EAP identity to the EAP server in an EAP-Response message.
If the FlexVPN server is configured to authenticate this client, using an EAP method, but the query-identity option is not configured, the FlexVPN server relays the peer IKE identity as EAP identity to the EAP server in an EAP-Response message.
The EAP server and the IKEv2 client then use EAP-Request and EAP-Response messages to exchange information, to negotiate the EAP method and to perform the method-specific authentication exchanges. The FlexVPN server relays the EAP-Request and EAP-Response messages between them. Note that the IDr, CERT and AUTH payloads would be sent only in the first IKE_AUTH response.
The EAP server uses EAP-Success/EAP-Failure messages to convey the authentication result. If the EAP authentication is successful, the EAP server communicates the authenticated EAP identity and the master session key (MSK)-shared secret if a key-generating EAP method was used.
The MSK is used to substitute the pre-shared key in computing the AUTH payload used in the final IKE_AUTH messages between the IKEv2 client and the FlexVPN server. In the absence of MSK, the SK_pi and SK_pr values derived from the Diffie-Hellman shared secret are used to substitute the pre-shared key.
The authenticated EAP identity is used to derive the AAA username for user and group authorizations.
If the EAP authentication is successful, the RADIUS server also pushes the policy attributes corresponding to the authenticated identity. These attributes can be configured to be cached and used, which is known as implicit authorization.
Configuring EAP
The following example illustrates configuring EAP as a remote authentication method on the FlexVPN server using a RADIUS-based external EAP server. EAP is configured in the IKEv2 profile.
In order to configure EAP as a remote authentication method, the local authentication method must be certificate-based.
Router(config-ikev2-profile)#authentication remote eap
For remote auth method to be EAP, the local auth method must be certificate-based
Router(config-ikev2-profile)#authentication local rsa-sig
Router(config-ikev2-profile)#authentication remote eap
The query-identity option makes the FlexVPN server query the EAP identity from the IKEv2 client and relay it to the EAP server.
Router(config-ikev2-profile)#authentication remote eap ?
query-identity query EAP identity from peer
timeout timeout
<cr>
The timeout option defines the duration for which the FlexVPN server will wait for an EAP-Response from the IKEv2 client after sending the EAP-Request, before timing out. The default timeout is 90 seconds.
Router(config-ikev2-profile)#authentication remote eap timeout ?
<45-180> EAP authentication timeout in seconds
The AAA method list specifying the RADIUS server to use for EAP authentication is configured using the below command.
Router(config-ikev2-profile)#aaa authentication eap ?
WORD AAA list name
EAP Configuration Example
The following example illustrates sample EAP configuration and logs on the FlexVPN server for EAP as a remote authentication method using a RADIUS-based external EAP server
Step 1. Enable AAA.
aaa new-model
Step 2. Define the AAA authentication method list to specify the RADIUS server hosting the EAP server.
aaa authentication login authen_list_radius group radius_group
Step 3. Define the RADIUS server group.
aaa group server radius radius_group
server name radius_server
Step 4. Define the RADIUS server.
radius server radius_server
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_key
Step 5. Configure EAP authentication in the IKEv2 profile.
crypto ikev2 profile ikev2_profile
aaa authentication eap authen_list_radius
authentication remote eap query-identity
authentication remote eap timeout 120
authentication remote rsa-sig
aaa authentication eap authen_list_radius
The following debug crypto ikev2, debug crypto ikev2 internal, debug radius authentication logs capture EAP message exchanges between the IKEv2 client and EAP server through FlexVPN server. The relevant logs are highlighted.
IKEv2 client skips AUTH payload in IKE_AUTH request to indicate intent to authenticate using EAP.
IKEv2:(SESSION ID = 69,SA ID = 1):Received Packet [From 172.16.1.1:59040/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
Payload contents:
IKEv2-INTERNAL:Parse Vendor Specific Payload: (CUSTOM) VID IDi CERTREQ CFG SA
The FlexVPN server sends AUTH payload in the IKE_AUTH response to authenticate itself. As the query-identity option is configured, the FlexVPN server also includes EAP-Request in the IKE_AUTH response to request the EAP identity.
IKEv2:(SESSION ID = 69,SA ID = 1):Generating EAP request
IKEv2:(SESSION ID = 69,SA ID = 1):Building packet for encryption.
Payload contents:
VID IDr CERT CERT AUTH EAP
IKEv2:(SESSION ID = 69,SA ID = 1):Sending Packet [To 172.16.1.1:59040/From
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
IKEv2 client sends its EAP identity in EAP-Response message in the IKE_AUTH request message.
IKEv2:(SESSION ID = 69,SA ID = 1):Received Packet [From 172.16.1.1:59040/To
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 2
IKEv2 IKE_AUTH Exchange REQUEST
Payload contents:
EAP
IKEv2:(SESSION ID = 69,SA ID = 1):Processing EAP response
IKEv2:Use authen method list TEST
IKEv2:pre-AAA: client sent User1 as EAP-Id response
The FlexVPN server kicks off EAP authentication by sending the IKEv2 client’s EAP identity to the EAP server as an EAP-Response in RADIUS Access-Request message.
IKEv2:sending User1 [EAP-Id] as username to AAA
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authentication request sent
RADIUS(00000049): Send Access-Request to 172.16.1.3:1812 id 1645/36, len 196
RADIUS: authenticator 5A 04 CC CF DA 86 4C D3 - 4E B8 8A F3 75 47 52 81
RADIUS: Service-Type [6] 6 Login [1]
RADIUS: Vendor, Cisco [26] 26
RADIUS: Cisco AVpair [1] 20 "service-type=Login"
RADIUS: Vendor, Cisco [26] 28
RADIUS: Cisco AVpair [1] 22 "isakmp-phase1-id=router1"
RADIUS: Calling-Station-Id [31] 16 "172.16.1.2"
RADIUS: Vendor, Cisco [26] 63
RADIUS: Cisco AVpair [1] 57 "audit-session-
id=L2L40A683111ZO2L40A6869A2ZH1194E6AZO45"
RADIUS: User-Name [1] 4 "User1"
RADIUS: EAP-Message [79] 9
RADIUS: 02 3B 00 07 01 70 31 [ ;User1]
RADIUS: Message-Authenticato[80] 18
RADIUS: 41 41 1E 2B 3B B9 4A 55 F0 1C 04 0A D4 60 62 86 [ AA+;JU`b]
RADIUS: NAS-IP-Address [4] 6 10.104.49.17
The RADIUS server sends an EAP-Request in an Access-Challenge message, and the FlexVPN server relays it to the IKEv2 client in an IKE_AUTH response message.
RADIUS: Received from id 1645/36 172.16.1.3:1812, Access-Challenge, len 1159
RADIUS: authenticator 52 73 15 7B 6F A2 46 38 - 7D 6B EB 3D 81 88 71 D0
RADIUS: Service-Type [6] 6 NAS Prompt [7]
RADIUS: EAP-Message [79] 24
IKEv2:(SESSION ID = 69,SA ID = 1):Generating EAP request
IKEv2:(SESSION ID = 69,SA ID = 1):Building packet for encryption.
Payload contents:
EAP
IKEv2:(SESSION ID = 69,SA ID = 1):Sending Packet [To 172.16.1.1:59040/From
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 2
IKEv2 IKE_AUTH Exchange RESPONSE
IKEv2 client sends an EAP-Response message in the IKE_AUTH request message, and the FlexVPN server relays it to the RADIUS server in an Access-Request message.
IKEv2:(SESSION ID = 69,SA ID = 1):Received Packet [From 172.16.1.1:59040/To
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 3
IKEv2 IKE_AUTH Exchange REQUEST
Payload contents:
EAP
RADIUS(00000049): Send Access-Request to 172.16.1.3:1812 id 1645/37, len 229
RADIUS: authenticator 3B 58 59 F2 D3 AC F8 18 - 5C E8 6C C2 A9 BD 1B B9
RADIUS: Service-Type [6] 6 Login [1]
RADIUS: Vendor, Cisco [26] 26
RADIUS: Cisco AVpair [1] 20 "service-type=Login"
RADIUS: Vendor, Cisco [26] 28
RADIUS: Cisco AVpair [1] 22 "isakmp-phase1-id=router1"
RADIUS: Calling-Station-Id [31] 16 "172.16.1.2"
RADIUS: Vendor, Cisco [26] 63
RADIUS: Cisco AVpair [1] 57 "audit-session-
id=L2L40A683111ZO2L40A6869A2ZH1194E6AZO45"
RADIUS: User-Name [1] 4 "User1"
RADIUS: EAP-Message [79] 24
The RADIUS server sends the EAP authentication status in an Access-Accept message, and the FlexVPN server relays it to the IKEv2 client in an IKE_AUTH response message.
RADIUS: Received from id 1645/37 172.16.1.3:1812, Access-Accept, len 1127
RADIUS: authenticator 7B 7A B6 8B 64 E1 2D 03 - 86 74 B9 21 39 A7 1B FB
RADIUS: Service-Type [6] 6 NAS Prompt [7]
RADIUS: EAP-Message [79] 6
IKEv2:(SESSION ID = 69,SA ID = 1):Sending EAP status message
IKEv2:(SESSION ID = 69,SA ID = 1):Building packet for encryption.
Payload contents:
EAP
IKEv2:(SESSION ID = 69,SA ID = 1):Sending Packet [To 172.16.1.1:59040/From
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 3
IKEv2 IKE_AUTH Exchange RESPONSE
If the EAP authentication was successful, the IKEv2 client sends the final IKE_AUTH request message to authenticate itself to the FlexVPN server using the pre-shared key method with the EAP shared secret or SK_pi and SK_pr values as the pre-shared key.
IKEv2:(SESSION ID = 69,SA ID = 1):Received Packet [From 172.16.1.1:59040/To
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 4
IKEv2 IKE_AUTH Exchange REQUEST
Payload contents:
AUTH
The FlexVPN server, after validating the AUTH payload from the IKEv2 client, performs the rest of the processing, including user and group authorization, processing of CFG_REQUEST, virtual-access interface creation, processing of IPsec Security Association proposal, construction of CFG_REPLY and AUTH payload to authenticate itself to the IKEv2 client using the pre-shared key method with the EAP shared secret or SK_pi and SK_pr values as the pre-shared key and sends the final IKE_AUTH response message.
IKEv2:(SESSION ID = 69,SA ID = 1):Building packet for encryption.
Payload contents:
AUTH CFG SA TSi TSr NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT)
NOTIFY(NON_FIRST_FRAGS)
IKEv2:(SESSION ID = 69,SA ID = 1):Sending Packet [To 172.16.1.1:59040/From
172.16.1.2:4500/VRF i0:f0]
Initiator SPI : 3A1C6331D3A4726E - Responder SPI : 123A08C78505C625 Message id: 4
IKEv2 IKE_AUTH Exchange RESPONSE
Payload contents:
ENCR
The show crypto ikev2 sa detail command displays the local and remote authentication methods and the peer’s authenticated EAP identity.
Router#show crypto ikev2 sa detail
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 172.16.1.2/4500 172.16.1.2/59040 none/none READY
Encr: 3DES, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: RSA, Auth verify: EAP
Life/Active Time: 900/21 sec
CE id: 1028, Session-id: 22
Status Description: Negotiation done
Local spi: 123A08C78505C625 Remote spi: 3A1C6331D3A4726E
Local id: 172.16.1.2
Remote id: router1
Remote EAP id: User1
The following XML configuration for AnyConnect can be used to create a profile for EAP-MSCHAPv2 to connect to a headend with the FQDN of vpn1.cisco.com. With regard to the headend certificate, if a subject alternative name (SAN) extension is present with relevant attributes, name verification is performed solely against the SAN. Relevant attributes include DNS name attributes for all certificates, and additionally include IP address attributes if the connection is being performed to an IP address. If a subject alternative name extension is not present, or is present but contains no relevant attributes, name verification is performed against any common name (CN) attributes found in the subject of the certificate. This identity must be configured as vpn1.cisco.com.
<ServerList>
<HostEntry>
<HostName>vpn1.cisco.com</HostName>
<HostAddress>vpn1.cisco.com</HostAddress>
<PrimaryProtocol>IPsec
<StandardAuthenticationOnly>true
<AuthMethodDuringIKENegotiation>EAP-MSCHAPv2</
AuthMethodDuringIKENegotiation>
<IKEIdentity>cisco.com</IKEIdentity>
</StandardAuthenticationOnly>
</PrimaryProtocol>
</HostEntry>
</ServerList>
The following XML configuration for AnyConnect can be used to create a profile for EAP-MD5 to connect to a headend with the FQDN of vpn2.cisco.com. Note that the identity contained in the headend certificate must be vpn2.cisco.com.
<ServerList>
<HostEntry>
<HostName>vpn2.cisco.com</HostName>
<HostAddress>vpn2.cisco.com</HostAddress>
<PrimaryProtocol>IPsec
<StandardAuthenticationOnly>true
<AuthMethodDuringIKENegotiation>EAP-MD5</AuthMethodDuringIKENegotiation>
<IKEIdentity>cisco.com</IKEIdentity>
</StandardAuthenticationOnly>
</PrimaryProtocol>
</HostEntry>
</ServerList>
AAA-based Pre-shared Keys
FlexVPN server supports hosting of symmetric and asymmetric pre-shared keys on an external AAA server, such as a RADIUS server for scalable management of pre-shared keys, which is useful when the pre-shared key method is used for local and/or remote authentication with a large number of IKEv2 initiators. The FlexVPN server uses AAA authorization to retrieve the pre-shared keys corresponding to a peer from the RADIUS server.
The pre-shared key lookup on the AAA server is based on the peer IKE identity. An IKEv2 name mangler can optionally be used to derive the AAA username from the peer IKE identity for pre-shared key lookup. Figure 9-7 illustrates retrieving pre-shared keys from the RADIUS server.
Configuring AAA-based Pre-Shared Keys
Step 1. The AAA-based pre-shared key configuration is defined in the IKEv2 profile using the following command.
Router(config-ikev2-profile)#keyring ?
aaa AAA-based keyring
local Local keyring
Step 2. Specify the AAA authorization method list that specifies the AAA server hosting the keys.
Router(config-ikev2-profile)#keyring aaa ?
WORD AAA list name
Step 3. Specify an IKEv2 name mangler to derive the AAA username from the peer IKE identity for the key lookup. If not specified, the entire peer IKE identity is used as AAA username for the key lookup.
Router(config-ikev2-profile)#keyring aaa aaa_psk_list ?
name-mangler Specify the name-mangler to derive username
password Specify the AAA password
<cr>
RADIUS Attributes for AAA-Based Pre-Shared Keys
Following are the standard and the Cisco proprietary RADIUS attributes known as Cisco attribute-value(AV) pairs that are used to hold the symmetric and asymmetric pre-shared keys.
The Tunnel-Password IETF attribute is used to hold the symmetric pre-shared key string.
The IKEv2-password-local Cisco AV pair is used to hold the local pre-shared key that is used for local authentication, that is, used by the FlexVPN server to authenticate to the IKEv2 initiators (to generate the AUTH payload).
The IKEv2-password-remote Cisco AV pair is used to hold the remote pre-shared key that is used for remote authentication, that is, used by the FlexVPN server to authenticate the IKEv2 initiators (to verify the peer’s AUTH payload).
AAA-based pre-shared keys allow for the ability to obtain additional attributes via RADIUS within the authentication phase to then be cached and used for implicit authorization. The ability to cache the attributes and reduce the RADIUS exchanges allows for an increase in the amount of tunnel setups that can occur at any given time.
AAA-Based Pre-Shared Keys Example
The following example illustrates sample configuration and logs on FlexVPN server for AAA-based pre-shared keys. In addition to pre-shared keys, any other policy attributes returned by the AAA server corresponding to the username used for pre-shared key lookup are cached and used as user authorization policy attributes when the aaa authorization user command with cached option is configured. This is known as implicit authorization. When the cached option is not configured, these policy parameters are ignored.
Step 1. Enable AAA.
aaa new-model
Step 2. Define the AAA authorization method list to specify the RADIUS server hosting the pre-shared keys.
aaa authorization network aaa_list1 group radius_group1
Step 3. Define the RADIUS server group.
aaa group server radius radius_group
server name radius_server
Step 4. Define the RADIUS server.
radius server radius_server
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_key
Step 5. Define IKEv2 name mangler.
crypto ikev2 name-mangler name_mangler1
fqdn hostname
Step 6. Configure AAA-based pre-shared keys in the 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
The following debug crypto ikev2, debug crypto ikev2 internal, and debug radius authentication logs capture exchanges between the FlexVPN server and the RADIUS server to retrieve the pre-shared keys. The relevant debug outputs are highlighted.
Note that the peer is authenticating using the pre-shared key method and is using an IKE identity of type FQDN with value ‘router1.domain1’.
IKEv2:(SESSION ID = 3,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 80753858A6D0BEAB - Responder SPI : EA3464A2957A6F65 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:(SESSION ID = 3,SA ID = 1):Searching policy based on peer's identity
'router1.domain1' of type 'FQDN'
IKEv2:(SESSION ID = 3,SA ID = 1):Peer's authentication method is 'PSK'
FlexVPN server initiates an AAA authorization request to retrieve pre-shared keys from the AAA server.
IKEv2:(SESSION ID = 3,SA ID = 1):Get peer's preshared key for router1.domain1
IKEv2-INTERNAL:Fetching shared secret from AAA
IKEv2-INTERNAL:Name-mangler 'name_mangler1' returning mangled-name 'router1'
for name-type 1, name-len 15, name_string router1.domain1
IKEv2-INTERNAL: Using AAA method list aaa_list1 for peer router1
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Password request sent
AAA SRV(0000000E): process author req
AAA SRV(0000000E): Author method=SERVER_GROUP radius_group1
RADIUS/ENCODE: Best Local IP-Address 172.16.1.2 for Radius-Server 172.16.1.3
RADIUS(0000000E): Send Access-Request to 172.16.1.3:1645 id 1645/2, len 131
RADIUS: authenticator 11 DD F2 16 3C 32 7A 9F - 26 6E AA DA 92 8D 99 8D
RADIUS: User-Name [1] 9 "router1"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 60
RADIUS: Cisco AVpair [1] 54 "audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZO3"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS(0000000E): Sending a IPv4 Radius Packet
RADIUS(0000000E): Started 5 sec timeout
RADIUS server returns the corresponding pre-shared keys.
RADIUS: Received from id 1645/2 172.16.1.3:1645, Access-Accept, len 172
RADIUS: authenticator B0 26 56 33 0F 1D 11 07 - A2 BE 8F 63 DD 71 DB B1
RADIUS: Vendor, Cisco [26] 33
RADIUS: Cisco AVpair [1] 27 "ipsec:route-set=interface"
RADIUS: Vendor, Cisco [26] 30
RADIUS: Cisco AVpair [1] 24 "ipsec:route-accept=any"
RADIUS: Vendor, Cisco [26] 45
RADIUS: Cisco AVpair [1] 39 "ipsec:route-set=prefix 192.168.1.1/24"
RADIUS: Vendor, Cisco [26] 44
RADIUS: Cisco AVpair [1] 38 "ipsec:tunnel-password=pre_shared_key"
RADIUS(0000000E): Received from id 1645/2
AAA SRV(0000000E): protocol reply PASS for Authorization
AAA SRV(0000000E): Return Authorization status=PASS
Note that along with the pre-shared key, other policy attributes are also received from the AAA server.
IKEv2:(SA ID = 1):[AAA -> IKEv2] Received password response
IKEv2-INTERNAL:Received symmetric password from radius server
IKEv2-INTERNAL:Received cached attributes:
route-set-interface: 1, route-accept any tag:1 distance:1,
IKEv2:(SESSION ID = 3,SA ID = 1):Verification of peer's authentication data PASSED
Accounting
The FlexVPN server leverages AAA accounting to report the IKE/IPsec session up and down events and the session statistics such as encrypt/decrypt packet and byte count. RADIUS accounting allows for a simple method to monitor the network. RADIUS accounting is mandatory when using RADIUS to allocate IP addresses. Accounting must be enabled to ensure that IP address allocation is indicated to the server, allowing for the return of IP addresses to the pool when no longer needed. The following example illustrates FlexVPN accounting configuration and logs.
Router(config-ikev2-profile)#aaa accounting ?
anyconnect-eap AAA list to use when IKEv2 remote auth method is AnyConnect
EAP
cert AAA list to use when IKEv2 remote auth method is certificate
based
eap AAA list to use when IKEv2 remote auth method is EAP
psk AAA list to use when IKEv2 remote auth method is PSK
The accounting method list specifies the AAA server that will store the accounting records.
Router(config-ikev2-profile)#aaa accounting psk ?
WORD AAA list name
Step 1. Configure the AAA accounting method list.
aaa accounting network acc_list
action-type start-stop
group radius_group1
Step 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
The selected output from debug crypto ikev2, debug aaa accounting, and debug radius accounting logs capture the accounting start and stop record being sent to the AAA server when the IKE/IPsec session comes up and goes down.
The accounting start record is sent after sending the IKE_AUTH response and successful establishment of the IKE/IPsec session. The accounting start record includes the peer IP address, and IKE identity among other things.
IKEv2:(SESSION ID = 8,SA ID = 1):Sending Packet [To 172.16.1.1:500/From
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 0A40B2679CC0B5C2 - Responder SPI : 6833E924871B8C81 Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
Payload contents:
ENCR
IKEv2:(SESSION ID = 8,SA ID = 1):IKEV2 SA created; inserting SA into database. SA
lifetime timer (86400 sec) started
IKEv2:(SA ID = 1):[IPsec -> IKEv2] Creation of IPsec SA into IPsec database PASSED
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
AAA/ACCT/EVENT/(00000011): CALL START
AAA/ACCT/EVENT/(00000011): IPSEC TNL UP
AAA/ACCT/IPSEC-TUNNEL(00000011): Queueing record is START
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Accounting start request sent successfully
RADIUS(00000011): Send Accounting-Request to 172.16.1.3:1646 id 1646/9, len 256
RADIUS: authenticator 6A 7A 8F EA 4E 10 E9 CE - 8C C9 EC A8 C4 70 C7 9F
RADIUS: Acct-Session-Id [44] 10 "00000007"
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 60
RADIUS: Cisco AVpair [1] 54 "audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZO8"
RADIUS: Vendor, Cisco [26] 40
RADIUS: Cisco AVpair [1] 34 "isakmp-phase1-id=router1.domain1"
RADIUS: Vendor, Cisco [26] 37
RADIUS: Cisco AVpair [1] 31 "isakmp-initator-ip=172.16.1.1"
RADIUS: User-Name [1] 17 "router1.domain1"
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Acct-Status-Type [40] 6 Start [1]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS: Acct-Delay-Time [41] 6 0
The accounting stop record is sent after the IKE/IPsec session is deleted. The accounting stop record includes the peer IP address, IKE identity, and the session encrypt/decrypt packet and byte count among other things.
AAA/ACCT/EVENT/(00000011): IPSEC TNL DOWN
IKEv2:in_octets 13020, out_octets 17640
IKEv2:in_packets 105, out_packets 105
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Accounting stop request sent successfully
AAA/ACCT/EVENT/(00000011): CALL STOP
AAA/ACCT/IPSEC-TUNNEL(00000011): STOP
RADIUS(00000011): Send Accounting-Request to 172.16.1.3:1646
id 1646/10, len 324
RADIUS: authenticator 6E 18 B4 4F E0 B5 C0 09 - 9F B9 FC 01 5A D4 69 6F
RADIUS: Acct-Session-Id [44] 10 "00000007"
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 60
RADIUS: Cisco AVpair [1] 54 "audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZO8"
RADIUS: Vendor, Cisco [26] 40
RADIUS: Cisco AVpair [1] 34 "isakmp-phase1-id=router1.domain1"
RADIUS: Vendor, Cisco [26] 37
RADIUS: Cisco AVpair [1] 31 "isakmp-initator-ip=172.16.1.1"
RADIUS: User-Name [1] 17 "router1.domain1"
RADIUS: Acct-Authentic [45] 6 Local [2]
RADIUS: Vendor, Cisco [26] 36
RADIUS: Cisco AVpair [1] 30 "connect-progress=No Progress"
RADIUS: Acct-Session-Time [46] 6 34
RADIUS: Acct-Input-Octets [42] 6 13020
RADIUS: Acct-Output-Octets [43] 6 17640
RADIUS: Acct-Input-Packets [47] 6 105
RADIUS: Acct-Output-Packets [48] 6 105
RADIUS: Acct-Terminate-Cause[49] 6 none [0]
RADIUS: Vendor, Cisco [26] 32
RADIUS: Cisco AVpair [1] 26 "disc-cause-ext=No Reason"
RADIUS: Acct-Status-Type [40] 6 Stop [2]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS: Acct-Delay-Time [41] 6 0
Per-Session Interface
The FlexVPN server dynamically instantiates a point-to-point tunnel interface known as virtual-access interface for every incoming IKEv2/IPsec session. The FlexVPN server instantiates the virtual-access interface after successful peer authentication and user and group authorizations.
Figure 9-8 illustrates the sequence of events that lead to virtual-access creation. If the IKEv2 profile matched, based on the peer IKE identity, has a virtual-template configured in it, then a virtual-access interface is instantiated from that virtual-template for the peer/session.
The virtual-access interface derives its configuration from the following sources in the specified order.
1. Virtual-template interface
2. AAA authorization (optional)
3. Incoming IKE/IPsec session
Deriving Virtual-Access Configuration from a Virtual Template
The FlexVPN server uses a virtual-template interface of type tunnel to instantiate the per session virtual-access interface. A virtual-template interface of type tunnel can be configured with all the commands that can be configured on a normal tunnel interface. The virtual-access interface inherits all the commands configured on the virtual-template it is cloned from.
The following are a few exceptions while configuring a virtual-template when compared to a normal point-to-point tunnel interface on the FlexVPN server
The IP address on a virtual-template interface is configured using ip unnumbered interface and/or ipv6 unnumbered interface commands. These commands allow the virtual-template and the cloned virtual-access interfaces to borrow and reuse the IP address from the specified interface. This is required because Cisco IOS does not allow the same IP subnet to be configured with ip address and ipv6 address commands on more than one interface due to the generation of erroneous routes and the loss of IP packets.
The tunnel destination command is not configured on the virtual-template because the address of the remote peer is not known in advance. The cloned virtual-access interface derives the tunnel destination address from the source address of the incoming IKE/IPsec session.
The tunnel source command may optionally be configured on a virtual-template, and when configured, it must match the source address of the incoming IKE/IPsec session. When not configured, the cloned virtual-access interface derives the tunnel source address from the destination address of the incoming IKE/IPsec session.
The following example illustrates virtual-template configuration on a FlexVPN server. The virtual-template interface is defined in the router global configuration mode and is referenced from the IKEv2 profile.
Router(config)#interface virtual-template ?
<1-200> Virtual-Template interface number
Router(config)#interface virtual-template 1 ?
type type of the virtual-template
<cr>
Router(config)#interface virtual-template 1 type ?
ethernet Set VT type as ethernet
serial Set VT type as serial
tunnel Set VT type as tunnel
The virtual-template interface must be of type tunnel.
Router(config)#interface virtual-template 1 type tunnel ?
<cr>
The IP address on the virtual-template must be configured using the ip unnumbered and/or ipv6 unnumbered command.
Router(config)#interface virtual-template 1 type tunnel
Router(config-if)#ip unnumbered e0/0
Router(config-if)#tunnel protection ipsec profile default
The virtual template must be referenced from IKEv2 profile in order to be used for cloning virtual-access interfaces.
Router(config-ikev2-profile)#virtual-template 1
When a virtual template of type tunnel has active cloned virtual-access interfaces, the interface configuration mode cannot be entered, and hence no new commands can be added to or any exiting commands deleted from or modified. A message is displayed as highlighted below.
Router#show vtemplate 1
Virtual-access subinterface creation is globally enabled
Active Active Subint Interface
Interface Subinterface Capable Type
--------- ------------ ------- ---------
Vt1 1 0 No Tunnel
Router(config)#interface virtual-template 1 type tunnel
% Virtual-template config is locked, active vaccess present
Router(config)#
Note that when the virtual-template has no active virtual-access interfaces, the interface configuration mode can be entered, and commands can be added, deleted, or modified.
Router#show vtemplate 1
Virtual-access subinterface creation is globally enabled
Active Active Subint Interface
Interface Subinterface Capable Type
--------- ------------ ------- ---------
Vt1 0 0 No Tunnel
Router(config)#interface virtual-template 1 type tunnel
Router(config-if)#
Deriving Virtual-Access Configuration from AAA Authorization
The virtual-access interface configuration can be hosted on an external AAA server and retrieved, using AAA authorization based on the peer IKE identity. This allows for scalable management of per-peer virtual-access configuration when the FlexVPN server needs to cater to a large number of IKEv2 initiators, with each requiring unique configuration such as VRF, access control list, QoS policy, firewall policy, IP MTU, and so on. A key benefit of AAA-based configuration is that it allows for cloning of virtual-access interfaces from a common virtual-template configured in a common IKEv2 profile for multiple peers while still being able to have per-peer configuration for each virtual-access interface. Without AAA-based configuration, per-peer configuration for each virtual-access requires a unique virtual-template configured in a unique IKEv2 profile per peer, which is not scalable.
The interface-config AAA Attribute
The AAA-based virtual-access configuration is accomplished using the Cisco proprietary interface-config AAA attribute of type string whose value can be applied as a command string on a virtual-access interface. The interface-config attribute is configured as a Cisco VSA (vendor-specific attribute) on a RADIUS server. For local AAA, the interface-config attribute can be configured, using an AAA attribute list referenced from the IKEv2 authorization policy. The interface-config attribute value is treated as an interface configuration mode command string and is applied to the virtual-access interface without any validation. Therefore, it must be ensured that the interface-config attribute is configured with a valid command string. Multiple interface-config attributes can be configured on the RADIUS server or the local AAA attribute list, one for each command.
The interface-config attribute values from the various authorization types are applied to the virtual-access interface in the following order.
1. Group authorization
2. Implicit authorization
3. User authorization
If the group authorization is configured to take precedence over user authorization, using the aaa authorization group override command, the interface-config attribute values are applied to the virtual-access interface in the following order.
1. Implicit authorization
2. User authorization
3. Group authorization
Note that in case of duplicate interface-config attributes, that is, the same interface command obtained from more than one authorization type, the one applied later will overwrite the previous. However, commands such as “service-policy” that require the existing command be removed before applying a new one, would not overwrite the previous command.
Deriving Virtual-Access Configuration from an Incoming Session
After the virtual-access interface is cloned from virtual-template and the interface-config attributes from AAA are applied, the following configuration is derived from the incoming IKE/IPsec session.
The tunnel destination configuration is derived from the source address of the incoming IKE/IPsec session. Note that this is dynamic information and is not known in advance.
The tunnel source configuration is derived from the destination address of the incoming IKE/IPsec session if the virtual-access interface is not already configured with the tunnel source command derived either from virtual-template or AAA.
If the auto-detection of tunnel encapsulation protocol and the transport IP address family is enabled, using the virtual-template number mode auto in the IKEv2 profile, the tunnel mode configuration on the virtual-access interface is derived from the IPsec Security Association traffic selector protocol, and the IP address family used by the incoming IKE/IPsec session.
Virtual-Access Cloning Example
The following example illustrates the configuration and logs for virtual-access cloning from virtual-template and AAA authorizations. The example uses RADIUS server for user authorization and local AAA for group authorization.
Step 1. Define the AAA authorization method lists to specify the RADIUS server and the local AAA database hosting the per-peer virtual-access interface configuration.
aaa authorization network default local
aaa authorization network aaa_list1 group radius_group1
Step 2. Define the IKEv2 name mangler to derive AAA username for user and group authorizations.
crypto ikev2 name-mangler name_mangler1
fqdn hostname
crypto ikev2 name-mangler name_mangler2
fqdn domain
Step 3. Define the AAA attribute list and the IKEv2 authorization policy that is used with group authorization in this example. The AAA attribute list is referenced from the authorization policy. Note the interface-config attributes defined under the AAA attribute list as highlighted below.
aaa attribute list attr_list1
attribute type interface-config "tunnel key 1"
attribute type interface-config "ip mtu 1000"
crypto ikev2 authorization policy domain1
aaa attribute list attr_list1
Step 4. Configure user and group authorizations 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 name-mangler name_mangler2
aaa authorization user psk list aaa_list1 name-mangler name_mangler1
virtual-template 1
Step 5. Define the virtual-template interface of type tunnel. Note that the virtual-template is referenced from the IKEv2 profile.
interface Virtual-Template1 type tunnel
ip unnumbered Ethernet0/0
tunnel protection ipsec profile default
The selected output from debug crypto ikev2, debug aaa per-user, and debug vtemplate cloning logs captures the cloning of virtual-access interface from the virtual-template and the application of interface-config attributes from user and group authorizations to the virtual-access interface.
Virtual-access interface is cloned from virtual-template1.
VT[Vi1]:Clone Vaccess from Virtual-Template1 (45 bytes)
VT[Vi1]:tunnel protection ipsec profile default
VT[Vi1]:end
The interface-config attribute values from the group authorization are applied to the virtual-access interface.
INFO: AAA/AUTHOR: Processing PerUser AV interface-config
INFO: AAA/AUTHOR: Processing PerUser AV interface-config
VT[Vi1]:Clone Vaccess from AAA (30 bytes)
VT[Vi1]:tunnel key 1
VT[Vi1]:ip mtu 1000
VT[Vi1]:end
The interface-config attribute values from the user authorization are applied to the virtual-access interface. Note that the same commands are received from group and user authorization. The commands from user authorization that are applied later overwrite the ones from group authorization applied earlier. Be aware of the order that commands are applied; these must be in the same order as commands are applied when manually configuring an interface. For example if an interface is to be placed into a VRF, using the ip vrf forwarding command, this must occur prior to the IP address of the interface being configured using the ip address command. If commands are not applied in the correct order, then one command can remove configuration applied by a previous command. Also, commands such as “service-policy” that require the existing command be removed before applying a new one would not overwrite the existing command.
INFO: AAA/AUTHOR: Processing PerUser AV interface-config
INFO: AAA/AUTHOR: Processing PerUser AV interface-config
VT[Vi1]:Clone Vaccess from AAA (30 bytes)
VT[Vi1]:ip mtu 1200
VT[Vi1]:tunnel key 2
VT[Vi1]:end
The crypto session is associated with virtual-access1.
Router2#show crypto session
Crypto session current status
Interface: Virtual-Access1
Profile: default
Session status: UP-ACTIVE
Peer: 172.16.1.1 port 500
Session ID: 28
IKEv2 SA: local 172.16.1.2/500 remote 172.16.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.16.1.1
Active SAs: 2, origin: crypto-map
The configuration on the virtual-access interface is derived from the virtual-template interface, AAA authorizations, and the IKE/IPsec session. Note that the tunnel destination and source are derived from the session.
Router2#show derived-config interface virtual-access 1
Building configuration...
Derived configuration : 222 bytes
interface Virtual-Access1
ip unnumbered Ethernet0/0
ip mtu 1200
tunnel source 172.16.1.2
tunnel destination 172.16.1.1
tunnel key 2
tunnel protection ipsec profile default
no tunnel protection ipsec initiate
end
Auto Detection of Tunnel Transport and Encapsulation
The FlexVPN server supports automatic detection of tunnel encapsulation mode and transport IP protocol type in order to support initiators that use multiple encapsulation modes and transport IP types that use a single virtual-template interface and an IKEv2 profile. The auto-detect mode is enabled using the virtual-template number mode auto command in the IKEv2 profile that overrides the tunnel mode configuration derived from the virtual-template or AAA authorization. The cloned virtual-access interfaces instead derive the tunnel mode configuration from the IPsec Security Association traffic selector protocol and the IP address family used by the incoming IKE/IPsec session. The following example illustrates the configuration and logs for tunnel auto-mode. The debug crypto ipsec output and the show command outputs below illustrate that the tunnel encapsulation protocol and the transport IP protocol type and therefore, the tunnel mode command on the virtual-access interface is derived from the incoming IPsec Security Association proposal with protocol Encapsulation Security Payload overriding the configuration cloned from the virtual-template.
IKEv2 profile with auto mode enabled.
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
Virtual-template with encapsulation protocol GRE and transport IPv4:
Router#show interfaces virtual-template 1 | inc protocol/transport
Tunnel protocol/transport GRE/IP
IPsec proposal from peer with protocol as any:
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 172.16.1.2:0, remote= 172.16.1.1:0,
local_proxy= 0.0.0.0/0.0.0.0/256/0,
remote_proxy= 0.0.0.0/0.0.0.0/256/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
Virtual-access with encapsulation protocol Encapsulation Security Payload and transport IPv4:
Router#show interfaces virtual-access 1 | inc protocol/transport
Tunnel protocol/transport IPSEC/IP
Following is another example where the virtual-template is configured with tunnel mode ipsec while the peer proposes protocol GRE.
Router#show interfaces virtual-template 1 | inc protocol/transport
Tunnel protocol/transport IPSEC/IP
IPsec proposal from peer with protocol as GRE.
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 172.16.1.2:0, remote= 172.16.1.1:0,
local_proxy= 172.16.1.2/255.255.255.255/47/0,
remote_proxy= 172.16.1.1/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes esp-sha-hmac (Transport),
Router#show interfaces virtual-access 1 | inc protocol/transport
Tunnel protocol/transport GRE/IP
RADIUS Packet of Disconnect
RFC 5716, Dynamic Authorization Extensions to RADIUS, defines a way to delete the sessions and to change the authorization attributes associated with the sessions on the Network Access Server (NAS) initiated from the RADIUS server. The disconnect-request (also known as Packet-of-Disconnect, or PoD) message is used to delete a session and the change-of-authorization (CoA) message is used to change the authorization attributes associated with a session. The entity originating the unsolicited PoD/CoA request is known as the dynamic authorization client (DAC) and is typically co-resident with the RADIUS server. The NAS (FlexVPN server in this case) that processes the PoD/CoA messages is known as the dynamic authorization server (DAS). The PoD/CoA messages are sent to UDP port 3799 and are independent of the RADIUS Access-Request/Response, Access-Challenge, and Access-Accept/Reject messages.
The FlexVPN server supports the RADIUS packet of disconnect feature that allows deletion of an IKE/IPsec session through the unsolicited PoD message from the RADIUS server as illustrated in the Figure 9-9. The FlexVPN server currently supports only the audit-session-id Cisco AV pair in the PoD message to identify the session to be deleted. The FlexVPN server returns Disconnect-ACK after successfully deleting the specified session and returns Disconnect-NACK if session is not found.
The audit-session-id to be used in the PoD message to identify the session to be deleted can be obtained from the debug and show command outputs on the FlexVPN server. The FlexVPN server sends the audit-session-id Cisco AV pair attribute in all the AAA authentication, authorization, and accounting requests and can be seen in the debug radius authentication and debug radius accounting output, and can also be seen using the show aaa user command.
Following are some of the use cases of PoD on the FlexVPN server:
Enforce re-authentication: A network administrator might want to terminate a user session on a FlexVPN server to force a re-authentication if a session is connected for a very long duration.
Apply a new policy: A network administrator might want to terminate an active crypto session and apply the new policy to the session when the client reconnects.
Free resources: A session may need to be terminated to free the resources.
Configuring RADIUS Packet of Disconnect
To configure the RADIUS packet of disconnect follow the steps:
Step 1. Enable RADIUS dynamic authorization on the FlexVPN server.
Router(config)#aaa server radius ?
dynamic-author Local server profile for RFC 3576 support
Router(config)#aaa server radius dynamic-author
Router(config-locsvr-da-radius)#?
RADIUS Application commands:
client Specify a RADIUS client
port Specify port on which local radius server listens
server-key Encryption key shared with the radius clients
Step 2. Specify the dynamic authorization client (DAC) typically co-located with the RADIUS server.
Router(config-locsvr-da-radius)#client ?
Hostname or A.B.C.D IP address of RADIUS client
X:X:X:X::X IPv6 address of RADIUS client
Step 3. Configure the shared-secret. Note that the same shared-secret must be configured on the DAC as well.
Router(config-locsvr-da-radius)#server-key ?
0 Specifies an UNENCRYPTED key will follow
6 Specifies an ENCRYPTED key will follow
7 Specifies HIDDEN key will follow
WORD The UNENCRYPTED (cleartext) shared key
Step 4. On the DAC (RADIUS server), as part of the PoD command, specify the DAS (FlexVPN server) IP address and the audit-session-id identifying the session to be deleted.
RADIUS Packet of Disconnect Example
The following example illustrates the display of audit-session-id Cisco AV pair in AAA authorization and accounting requests and the deletion of IKE/IPsec session on receipt of RADIUS PoD. The relevant debug aaa pod and debug crypto ikev2 logs are highlighted.
The audit-session-id Cisco AV pair sent in authorization requests.
IKEv2:Using mlist aaa_list1 and username router1 for user author request
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorization request sent
RADIUS(000000D0): Send Access-Request to 172.16.1.3:1645 id 1645/37, len 132
RADIUS: authenticator E0 93 9F 13 28 EB 8A EA - 64 46 2B 52 53 CF D1 33
RADIUS: User-Name [1] 9 "router1"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 61
RADIUS: Cisco AVpair [1] 55 "audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN34"
The ‘audit-session-id’ Cisco AV pair sent in accounting requests.
RADIUS(000000D3): Send Accounting-Request to 172.16.1.3:1646 id 1646/96, len 267
RADIUS: authenticator DD 1D 68 F4 B0 EF 11 DA - 91 22 C2 9E 7C 86 5F A7
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 61
RADIUS: Cisco AVpair [1] 55 "audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN34"
Display the audit-session-id in the show aaa user command output. Find the peer IKE identity from the show crypto ikev2 sa detail command.
Router2#show crypto ikev2 sa detail
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 172.16.1.2/500 172.16.1.1/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:5, Auth sign:
PSK, Auth verify: PSK
Life/Active Time: 86400/3 sec
CE id: 1057, Session-id: 52
Status Description: Negotiation done
Local spi: 8D331A95A67688AB Remote spi: E7286487AC534733
Local id: 172.16.1.2
Remote id: router1.domain1
Display the audit-session-id corresponding to the peer IKE identity, using the show aaa user all command. Note that AAA accounting must be enabled for the session for audit-session-id to be displayed.
Router#show aaa user all | begin router1.domain1
IPSEC-TUNNEL: Username=router1.domain1
Session Id=000000CE Unique Id=000000D8
Start Sent=1 Stop Only=N
stop_has_been_sent=N
Method List=8655B740 : Name = acc_list
Attribute list:
86D5EEF8 0 00000082 formatted-clid(37) 10 172.16.1.1
86D5EF2C 0 0000008A audit-session-id(819) 36
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN35
86D5EF60 0 00000081 isakmp-phase1-id(737) 15 router1.domain1
86D5EF94 0 00000002 isakmp-initator-ip(738) 4 172.16.1.1
The PoD received from the DAC (RADIUS server) with audit-session-id Cisco AV pair is shown:
RADIUS: POD received from id 6 172.16.1.3:1700, POD Request, len 84
POD: 172.16.1.3 request queued
++++++ POD Attribute List ++++++
86D5EDB4 0 00000089 audit-session-id(819) 36
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN34
The FlexVPN server sends ACK after finding the session corresponding to the received audit-session-id and queueing it for deletion.
POD: Sending ACK from port 1700 to 172.16.1.3/1700
The IKEv2/IPsec session is deleted.
IKEv2:(SESSION ID = 52,SA ID = 1):Sending DELETE INFO message for IKEv2 SA [ISPI:
0x5610ADC95CCD6AC7 RSPI: 0x1842E6A7EF7BE81A]
IKEv2:(SESSION ID = 52,SA ID = 1):Building packet for encryption.
Payload contents:
DELETE NOTIFY(DELETE_REASON)
IKEv2:(SESSION ID = 52,SA ID = 1):Delete all IKE SAs
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Accounting stop request sent successfully
RADIUS(000000D3): Send Accounting-Request to 172.16.1.3:1646 id 1646/97, len 335
RADIUS: authenticator 9E 05 29 DA EF 2B 44 37 - 89 5A DC F0 0B 71 70 FA
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Vendor, Cisco [26] 61
RADIUS: Cisco AVpair [1] 55 "audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN34"
The FlexVPN server sends NACK when no matching session is found.
RADIUS: POD received from id 9 172.16.1.3:1700, POD Request, len 84
POD: 172.16.1.3 request queued
++++++ POD Attribute List ++++++
86D5F0E4 0 00000089 audit-session-id(819) 36 L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN34
POD: 172.16.1.3 Unsupported attribute type 26 for component
POD: 172.16.1.3 user 0.0.0.0i sessid 0x0 key 0x0 DROPPED
POD: Added Reply Message: No Matching Session
POD: Added NACK Error Cause: Invalid Request
POD: Sending NAK from port 1700 to 172.16.1.3/1700
RADIUS: 18 21 4E6F204D61746368696E672053657373696F6E
RADIUS: 101 6 00000194
RADIUS Change of Authorization (CoA)
The FlexVPN server supports RADIUS change-of-authorization (CoA) as defined in RFC–5716 that allows changing the authorization attributes applied to an IKE/IPsec session through the unsolicited CoA message from the RADIUS server as illustrated in the Figure 9-10. The FlexVPN server currently supports only the audit-session-id Cisco AV pair in the CoA message to identify the session. The FlexVPN server returns CoA-ACK after successfully applying the authorization attributes to the session, or it returns CoA-NACK if session is not found or the attributes could not be applied.
As with PoD, the audit-session-id to be used in the CoA message to identify the session can be obtained from the debug and show command outputs on the FlexVPN server. The FlexVPN server sends the audit-session-id Cisco AV pair attribute in all the AAA authentication, authorization, and accounting requests and can be seen in the debug radius authentication and debug radius accounting output, as well as using the show aaa user command.
FlexVPN server currently supports the following RADIUS attributes in the CoA request:
The interface-config Cisco AV pair attribute which can contain any interface configuration mode command string and is applied to the virtual-access interface for the session corresponding to the audit-session-id received in the CoA request.
The sub-policy-in and sub-qos-policy-in Cisco AV pair attributes that contain the interface configuration mode command string to apply the QoS policy in the inbound direction (service-policy input QoS-policy-name). The command string is applied to the session virtual-access interface.
The sub-policy-out and sub-qos-policy-out Cisco AV pair attributes that contain the interface configuration mode command string to apply the QoS policy in the outbound direction (service-policy input QoS-policy-name). The command string is applied to the session virtual-access interface.
The inacl Cisco AV pair attribute, which defines a template access control list (ACL) that is applied to the session virtual-access interface in the inbound direction.
The outacl Cisco AV pair attribute, which defines a template ACL that is applied to the session virtual-access interface in the outbound direction.
Configuring RADIUS CoA
To configure RADIUS CoA, follow these steps:
Step 1. Enable RADIUS dynamic authorization on the FlexVPN server.
Router(config)#aaa server radius ?
dynamic-author Local server profile for RFC 3576 support
Router(config)#aaa server radius dynamic-author
Router(config-locsvr-da-radius)#?
RADIUS Application commands:
client Specify a RADIUS client
port Specify port on which local radius server listens
server-key Encryption key shared with the radius clients
Step 2. Specify the dynamic authorization client (DAC) typically co-located with the RADIUS server.
Router(config-locsvr-da-radius)#client ?
Hostname or A.B.C.D IP address of RADIUS client
X:X:X:X::X IPv6 address of RADIUS client
Step 3. Specify the shared-secret that must be configured on the DAC, as well.
Router(config-locsvr-da-radius)#server-key ?
0 Specifies an UNENCRYPTED key will follow
6 Specifies an ENCRYPTED key will follow
7 Specifies HIDDEN key will follow
WORD The UNENCRYPTED (cleartext) shared key
Step 4. On the DAC (RADIUS server), as part of the CoA command, specify the DAS (FlexVPN server) IP address, the audit-session-id identifying the session, and the attributes to be updated.
RADIUS CoA Examples
The following two examples illustrate the power of CoA to update the configuration on a virtual-access interface.
Updating Session QoS Policy, Using CoA
The following example illustrates updating the QoS policy applied to a session’s virtual-access interface, using CoA. The QoS policies must be defined on the FlexVPN server.
Step 1. Define the QoS policies.
policy-map Input-QoS-policy-1
class class-default
policy-map Input-QoS-policy-2
class class-default
policy-map Output-QoS-policy-2
class class-default
policy-map Output-QoS-policy-1
class class-default
Step 2. Apply the QoS policies on the virtual-template so that they get cloned on the virtual-access interface.
interface Virtual-Template1 type tunnel
ip unnumbered Ethernet0/0
tunnel protection ipsec profile default
service-policy input Input-QoS-policy-1
service-policy output Output-QoS-policy-1
Step 3. Establish the session and verify the QoS policies applied on the virtual-access interface.
Router#show crypto session
Crypto session current status
Interface: Virtual-Access1
Profile: default
Session status: UP-ACTIVE
Peer: 172.16.1.1 port 500
Session ID: 60
IKEv2 SA: local 172.16.1.2/500 remote 172.16.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.16.1.1
Active SAs: 2, origin: crypto-map
Router#show derived-config interface virtual-access 1
interface Virtual-Access1
ip unnumbered Ethernet0/0
tunnel source 172.16.1.2
tunnel destination 172.16.1.1
tunnel protection ipsec profile default
no tunnel protection ipsec initiate
service-policy input Input-QoS-policy-1
service-policy output Output-QoS-policy-1
end
Step 4. Note the audit-session-id for the session and use the same while initiating the CoA from the RADIUS server.
Router#show aaa user all | begin router1.domain1
IPSEC-TUNNEL: Username=router1.domain1
Session Id=000000F1 Unique Id=000000FB
Start Sent=1 Stop Only=N
stop_has_been_sent=N
Method List=8655B740 : Name = acc_list
Attribute list:
86D5F338 0 00000082 formatted-clid(37) 10 172.16.1.1
86D5F36C 0 0000008A audit-session-id(819) 36
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN3C
Step 5. Initiate the CoA command from the RADIUS server (DAC) to update the QoS policies applied on the session’s virtual-access interface. The relevant debug aaa coa and debug vtemplate cloning logs are highlighted. Note that the audit-session-id and the attributes to update the QoS policies are received in the CoA request.
RADIUS: COA received from id 1 172.16.1.3:1700, CoA Request, len 323
COA: 172.16.1.3 request queued
RADIUS: authenticator 30 46 44 CE 19 6C FE 74 - 1D 64 7A DB 5B 9E 20
0F
RADIUS: Vendor, Cisco [26] 64
RADIUS: Cisco AVpair [1] 58 "ip:audit-session-id=
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN3B"
RADIUS: Vendor, Cisco [26] 67
RADIUS: Cisco AVpair [1] 61 "ip:interface-config=
service-policy input Input-QoS-policy-2"
RADIUS: Vendor, Cisco [26] 69
RADIUS: Cisco AVpair [1] 63 "ip:interface-config=
service-policy output Output-QoS-policy-2"
++++++ CoA Attribute List ++++++
86D5F0E4 0 00000089 audit-session-id(819) 36
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN3B
86D5F25C 0 00000089 interface-config(222) 39 service-policy input
Input-QoS-policy-2
86D5F290 0 00000089 interface-config(222) 41 service-policy output
Output-QoS-policy-2
The FlexVPN server sends CoA-ACK.
COA: Sending ACK from port 1700 to 172.16.1.3/1700
The interface configuration commands received in the interface-config attributes are applied to the virtual-access interface for the session corresponding to the received audit-session-id.
VT[Vi1]:Clone Vaccess from AAA (99 bytes)
VT[Vi1]:service-policy input Input-QoS-policy-2
VT[Vi1]:service-policy output Output-QoS-policy-2
VT[Vi1]:end
Step 6. Verify that the QoS policies applied on the virtual-access interface are updated.
Router#show derived-config interface virtual-access 1
interface Virtual-Access1
ip unnumbered Ethernet0/0
tunnel source 172.16.1.2
tunnel destination 172.16.1.1
tunnel protection ipsec profile default
no tunnel protection ipsec initiate
service-policy input Input-QoS-policy-2
service-policy output Output-QoS-policy-2
end
Updating the Session ACL, Using CoA
The following example illustrates applying a template ACL to a session’s virtual-access interface using CoA. Note that the new ACL replaces any existing ACL applied to the virtual-access interface.
Step 1. Establish the session and verify the configuration on the virtual-access interface.
Router#show crypto session
Crypto session current status
Interface: Virtual-Access1
Profile: default
Session status: UP-ACTIVE
Peer: 172.16.1.1 port 500
Session ID: 60
IKEv2 SA: local 172.16.1.2/500 remote 172.16.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.1.2 host 172.16.1.1
Active SAs: 2, origin: crypto-map
Router#show derived-config interface virtual-access 1
interface Virtual-Access1
ip unnumbered Ethernet0/0
tunnel source 172.16.1.2
tunnel destination 172.16.1.1
tunnel protection ipsec profile default
no tunnel protection ipsec initiate
end
Step 2. Note the audit-session-id for the session and use the same while initiating the CoA from the RADIUS server.
Router#show aaa user all | begin router1.domain1
IPSEC-TUNNEL: Username=router1.domain1
Session Id=000000F9 Unique Id=00000103
Start Sent=1 Stop Only=N
stop_has_been_sent=N
Method List=8655B740 : Name = acc_list
Attribute list:
86D5EEF8 0 00000082 formatted-clid(37) 10 172.16.1.1
86D5EF2C 0 0000008A audit-session-id(819) 36
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN3D
Step 3. Initiate the CoA command from the RADIUS server (DAC). The relevant debug aaa coa and debug vtemplate cloning logs are highlighted. Note that the audit-session-id and the attributes to apply to the template ACL are received in the CoA request.
RADIUS: COA received from id 4 172.16.1.3:1700, CoA Request, len 151
COA: 172.16.1.3 request queued
RADIUS: authenticator AD 54 06 14 D9 22 22 5C - 2E 06 C1 CF 86 56 41 C3
RADIUS: Vendor, Cisco [26] 33
RADIUS: Cisco AVpair [1] 27 "ip:inacl#3=permit 1.1.1.1"
RADIUS: Vendor, Cisco [26] 34
RADIUS: Cisco AVpair [1] 28 "ip:outacl#4=permit 1.1.1.3"
RADIUS: Vendor, Cisco [26] 64
RADIUS: Cisco AVpair [1] 58 "ip:audit-session-
id=L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN3D"
++++++ CoA Attribute List ++++++
86D5F0E4 3 00000081 inacl(144) 14 permit 1.1.1.1
86D5EEC4 4 00000081 outacl(310) 14 permit 1.1.1.3
86D5EEF8 0 00000089 audit-session-id(819) 36
L2L4AC1G102ZO2L4AC1G101ZI1F401F4ZN3D
The FlexVPN server sends CoA-ACK.
COA: Sending ACK from port 1700 to 172.16.1.3/1700
The commands are applied to the virtual-access interface for the session corresponding to the received audit-session-id.
VT[Vi1]:Clone Vaccess from AAA (86 bytes)
VT[Vi1]:IP access-group Virtual-Access1#2601 in
VT[Vi1]:IP access-group Virtual-Access1#2602 out
VT[Vi1]:end
Step 4. Verify that the ACLs on the virtual-access interface are updated.
Router#show ip interface virtual-access 1 | include access
Outgoing access list is Virtual-Access1#2602, default is not set
Inbound access list is Virtual-Access1#2601, default is not set
Router#show ip access-lists
Standard IP access list Virtual-Access1#2601
10 permit 1.1.1.1
Standard IP access list Virtual-Access1#2602
10 permit 1.1.1.3
IKEv2 Auto-Reconnect
The FlexVPN server supports the IKEv2 auto-reconnect feature with AnyConnect client that allows the AnyConnect client to automatically reconnect the IKEv2 session without any user intervention when the IKEv2 session goes down temporarily due to loss of network connectivity, client switching to a different network, or going into sleep mode.
Following are some of the advantages of the auto-reconnect feature:
The auto-reconnect IKE/IPsec session is much quicker and lighter.
For the auto-reconnect session, the AnyConnect client authenticates by using the pre-shared key method that is lighter and quicker than EAP and certificate-based methods. The session token provided by the FlexVPN server during the initial session is used as the pre-shared key.
The FlexVPN server preserves and reuses the AAA authorization attributes from the initial session for the auto-reconnect sessions, thus avoiding the overhead of round trips to the AAA servers.
The reconnect feature enhances the user experience because it does not require any user intervention and automatically reconnects when the network connectivity is available or when the client wakes up from the sleep or hibernate mode.
The reconnect feature enhances security because it ensures that the end host is always connected securely.
Limitations of the IKEv2 auto-reconnect feature are described below:
The IKEv2 auto-reconnect feature is not supported with pre-shared key authentication. Hence, the AnyConnect client must authenticate, using either EAP or certificate-based methods, and the FlexVPN server client must authenticate using only the certificate-based method. Note that this limitation applies to the initial session and that the AnyConnect client authenticates using the pre-shared key method for the auto-reconnect sessions.
The auto-reconnect does not work and the normal IKEv2 session establishment needs to happen in the following cases:
When the user disconnects the session on the AnyConnect client or clears the session on the FlexVPN server.
When the AnyConnect client host or the FlexVPN server reboots.
When the reconnect timer on the FlexVPN server expires after which the server discards the preserved session information.
Auto-Reconnect Configuration Attributes
The AnyConnect client indicates intent to use the auto-reconnect feature by requesting the Cisco proprietary configuration attributes in the CFG_REQUEST payload in IKE_AUTH request during the initial IKEv2 session setup. Note that there is no capability negotiation using the Vendor-ID payload for the auto-reconnect feature. If the auto-reconnect feature is enabled using reconnect command in the IKEv2 profile associated with the client session, the FlexVPN server provides values for the requested configuration attributes in the CFG_REPLY payload in IKE_AUTH response. Table 9-1 lists the Cisco proprietary configuration attributes related to the auto-reconnect feature.
Note that the AnyConnect client uses the same reconnect-session-id and reconnect-token-id that was provided by the FlexVPN server during the initial session for all the reconnect sessions.
The auto-reconnect behavior for AnyConnect can be controlled through the AnyConnect XML profile with this setting:
<AutoReconnect UserControllable="true">true
<AutoReconnectBehavior>ReconnectAfterResume</AutoReconnectBehavior>
</AutoReconnect>
Using this defined setting, AnyConnect will try to reconnect when the computer is brought back from sleep. The AutoReconnectBehavior preference defaults to DisconnectOnSuspend. For reconnection after resuming, the network administrator must either set ReconnectAfterResume in the profile or make the AutoReconnect and AutoReconnectBehavior preferences user controllable in the profile to allow users to set it.
Smart DPD
With the auto-reconnect feature, the FlexVPN server uses smart DPD probes to confirm if the AnyConnect client is unreachable before moving the session to the inactive state and waiting for the client to reconnect. The FlexVPN server automatically enables smart DPD probes when DPD is not explicitly configured and tracks the DPD probes from the client if available to check whether the client is live. When probes are not received from the client for a certain duration, the FlexVPN server starts sending probes to the client to confirm its liveness. If the client responds to the server probe, the server again waits for the probes from the client and repeats the process. If the client does not respond to server probes, the server concludes that the client is unreachable, preserves the session state, and moves the session to an inactive state, waiting for the client to reconnect. Note that when DPD is explicitly configured, the FlexVPN server uses these DPDs to track the client reachability.
Figure 9-11 illustrates the IKE_AUTH exchange for the initial and the auto-reconnect sessions.
When the IKEv2 auto-reconnect feature is enabled on the AnyConnect client, the client authenticates either using either EAP or certificate-based method and requests for the Cisco proprietary configuration attributes session-id, session-token, dpd-interval and cleanup-interval in the CFG_REQUEST payload in IKE_AUTH request.
If the IKEv2 auto-reconnect feature is enabled on the FlexVPN server, using the reconnect command in the IKEv2 profile, the server authenticates using the certificate-based method and provides the values for these reconnect attributes in the CFG_REPLY payload in IKE_AUTH response.
When the server detects that the client is unreachable using smart DPD, the server preserves the session state, including the reconnect attributes and the AAA authorization attributes, and moves the session to inactive state, waiting for client to reconnect before the reconnect timeout duration.
If the client session went down due any reason other than user-initiated disconnection, the client reconnects, authenticating using pre-shared-key method and using the session-id and session-token attributes received from the server as the IKE identity and pre-shared-key respectively.
The server looks up the preserved session, using the session-id, and authenticates the client, using the corresponding session-token. If the authentication is successful, the server creates a new session, using the preserved authorization attributes, thus avoiding the overhead of round trips to the AAA server. The server authenticates using the certificate-based method.
If the client does not reconnect within the reconnect timeout duration configured on the server, the preserved session state is discarded. After reconnect timeout, the client reconnect attempts will fail, and the client must establish a new session.
Configuring IKEv2 Auto-Reconnect
The IKEv2 auto-reconnect feature on the FlexVPN server is enabled in the IKEv2 profile as illustrated in the following example. The reconnect-timeout value specifies the duration for which the FlexVPN server would preserve the inactive session state and wait for the client to reconnect. After that, the server will discard the state, reconnect attempts from the client will fail, and the client will have to establish a new session. The default reconnect-timeout duration is 30 minutes.
Auto-reconnect cannot be configured in an IKEv2 profile when either the local or remote authentication method is based on a pre-shared key.
Router(config)#crypto ikev2 profile default
Router(config-ikev2-profile)#authentication local pre-share
Router(config-ikev2-profile)#reconnect ?
timeout timeout value for session in reconnect state
<cr>
Router(config-ikev2-profile)#reconnect
Reconnect can not be configured if either Keyring, PSK authentication or PSK
authorization enabled in profile.
Router(config-ikev2-profile)#authentication local rsa-sig
Router(config-ikev2-profile)#authentication remote eap
Router(config-ikev2-profile)#reconnect timeout ?
<600-86400> reconnect timeout interval in seconds
Please refer AnyConnect documentation for steps to enable the IKEv2 auto-reconnect feature on the client.
The show crypto session detail command outputs can be used to determine if a session is the initial or the reconnected session. The capability flag R would be set for the reconnected session and not for the initial session. Also note that for a reconnected session, the Auth verify field in the show crypto ikev2 sa detail command output must be PSK.
ASR-HUB1#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect
Interface: Virtual-Access1
Profile: ike_profile
Uptime: 00:00:38
Session status: UP-ACTIVE
Peer: 10.104.105.162 port 64696 fvrf: (none) ivrf: (none)
Phase1_id: eap
Desc: (none)
Session ID: 81
IKEv2 SA: local 10.104.49.17/4500 remote 10.104.105.162/64696 Active
Capabilities:DNX connid:1 lifetime:23:59:22
Router#show crypto ikev2 sa detail
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.104.49.17/4500 10.104.105.162/64696 none/none READY
Encr: 3DES, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: RSA, Auth verify: EAP
Reconnected session:
Router#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect
Interface: Virtual-Access1
Profile: ike_profile
Uptime: 00:02:49
Session status: UP-ACTIVE
Peer: 10.104.105.162 port 56028 fvrf: (none) ivrf: (none)
Phase1_id: eap
Desc: (none)
Session ID: 84
IKEv2 SA: local 10.104.49.17/4500 remote 10.104.105.162/56028 Active
Capabilities:DNR connid:1 lifetime:23:57:11
Router#show crypto ikev2 sa detail
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 10.104.49.17/4500 10.104.105.162/56028 none/none READY
Encr: 3DES, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: RSA, Auth verify: PSK
The show crypto ikev2 stats reconnect displays the statistics relevant to the auto-reconnect feature. The following command output indicates that the FlexVPN server has received a total of 20 auto-reconnect requests from clients and that all of them succeeded—none failed. The Reconnect capable active session count message indicates the number of auto-reconnect capable sessions that have active sessions with the clients. The message Reconnect capable inactive session count indicates the number of auto-reconnect capable sessions that are inactive after detecting that client is unresponsive and have preserved the session state and are waiting for clients to reconnect before the reconnect timeout duration.
Router#show crypto ikev2 stats reconnect
Total incoming reconnect connection: 20
Success reconnect connection: 20
Failed reconnect connection: 0
Reconnect capable active session count: 5
Reconnect capable inactive session count: 2
User Authentication, Using AnyConnect-EAP
The AnyConnect client uses an XML-based aggregate authentication and configuration protocol that uses an XML document referred to as Aggregate XML to exchange authentication and configuration information between the client and the security gateway. IKEv2 can carry the Aggregate XML inside a Cisco proprietary configuration attribute or inside an EAP payload using a proprietary EAP method. Authentication performed using the Aggregate XML is referred to as Aggregate authentication.
AnyConnect-EAP
AnyConnect-EAP is a Cisco proprietary EAP method used between an AnyConnect client and security gateways such as ASA and the FlexVPN server for client-side user and device authentication using the XML-based aggregate authentication and configuration protocol. The FlexVPN server uses AnyConnect-EAP to query the client for user credentials and validates the credentials using AAA authentication similar to XAUTH user authentication in IKEv1. The AAA authentication can be local or RADIUS based. For local AAA authentication, the user credentials are configured using the username name-string password password-string commands in the global configuration mode. One advantage of the Anyconnect-EAP method is that it allows client user authentication without requiring an external EAP server. Unlike standards-based EAP methods (such as EAP-GTC, EAP-MD5 etc.), the FlexVPN Server does not operate in EAP pass-through mode. All EAP communication with the client terminates on the FlexVPN Server, and the required session key used to construct the AUTH payload is computed locally by the FlexVPN Server. The FlexVPN Server authenticates itself to the client using certificates as per RFC 7296. Figure 9-12 illustrates user authentication with the AnyConnect-EAP method.
AnyConnect-EAP XML Messages for User Authentication
Figure 9-13 illustrates the AnyConnect-EAP XML messages exchanged between the AnyConnect client and the FlexVPN server for client-side user authentication using RADIUS, however local AAA can also be used if required.
Following is a description of the steps involved:
1. The AnyConnect client and the FlexVPN server exchange the capability to perform AnyConnect-EAP using the CiscoCopyright and AnyConnect-EAP vendor ID payloads in IKE_SA_INIT exchange.
2. The AnyConnect client indicates its intent to authenticate using the AnyConnect-EAP method by leaving out the AUTH payload in the IKE_AUTH request. The IKE identity is defined within the XML profile on the AnyConnect client.
3. If the FlexVPN server is configured to authenticate this client, using the AnyConnect-EAP method in the IKEv2 profile using the authentication remote anyconnect-eap command, the FlexVPN server authenticates using certificate-based method and sends an EAP-Request containing AnyConnect-EAP XML hello message in IKE_AUTH response message. The hello message informs the client to initiate the aggregate authentication and configuration protocol with the client.
4. The AnyConnect client sends an EAP-Response containing AnyConnect-EAP XML init message in IKE_AUTH request message. The init message initiates the aggregate authentication and configuration protocol with the FlexVPN server.
5. The FlexVPN server sends an EAP-Request containing AnyConnect-EAP XML auth-request message in IKE_AUTH response message. The auth-request message requests authentication credentials from the client.
6. The AnyConnect client sends an EAP-Response containing AnyConnect-EAP XML auth-reply message in IKE_AUTH request message. The auth-reply message carries user credentials from the client.
7. The FlexVPN server validates the user credentials, using RADIUS authentication, and if the authentication is successful, sends an EAP-Request containing AnyConnect-EAP XML complete message in IKE_AUTH response message. The complete message indicates that the authentication is complete.
8. The AnyConnect client sends an EAP-Response containing AnyConnect-EAP XML ack message in IKE_AUTH request message. The ack message acknowledges the receipt of complete message.
9. The FlexVPN server sends an EAP-Success message in IKE_AUTH response message.
10. The AnyConnect client and the FlexVPN server perform mutual authentication using the pre-shared key method. The SK_pi and SK_pr values derived from the Diffie-Hellman shared secret are used as the pre-shared-key.
Configuring User Authentication, Using AnyConnect-EAP
The following example illustrates configuring AnyConnect-EAP on the FlexVPN server for the client user authentication using a RADIUS server, although local AAA can be used as well.
Step 1. AnyConnect-EAP can only be configured as a remote authentication method and the local authentication method must be certificate-based.
Router(config-ikev2-profile)#authentication remote ?
anyconnect-eap AnyConnect EAP
eap Extended Authentication Protocol
ecdsa-sig ECDSA Signature
pre-share Pre-Shared Key
rsa-sig Rivest-Shamir-Adleman Signature
Router(config-ikev2-profile)#authentication remote anyconnect-eap ?
aggregate use aggregate auth for anyconnect eap
Router(config-ikev2-profile)#authentication remote anyconnect-eap
aggregate
Step 2. Specify the AAA authentication list that points to the RADIUS server to authenticate the user credentials obtained through Anyconnet-EAP.
Router(config-ikev2-profile)#aaa authentication anyconnect-eap ?
WORD AAA list name
Step 3. The AAA user and group authorization and accounting can be configured for AnyConnect-EAP authentication method.
Router(config-ikev2-profile)#aaa authorization group ?
anyconnect-eap AAA list to use when IKEv2 remote auth method is
anyconnect
eap based
Router(config-ikev2-profile)#aaa authorization user ?
anyconnect-eap AAA list to use when IKEv2 remote auth method is
anyconnect
eap based
Router(config-ikev2-profile)#aaa accounting ?
anyconnect-eap AAA list to use when IKEv2 remote auth method is
AnyConnect
EAP
Step 4. The show crypto ikev2 session detail command output displays the remote authentication method as AnyConnect-EAP.
Router#show crypto ikev2 sa detail
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 192.168.1.1/4500 192.168.1.2/65058 none/none READY
Encr: 3DES, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: RSA,
Auth verify: AnyConnect-EAP
Life/Active Time: 86400/8 sec
CE id: 1007, Session-id: 6
Status Description: Negotiation done
Local spi: 016B20168FB2D051 Remote spi: B4E6576AD4BEAF7A
Local id: 192.168.1.2
Remote id: AnyConnect-IKE-ID
Remote EAP id: [email protected]
AnyConnect Configuration for Aggregate Authentication
When connecting using AnyConnect-EAP the client will present an IKE identity which is defined within the AnyConnect XML profile. The following illustrates the method of configuring the IKE Identity within the AnyConnect XML profile.
<IKEIdentity>AnyConnect-IKE-ID</IKEIdentity>
The following illustrates the method of configuring the FlexVPN server to match the IKE Identity. The same IKE Identity must be configured on the FlexVPN Server under the IKEv2 profile as what is presented by the AnyConnect client.
Router(config-ikev2-profile)#match identity remote ?
address IP Address(es)
any match any peer identity
email Fully qualified email string [Max. 255 char(s)]
fqdn Fully qualified domain name string [Max. 255 char(s)]
key-id key-id opaque string
Router(config-ikev2-profile)#match identity remote key-id ?
WORD Specify the key-id string
Router(config-ikev2-profile)#match identity remote key-id AnyConnect-IKE-ID
At the time of writing the feature that allows the AnyConnect client to download newer versions of the client software from the VPN gateway is not supported on Cisco IOS. In order to disable this feature a change in the AnyConnectLocalPolicy file is required as illustrated below.
<BypassDownloader>true</BypassDownloader>
Note: If configuring local authentication with AnyConnect-EAP the username and password must be defined locally on the IOS device using the username command.
Dual-factor Authentication, Using AnyConnect-EAP
IKEv2 supports EAP, pre-shared key, and certificate-based authentication methods. While pre-shared key and certificate-based methods are typically used for device authentication, EAP is mainly used for user authentication. However, since an IKEv2 node can authenticate using only one of these authentication methods, an IKEv2 node can either perform device or user authentication but not both. There are cases when using tunneled EAP methods (e.g., EAP-TLS) where multiple authentications can occur. However, this is not used for AnyConnect-EAP. The ability to perform device as well as user authentication by AnyConnect-EAP is referred to as dual-factor authentication here.
IKEv2 dual-factor authentication is useful and required for the following reasons.
There are scenarios where making the authorization decision in IKEv2 requires using multiple authentication methods. For instance, it may be necessary to authenticate both the host machine requesting access and the user currently using the host. These two authentications would use two separate sets of credentials and might even use different authentication mechanisms.
Another example is when an operator is hosting a virtual private network (VPN) gateway service for a third party, it may be necessary to authenticate the client to both the operator for billing purposes and the third-party’s AAA server for authorizing access to the third-party’s internal network.
IKEv1 supports dual-factor authentication using XAUTH defined in the IETF draft “Extended Authentication within ISAKMP/Oakley (XAUTH).” The XAUTH user authentication is performed after device authentication, using pre-shared key or certificate-based methods. Customers migrating from IKEv1 expect IKEv2 to support both device and user authentication as well.
There are two ways of supporting dual-factor authentication.
The RFC 4739, “Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol,” specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user.
Double authentication using AnyConnect-EAP. The XML-based aggregate authentication and configuration protocol transported over the AnyConnect-EAP allows the security gateway to query the client for certificate for device authentication as well as user credentials for user authentication.
The FlexVPN server supports dual-factor authentication using the AnyConnect-EAP method as illustrated in the Figure 9-14.
AnyConnect-EAP XML Messages for dual-factor authentication
Figure 9-15 illustrates the AnyConnect-EAP XML messages exchanged between the AnyConnect client and the FlexVPN server for client-side device and user authentication. The AnyConnect-EAP message flow for dual-factor authentication is similar to that of user authentication except it requires an additional XML exchange for device authentication. Although the example illustrates AAA authentication using RADIUS server, local AAA can be used as well.
A description of the steps involved follows:
1. The AnyConnect client and the FlexVPN server exchange the capability to perform AnyConnect-EAP using the CiscoCopyright and AnyConnect-EAP vendor ID payloads in IKE_SA_INIT exchange.
2. The AnyConnect client indicates its intent to authenticate using the AnyConnect-EAP method by leaving out the AUTH payload in the IKE_AUTH request.
3. If the FlexVPN server is configured to authenticate this client using the AnyConnect-EAP method in the IKEv2 profile using the authentication remote anyconnect-eap command, the FlexVPN server authenticates with the certificate-based method and sends an EAP-Request containing AnyConnect-EAP XML hello message in IKE_AUTH response message. The hello message informs the client to initiate the aggregate authentication and configuration protocol with the client.
4. The AnyConnect client sends an EAP-Response containing AnyConnect-EAP XML init message in IKE_AUTH request message. The init message initiates the aggregate authentication and configuration protocol with the FlexVPN server.
5. The FlexVPN server sends an EAP-Request containing AnyConnect-EAP XML auth-request and client-cert-auth messages in IKE_AUTH response message, requesting the client certificate and the corresponding authentication data.
6. The AnyConnect client sends an EAP-Response containing a certificate and the corresponding authentication data signed using the private key and the init message in IKE_AUTH request message.
7. The FlexVPN server validates the certificate and the corresponding authentication data. If the authentication is successful, the FlexVPN server sends an EAP-Request containing the AnyConnect-EAP XML auth-request message in the IKE_AUTH response message. The auth-request message requests authentication credentials from the client.
8. The AnyConnect client sends an EAP-Response containing AnyConnect-EAP XML auth-reply message in IKE_AUTH request message. The auth-reply message carries user credentials from the client.
9. The FlexVPN server validates the user credentials using RADIUS authentication, and if the authentication is successful, sends an EAP request with AnyConnect-EAP XML complete message in IKE_AUTH response message. The complete message indicates that the authentication is complete.
10. The AnyConnect client sends an EAP-Response containing AnyConnect-EAP XML ack message in IKE_AUTH request message. The ack message acknowledges the receipt of complete message.
11. The FlexVPN server sends an EAP success message in IKE_AUTH response message.
12. The AnyConnect client and the FlexVPN server perform mutual authentication using the pre-shared key method. The SK_pi and SK_pr values derived from the Diffie-Hellman shared secret are used as the pre-shared key.
Configuring Dual-factor Authentication, Using AnyConnect-EAP
The following example illustrates configuring dual-factor authentication using AnyConnect-EAP on the FlexVPN server.
Router(config-ikev2-profile)#authentication remote anyconnect-eap aggregate ?
cert-request use double authentication during anyconnect eap
<cr>
Router(config-ikev2-profile)#authentication remote anyconnect-eap aggregate
cert-request ?
<cr>
Router2(config-ikev2-profile)#authentication remote anyconnect-eap aggregate
cert-request
Specify the AAA authentication list pointing to the RADIUS server to authenticate the user credentials obtained through Anyconnet-EAP.
Router(config-ikev2-profile)#aaa authentication anyconnect-eap ?
WORD AAA list name
RADIUS Attributes Supported by the FlexVPN Server
This section describes the RADIUS attributes supported by the FlexVPN server. Theattributes are either standard IETF RADIUS attributes or Cisco AV pairs and are configured on the RADIUS server or locally in the IKEv2 authorization policy that acts as the local AAA database. The attributes in the IKEv2 authorization policy are either configured as commands or by referencing an AAA attribute list. The FlexVPN server uses some of the attributes locally and pushes some to the client, using IKEv2 configuration payloads CFG_REPLY and CFG_SET. The attributes can be specific to a peer when obtained through user authorization and can apply to multiple peers when obtained through group authorization.
Note
Cisco AV pair is a Cisco vendor-specific attribute (VSA) with vendor-id 9 and vendor-type 1. The VSAs are encapsulated in the Radius IETF attribute 26 Vendor-Specific. The Cisco AV pair is specified as a string of format protocol:attribute=value.
The following are the RADIUS attributes that are used by the FlexVPN server locally.
Tunnel-password=key-string
This IETF attribute specifies the symmetric pre-shared key to be used with pre-shared key authentication.
ipsec:ikev2-password-local=key-string
This Cisco AV pair specifies the asymmetric local pre-shared key that is used by FlexVPN server to authenticate to peer(s).
ipsec:ikev2-password-remote=key-string
This Cisco AV pair specifies the asymmetric remote pre-shared key that is used by FlexVPN server to authenticate peer(s).
Framed-Pool=pool-name
This IETF attribute specifies the name of the IPv4 address pool defined on the FlexVPN server that is used to allocate the IPv4 address to be assigned to the client using the INTERNAL_IP4_ADDRESS attribute. This attribute can be configured in the IKEv2 authorization policy using the pool pool-name command.
ipsec:group-dhcp-server=ipv4-address
This Cisco AV pair specifies the IPv4 DHCP server that is used by FlexVPN server to lease an IPv4 address to be assigned to the client using the INTERNAL_IP4_ADDRESS attribute. This attribute can be configured in the IKEv2 authorization policy using the dhcp server ipv4-address | hostname command.
ipsec:dhcp-giaddr=ipv4-address
This Cisco AV pair specifies the IPv4 address used by FlexVPN server as a source address to the contact the DHCP server. This attribute can be configured in the IKEv2 authorization policy using the dhcp giaddr ipv4-address command.
ipsec:dhcp-timeout=seconds
This Cisco AV pair specifies the time for which the FlexVPN server will wait for a response from the DHCP server. This attribute can be configured in the IKEv2 authorization policy using the dhcp timeout seconds command.
ipsec:ipv6-addr-pool=pool-name
This Cisco AV pair specifies the name of the IPv6 address pool defined on the FlexVPN server that is used to allocate the IPv6 address to be assigned to the client using the INTERNAL_IP6_ADDRESS attribute. This attribute is an IPv6 equivalent of the Framed-Pool IETF attribute. This attribute can be configured in the IKEv2 authorization policy using the ipv6 pool pool-name command.
ipsec:route-set=local ipv4 address mask next-hop address [tag:tag] [distance:distance]
This Cisco AV pair specifies an IPv4 subnet protected by the peer. The FlexVPN server adds a static route to this subnet pointing to the virtual-access interface corresponding to the peer and uses the specified next hop IP address, tag and distance while adding the static route. This attribute can be configured in the IKEv2 authorization policy using the route set local ipv4 address mask next-hop address tag tag distance distance command.
ipsec:route-set=local ipv6 prefix/length next-hop address [tag:tag] [distance:distance]
This Cisco AV pair specifies an IPv6 subnet protected by the peer. The FlexVPN server adds a static route to this subnet pointing to the virtual-access interface corresponding to the peer and uses the specified next hop IP address, tag and distance while adding the static route. This attribute can be configured in the IKEv2 authorization policy using the route set local ipv6 prefix/length next-hop address tag tag distance distance command.
ipsec:route-accept=any [tag:tag] [distance:distance]
This Cisco AV pair specifies the routes from the peer that can be accepted (“any” accepts all routes) and the tag and distance to be used while installing static routes to these subnets. This attribute can be configured in the IKEv2 authorization policy using the route accept any [tag tag] [distance distance] command.
ip:interface-config=interface-command-string
This Cisco AV pair specifies the interface configuration mode command string that is applied to the virtual-access interface associated with the peer’s session.
ipsec:ipsec-flow-limit=limit
This Cisco AV pair specifies the maximum number of IPsec Security Associations an IKEv2 session can have. This attribute is used with dVTI multi-SA feature. This attribute can be configured in the IKEv2 authorization policy using the ipsec flow-limit limit command.
The following are the RADIUS attributes that are pushed by the FlexVPN server to the client using IKEv2 configuration payloads. These attributes are pushed to all the IKEv2 clients.
Framed-IP-Address=ipv4-address
This IETF attribute specifies the IPv4 address that is assigned to a remote access client using the INTERNAL_IP4_ADDRESS configuration attribute.
Framed-IP-Netmask=ipv4-subnet-mask
This IETF attribute specifies the IPv4 subnet mask associated with the IPv4 address assigned to the client. This attribute is pushed to client, using the INTERNAL_IP4_NETMASK configuration attribute. This attribute can be configured in the IKEv2 authorization policy, using the netmask mask command.
ipsec:route-set=interface [interface-name]
This Cisco AV pair enables the sending of IPv4/IPv6 address of the VPN interface (virtual-access interface associated with the peer’s session) or the specified interface to the peer using the INTERNAL_IP4_SUBNET attribute. This attribute can be configured in the IKEv2 authorization policy using the route set interface [interface-name] command.
ipsec:route-set=prefix prefix/length
This Cisco AV pair specifies an IPv4 subnet protected by FlexVPN server and is pushed to the peer using the INTERNAL_IP4_SUBNET attribute.
ipsec:route-set=remote ipv4 address mask
This Cisco AV pair specifies an IPv4 subnet protected by FlexVPN server and is pushed to the peer, using the INTERNAL_IP4_SUBNET attribute. This attribute can be configured in the IKEv2 authorization policy using the route set remote ipv4 address mask command.
ipsec:route-set=remote ipv6 prefix/length
This Cisco AV pair specifies an IPv6 subnet protected by FlexVPN server and is pushed to the peer using the INTERNAL_IP6_SUBNET attribute. This attribute can be configured in the IKEv2 authorization policy, using the route set remote ipv6 prefix/length command.
ipsec:dns-servers=ipv4-address1[ipv4-address2]
This Cisco AV pair specifies the IPv4 addresses of the primary and the secondary DNS servers that are pushed to the client using the INTERNAL_IP4_DNS attributes. This attribute can be configured in the IKEv2 authorization policy, using the dns ipv4-address1[ipv4-address2] command.
ipsec:wins-servers=ipv4-address1[ipv4-address2]
This Cisco AV pair specifies the IPv4 addresses of the primary and the secondary WINS servers that are pushed to the client using the INTERNAL_IP4_NBNS attributes. This attribute can be configured in the IKEv2 authorization policy, using the wins ipv4-address1[ipv4-address2] command.
ipsec:route-set=access-list acl-name | acl-number
This Cisco AV pair specifies an IPv4 access list defined on the FlexVPN server listing the IPv4 subnets protected by FlexVPN server that are pushed to the peer, using the INTERNAL_IP4_SUBNET attribute. This attribute can be configured in the IKEv2 authorization policy, using the route set access-list {acl-name | acl-number} command.
ipsec:route-set=access-list ipv6 acl-name
This Cisco AV pair specifies an IPv6 access list defined on the FlexVPN server listing the IPv6 subnets protected by FlexVPN server that are pushed to the peer, using the INTERNAL_IP6_SUBNET attribute. This attribute can be configured in the IKEv2 authorization policy, using the route set access-list ipv6 acl-name command.
ipsec:addrv6=ipv6-address
This Cisco AV pair specifies the IPv6 address that is assigned to a remote access client, using the INTERNAL_IP6_ADDRESS configuration attribute. This attribute is an IPv6 equivalent of the Framed-IP-Address IETF attribute.
ipsec:prefix-len=length
This Cisco AV pair specifies the prefix length of the IPv6 address assigned to the client. This attribute is pushed to client, using the INTERNAL_IP6_ADDRESS configuration attribute in the last (17th) byte. This attribute is an IPv6 equivalent of the Framed-IP-Netmask IETF attribute.
ipsec:ipv6-dns-servers-addr=ipv6-address1 [ipv6-address2]
This Cisco AV pair specifies the IPv6 addresses of the primary and the secondary DNS servers that are pushed to the client, using the INTERNAL_IP6_DNS attribute. This attribute can be configured in the IKEv2 authorization policy, using the ipv6 dns ipv6-address1[ipv6-address2] command.
The following are the Cisco AV pair RADIUS attributes that are pushed by the FlexVPN server only to the Cisco clients such as FlexVPN and AnyConnect clients, using the Cisco proprietary unity configuration attributes. These attributes can be configured in the IKEv2 authorization policy as well.
ipsec:default-domain=domain-name
ipsec:split-dns=name
ipsec:ipsec-backup-gateway=name
ipsec:pfs=value
ipsec:include-local-lan=value
ipsec:smartcard-removal-disconnect=value
ipsec:configuration-url=url
ipsec:configuration-version=version
Remote Access Clients Supported by FlexVPN Server
FlexVPN server supports the following IKEv2 remote access clients:
FlexVPN remote access client
Cisco IKEv2 AnyConnect client
Microsoft Windows7 IKEv2 Client
Linux Strongswan IKEv2 client
FlexVPN Remote Access Client
The FlexVPN remote access client is a Cisco IOS based hardware client described in Chapter 10 “FlexVPN client.”
Microsoft Windows7 IKEv2 Client
The Microsoft Windows 7 IKEv2 client sends an IP address as the Internet key exchange (IKE) identity that prevents the Cisco IKEv2 FlexVPN server from segregating remote users based on the IKE identity. To allow the Windows 7 IKEv2 client to send the email address (user@domain) as the IKE identity, apply the hotfix documented in KB975488 (http://support.microsoft.com/kb/975488) on Microsoft Windows 7 and specify the email address string in either the Username field when prompted or the CommonName field in the certificate depending on the authentication method.
For certificate-based authentication, the FlexVPN server and Microsoft Windows 7 client certificates must have an extended key usage (EKU) field as follows:
For the client certificate, EKU field = client authentication certificate
For the server certificate, EKU field = server authentication certificate
For EAP authentication, the Microsoft Windows 7 IKEv2 client expects an EAP identity request before any other EAP requests. Hence the query-identity option must be specified when configuring EAP as a remote authentication method in the IKEv2 profile, using authentication remote eap command, in order for the FlexVPN server to send an EAP identity request to the client.
Cisco IKEv2 AnyConnect Client
For certificate-based authentication, the FlexVPN server and the AnyConnect client certificates must have an extended key usage (EKU) field as follows:
For the client certificate, EKU field = client authentication certificate
For the server certificate, EKU field = server authentication certificate
If the FlexVPN server authenticates to an AnyConnect client using certificates, a SubjectAltName extension is required in the FlexVPN server certificate that contains the server’s IP address or fully qualified domain name (FQDN). Additionally, HTTP certified URLs must be disabled on the FlexVPN server using the no crypto ikev2 http-url cert command.
The FlexVPN server supports the following features only with the AnyConnect client:
IKEv2 auto-reconnect
User authentication using AnyConnect-EAP
Dual-factor authentication using AnyConnect-EAP
Summary
This chapter introduced the Cisco IOS FlexVPN server and then explained the various features supported by the FlexVPN server. The chapter started with an overview of the sequence of events on the FlexVPN server and then delved into the details of EAP authentication, AAA-based pre-shared keys and AAA accounting, and RADIUS PoD and CoA features. It explained the flow of messages between the client, server, and the RADIUS server. The chapter then explained the features that are specific to AnyConnect client, such as IKEv2 auto-reconnect and user and dual-factor authentication using the AnyConnect-EAP method. The chapter concluded with the RADIUS attributes and the clients supported by FlexVPN server.
Reference
https://tools.ietf.org/html/rfc2866 RADIUS Accounting.