Chapter 8. Introduction to FlexVPN
This chapter introduces the Cisco IOS FlexVPN solution. The chapter discusses the FlexVPN building blocks, builds on the foundational IKEv2 configuration covered in the earlier chapters, and explains the concepts and configurations relevant to FlexVPN. The chapter lays the foundation for the FlexVPN server and FlexVPN client chapters.
The chapter covers the following main topics
FlexVPN configuration exchange
FlexVPN Overview
FlexVPN is a robust, standards-based VPN technology that enables large businesses to securely connect branch offices and remote users. It provides significant cost savings compared to the cost of supporting multiple separate types of virtual private network (VPN) solutions such as GRE (generic routing encapsulation), crypto map, and virtual tunnel interface (VTI)-based solutions. FlexVPN relies on open-standards-based IKEv2 as a security technology and provides a number of Cisco-specific enhancements to provide high levels of security, added value, and competitive differentiations.
FlexVPN is supported on Cisco Integrated Services Router Generation 2 (ISR G2) platforms running IOS and Aggregation Services Routers (ASR 1000) running IOS-XE, including Cloud Services Router 1000v (CSR 1000v) and ISR4000 series routers. Cisco AnyConnect is supported as a client, in addition to any compatible third-party client.
The Rationale
Over the years, Cisco IPsec VPN solutions have evolved from crypto maps to tunnel protection as listed:
Static crypto maps
Dynamic crypto maps
Legacy EzVPN (Easy VPN) based on crypto maps
GRE interfaces with crypto maps on WAN interface
GRE interfaces with tunnel protection
IPsec VTI (virtual tunnel interface): static and dynamic VTI
DMVPN (dynamic multipoint VPN)
Enhanced EzVPN based on IPsec VTI
GET VPN (group encrypted transport VPN)
Because each solution serves different purposes, those different features were developed relatively independently, each with their own configuration constructs, show commands, underlying interface infrastructure, and feature sets while sharing the basic building blocks of ISAKMP and IPsec. An example of this divergence is that while DMVPN predominantly uses multipoint GRE interfaces, supports dynamic overlay routing, and does not support AAA (authentication, authorization, and accounting) and per-user or per-peer policy out of the box, EzVPN uses point-to-point IPsec VTI interfaces, integrates with AAA, and supports per-user or per-peer policy but does not support dynamic overlay routing. This separation and divergence has several drawbacks, notably in terms of learning curve and ease of troubleshooting due to the various concepts and commands involved. It is difficult to configure the various IPsec VPN solutions on a single device.
The IKEv2 protocol brought together a lot of functionalities that were earlier defined in multiple RFCs. The introduction of IKEv2 into Cisco IOS was used as an opportunity to unify the different VPN solutions, bringing all solutions under the same configuration and basic building blocks, and making available all the protocol functionalities and features to all VPN topologies. This resulted in FlexVPN.
With the exception of GET VPN that essentially does not create a VPN but provides encryption services to an existing layer-3 VPN, such as MPLS (multiprotocol label switching), FlexVPN encompasses all previous IPsec VPN functionality.
FlexVPN is supported by a vastly improved framework based on the IKEv2 standard, point-to-point tunnel interfaces, and the AAA framework.
FlexVPN Value Proposition
FlexVPN is an IKEv2-based unified Cisco IOS VPN solution that caters to multiple VPN topologies. The key value proposition of FlexVPN is the unified user interface, underlying infrastructure and features across the VPN topologies. Some of the benefits of FlexVPN are:
Standards-based, interoperable with non-Cisco IKEv2 implementations
Support for multiple VPN topologies such as point-to-point, remote-access, hub-spoke, and dynamic mesh
Multiple VPN technologies under one command line interface (CLI)
Reduction in training to learn multiple VPN technologies
Unified configuration and show commands, underlying interface infrastructure, and features across the supported VPN topologies
Support for per-user or per-peer policy
Support for dynamic overlay routing
Integration with Cisco IOS AAA infrastructure
Support for GRE and native IPsec encapsulations with auto-detection of encapsulation protocol
Support for IPv4 and IPv6 overlay and underlay with auto-detection of IP transport type
FlexVPN Building Blocks
This section discusses the main building blocks that FlexVPN is based upon
IKEv2
Cisco IOS point-to-point (P2P) tunnel interfaces
Cisco IOS AAA infrastructure
IKEv2
FlexVPN is based on IKEv2 and hence brings all the IKEv2 protocol features such as configuration exchange, IKEv2 redirect for server load balancing, cookie challenge for DoS mitigation, NAT traversal, IKEv2 fragmentation, and Cisco IOS IKEv2 features, such as IKEv2 call admission control, session deletion on certificate expiry, or revocation to all the supported VPN topologies. FlexVPN makes use of the IKEv2 configuration exchange in order to exchange policy parameters between peers (typically between FlexVPN client and server) and to exchange routing information between peers. It adds routes to remote overlay addresses and protected subnets and serves as a lightweight overlay routing mechanism.
Cisco IOS Point-to-Point Tunnel Interfaces
FlexVPN uses per-peer point-to-point (P2P) tunnel interfaces for all the supported VPN topologies with either GRE or native IPsec encapsulation. GRE encapsulation offers the benefit of native support for IP dual stack because it can carry both IPv4 and IPv6 overlay traffic over either IPv4 or IPv6 transport, compared to native IPsec encapsulation that can carry either IPv4 or IPv6 overlay traffic over either IPv4 or IPv6 transport and is useful for interoperating with implementations that do not support GRE. The P2P tunnel interface is statically configured on FlexVPN initiators and is dynamically instantiated from a virtual-template interface on FlexVPN responders. Table 8-1 lists the point-to-point tunnel interface types used by FlexVPN.
Configuring Static P2P Tunnel Interfaces
On initiators, the IPsec Security Associations (SAs) originate from an IPsec interface. With FlexVPN, the IPsec interface is a tunnel interface with tunnel protection applied. The IPsec parameters used in the SA negotiation are derived from the tunnel interface configuration and especially the tunnel encapsulation mode determines the IPsec Security Association traffic selectors. Table 8-2 shows the tunnel encapsulation modes and the corresponding outbound IPsec Security Association negotiation parameters on an initiator.
Table 8-2 Tunnel Encapsulation Modes and the outbound IPsec Security Association Parameters on Initiator
Note that the ipv4 or ipv6 keyword, used with tunnel mode command, determines if the tunnel source and destination address is IPv4 or IPv6.
The following are the P2P tunnel interface commands on an initiator that determine the outbound IPsec Security Association negotiation parameters.
The tunnel mode command determines the encapsulation protocol and the transport IP address family (IPv4 or IPv6). The addresses specified in tunnel source and tunnel destination commands must match this IP address family.
The tunnel source address is typically the address of the WAN interface. When there are multiple WAN interfaces, it can be a loopback interface IP address that can be reached through all the WAN transports.
The ip address and ipv6 address commands determine the overlay IP address family (IPv4 or IPv6) i.e whether the interface can support IPv4 and/or IPv6 overlay traffic.
The vrf forwarding command specifies the IVRF (overlay VRF). The tunnel vrf command specifies the FVRF (transport VRF).
The tunnel protection command enables IPsec on the interface and specifies the IPsec protection profile.
The following example illustrates the configuration of a P2P GRE tunnel interface with IPv4 transport, where the tunnel source and tunnel destination addresses are IPv4. Note that tunnel mode gre ip is not displayed in the running configuration as it is the default. The interface is enabled for both IPv4 and IPv6 overlay traffic as it is configured with both IPv4 and IPv6 addresses.
interface tunnel1
vrf forwarding ivrf_1
ip address 192.168.1.1 255.255.255.0
ipv6 address 2001::1:1/120
tunnel source Ethernet0/0
tunnel destination 192.168.2.1
tunnel vrf fvrf_1
tunnel protection ipsec profile default
end
Router#show interfaces tunnel 1 | include Tunnel protocol/transport
Tunnel protocol/transport GRE/IP
The other encapsulation modes and transport types can be configured on the tunnel interface as follows:
Router(config)#interface tunnel 1
Router(config-if)#tunnel mode gre ?
ip over IP
ipv6 over IPv6
Router (config-if)#tunnel mode ipsec ?
ipv4 over IPv4
ipv6 over IPv6
Configuring Virtual-Template Interfaces
On a responder, the IPsec Security Association terminates on an IPsec interface, which in the case of FlexVPN is a tunnel interface with tunnel protection applied. The tunnel interface configuration and especially the tunnel encapsulation mode determine the incoming IPsec Security Associations proposals that an interface can accept. Table 8-3 shows the tunnel encapsulation modes and the incoming IPsec Security Association proposals that an IPsec interface can accept.
Table 8-3 Tunnel Encapsulation Modes and Acceptable IPsec Security Association Proposals on Responder
Note that the ipv4 or ipv6 keyword used with tunnel mode command determines if the tunnel source and destination addresses are IPv4 or IPv6.
On the responder a P2P tunnel interface is dynamically instantiated for every incoming IKEv2/IPsec session. This interface is known as a virtual-access interface that derives its configuration from the virtual-template interface of type tunnel configured in the IKEv2 profile associated with that incoming session. Note that the virtual-access interface can optionally derive its configuration from AAA that is obtained as part of user and/or group authorization described later in the chapter.
The following are the virtual-template configurations that determine the incoming IPsec SA proposals, that the cloned virtual-access interfaces can accept:
The tunnel mode command specifies the encapsulation protocol and the transport IP address family (IPv4 or IPv6). The IPsec Security Association source and destination addresses in the incoming proposal must match this IP address family. The encapsulation mode determines the acceptable IPsec Security Association traffic selectors.
The tunnel destination command must not be configured on a virtual-template. The cloned virtual-access interface derives its tunnel destination address from the source address of the incoming IPsec Security Association proposal.
The tunnel source command may optionally be configured on a virtual-template, and when configured, it must match the destination address of the incoming IPsec Security Association proposal. Note that on a mismatch, the negotiation is aborted. When not configured, the cloned virtual-access interface derives the tunnel source address from the destination address of the incoming IPsec Security Association proposal.
The ip unnumbered and ipv6 unnumbered commands determine the overlay IP address family (IPv4 or IPv6)—and therefore determine if the cloned virtual-access interface can support IPv4 and/or IPv6 overlay traffic.
The vrf forwarding command specifies the IVRF (overlay VRF), and the tunnel vrf command specifies the FVRF (transport VRF).
The tunnel protection command enables IPsec on the interface and specifies the IPsec protection profile.
Note that the IP address on a virtual-template must be configured, using ip unnumbered interface and/or ipv6 unnumbered interface commands. All the cloned virtual-access interfaces inherit these commands, which indicate that the IP address is borrowed from the specified interface and reused. This is required as Cisco IOS does not allow the same IP subnet to be configured, using ip address and ipv6 address commands to be used on more than one interface. In other words, if a virtual-template had the IP addresses configured using ip address and ipv6 address commands, the cloning of these commands on the instantiated virtual-access interfaces would fail with the error “% subnet overlaps with Virtual-Template n.”
The following example shows the configuration of a virtual-template interface of type tunnel with encapsulation mode of P2P GRE and transport type IPv4. The tunnel mode gre ip is not displayed in the running configuration because it is the default. Note that tunnel source and tunnel destination commands are not configured. The interface is enabled for both IPv4 and IPv6 overlay traffic because it has configured both IPv4 and IPv6 addresses. The virtual-template must be referenced from the IKEv2 profile.
crypto ikev2 profile ikev2_profile
virtual-template 1
interface virtual-template1 type tunnel
ip unnumbered Ethernet0/0
ipv6 unnumbered Ethernet0/0
tunnel protection ipsec profile default
Router#show interfaces virtual-template 1 | include Tunnel protocol
Tunnel protocol/transport GRE/IP
The other encapsulation modes and transport types can be configured on the virtual-template as follows:
Router(config)#interface virtual-template 1 type tunnel
Router(config-if)#tunnel mode gre ?
ip over IP
ipv6 over IPv6
Router (config-if)#tunnel mode ipsec ?
ipv4 over IPv4
ipv6 over IPv6
Auto-Detection of Tunnel Encapsulation and Transport
FlexVPN supports automatic detection of tunnel encapsulation mode and transport IP protocol type on responders, such as the FlexVPN server, that enables them to support initiators using multiple encapsulation modes and transport IP types, using a single virtual-template interface. The auto-detect mode is configured in the IKEv2 profile that overrides the configuration obtained from the virtual-template. The cloned virtual-access interfaces instead derive the encapsulation modes and transport IP types from the incoming IPsec Security Association proposal. The following example shows tunnel encapsulation and transport auto-detection configuration.
Router(config)#crypto ikev2 profile ikev2_profile
Router(config-ikev2-profile)#virtual-template 1 ?
mode Enabling Tunnel Auto Mode
<cr>
Router(config-ikev2-profile)#virtual-template 1 mode ?
auto Auto - Enable Auto feature on the ike profile
Router(config-ikev2-profile)#virtual-template 1 mode auto
Warning! Mode auto takes precedence over the mode configured on the
Virtual-Template
The following example shows cloning of virtual-access interface from a virtual-template, including the IKEv2 profile and virtual-template configuration.
crypto ikev2 profile default
match identity remote any
authentication local pre-share
authentication remote pre-share
keyring local ikev2_keyring
virtual-template 1 mode auto
interface Virtual-Template1 type tunnel
ip unnumbered Ethernet0/0
tunnel protection ipsec profile default
Following is selected output from debug crypto ikev2 and debug vtemplate cloning logs illustrating the cloning of virtual-access from virtual-template:
IKEv2:(SESSION ID = 17,SA ID = 1):Processing IKE_AUTH message
IKEv2:% DVTI create request sent for profile default with PSH index 1.
%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to
down
VT[Vi1]:Clone Vaccess from Virtual-Template1 (96 bytes)
VT[Vi1]:tunnel mode ipsec ipv6
VT[Vi1]:tunnel protection ipsec profile default
VT[Vi1]:end
IKEv2:% DVTI Vi1 created for profile default with PSH index 1.
The following show crypto session command output shows that the crypto session is associated with the virtual-access interface as highlighted:
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: 15
IKEv2 SA: local 172.16.2.1/500 remote 172.16.1.1/500 Active
IPSEC FLOW: permit 47 host 172.16.2.1 host 172.16.1.1
Active SAs: 2, origin: crypto-map
The following show command output illustrates the virtual-access configuration partly derived from virtual-template and partly derived from the incoming IPsec session. Note that the ‘tunnel source’ and ‘tunnel destination’ addresses are derived from the destination and source addresses in the incoming IPsec proposal.
Router#show derived-config interface virtual-access 1
Building configuration...
Derived configuration : 218 bytes
interface Virtual-Access1
ip unnumbered Ethernet0/0
tunnel source 172.16.2.1
tunnel destination 172.16.1.1
tunnel protection ipsec profile default
no tunnel protection ipsec initiate
end
Benefits of Per-Peer P2P Tunnel Interfaces
As we have seen, FlexVPN uses a dedicated P2P tunnel interface for every session or peer. Most of the Cisco IOS features are interface-centric. That means the features are applied on an interface such as quality of service (QoS), access control List (ACL), and firewall. A key advantage of using a per-peer or per-session interface is that all the interface features become available on a per-peer basis without requiring any additional feature specific implementation that is required with multipoint interfaces. For example, a different QoS policy or ACL can be used for every peer by just configuring the QoS policy or ACL on the interface associated with that peer.
Because of per-peer P2P tunnel interface, FlexVPN allows multiple peers to be situated behind the same network address port translation (NAPT) device even when multiple peers have the same public address and/or same private address. This is currently not possible with DMVPN that uses multipoint interfaces.
Cisco IOS AAA Infrastructure
Cisco IOS AAA infrastructure provides an abstracted framework for authentication, authorization, and accounting using the local database or external AAA servers that hold the authentication credentials, authorization policy parameters and accounting data in a way that is transparent to the AAA clients. Please refer Cisco IOS AAA documentation available at http://www.cisco.com/ for further details. FlexVPN registers as an AAA client and leverages AAA for EAP authentication, AAA-based pre-shared keys, user and group authorization policy, and accounting. Table 8-4 lists the FlexVPN AAA operations and the AAA databases supported for each.
The steps to configure AAA for FlexVPN are:
Step 1. Enable AAA, using the aaa new-model command.
Step 2. Define AAA method list that specifies an ordered list of AAA databases (local AAA database and external AAA servers) to be used for authentication, authorization, and accounting. Note that the next database in the ordered list is tried only if the previous database is not reachable and not if it returns a failure.
Step 3. If the method list specifies external AAA server groups, define the server groups and the servers.
Step 4. If the method list specifies local AAA database, configure the local AAA database for FlexVPN using the crypto ikev2 authorization policy command.
Step 5. Reference the AAA method list from the IKEv2 profile.
Configuring AAA for FlexVPN
The following example illustrates the configuration of AAA for FlexVPN. Note that the IKEv2 authorization policy configured, using crypto ikev2 authorization policy command, is the local AAA database for FlexVPN. The authorization policy supports all the policy attributes that can be defined on a remote authentication dial-in user service (RADIUS) server. The policy attributes can be defined through sub-commands and/or through an AAA attribute list.
Step 1. Enable AAA.
aaa new-model
Step 2. Define the AAA method lists for authentication, authorization, and accounting as needed.
aaa authentication login authen_list_radius group radius_group
aaa authorization network author_list_local local
aaa authorization network author_list_radius group radius_group
aaa accounting network acc_list_radius group radius_group
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 local AAA database for FlexVPN.
crypto ikev2 authorization policy author_policy
route set interface
route accept any
pool ip_address_pool
aaa attribute list attr_list
Step 6. Define the AAA attribute list.
aaa attribute list attr-list1
attribute type interface-config "ip mtu 1100"
attribute type interface-config "tunnel key 10"
Step 7. Configure FlexVPN authentication, authorization, and accounting in the IKEv2 profile as needed.
crypto ikev2 profile ikev2_profile
aaa authentication eap authen_list_radius
aaa authorization user cert list author_list_radius user1
aaa authorization group cert list author_list_local author_policy
aaa accounting cert acc_list_radius
IKEv2 Name Mangler
The IKEv2 name mangler extracts a name string from the authenticated peer IKE identity string. The extracted name string is used as an AAA username with AAA authorization to perform policy lookup for the peer.
The name mangler offers the flexibility to perform AAA-based policy lookup for the peer based on arbitrary portions of the peer IKE identities of various types. The name mangler is referenced from the IKEv2 profile specifically from the aaa authorization and keyring aaa commands that use AAA authorization for policy lookup.
Note that because AAA-based policy lookup must be based on an authenticated peer IKE identity, AAA authorization and hence the name mangler invocation is performed after peer authentication. When invoked, the name mangler takes an IKE identity string as input and outputs a name string based on the extraction rule configured in the name mangler for that identity type. Figure 8-1 illustrates the functionality provided by the IKE2 name mangler.
Configuring IKEv2 Name Mangler
The IKEv2 name mangler is created using the following command in the router global configuration mode.
crypto ikev2 name-mangler name_mangler
Once the name mangler is created, the router command prompt will change from (config) to (config-ikev2-name-mangler), denoting that user is in IKEv2 name mangler submode.
Table 8-5 shows the IKE identity types that can be configured in the IKEv2 name mangler.
The following example illustrates configuring an IKEv2 name mangler. The name mangler can have multiple identity statements, one of each type, and this allows the same name mangler to be used with multiple peers with different IKE identities.
Router(config-ikev2-name-mangler)#?
IKEv2 name mangler commands:
dn Derive name from DN identity
eap Derive name from EAP identity
email Derive name from EMAIL identity
fqdn Derive name from FQDN identity
Router#show run | begin name-mangler
crypto ikev2 name-mangler name_mangler
fqdn hostname
email domain
dn common-name
eap all
The name mangler must be referenced from the IKEv2 profile as part of the aaa authorization and keyring aaa commands. The same name mangler can be referenced from multiple commands in the IKEv2 profile.
crypto ikev2 profile ikev2_profile
keyring aaa aaa_method_list name-mangler name_mangler
aaa authorization group psk list aaa_list name-mangler name_mangler
aaa authorization user psk list aaa_list name-mangler name_mangler
The name mangler must be dereferenced from the IKEv2 profile before it can be deleted:
Router(config)#no cryto ikev2 name-mangler name_mangler
% Cannot remove as name mangler is in use.
Extracting Name from FQDN Identity
The name mangler can be configured to extract the name string for AAA policy lookup from the hostname or domain portions of the peer FDQN identity string or the entire identity string. Table 8-6 lists the IKEv2 name mangler commands to extract the name from the FQDN identity.
Extracting Name from Email Identity
The name mangler can be configured to extract the name string for AAA policy lookup from the username or domain portions of the peer email identity string or the entire identity string. Table 8-7 lists the IKEv2 name mangler commands to extract name from the email identity.
Extracting Name from DN Identity
The name mangler can be configured to extract the name string for AAA policy lookup from a portion of the peer DN identity string or the entire identity string. Table 8-8 lists the IKEv2 name mangler commands to extract name from the DN identity.
Extracting Name from EAP Identity
The name mangler can be configured to extract the name string for AAA policy lookup from a portion of the peer extensible authentication protocol (EAP) identity string or the entire identity string. Table 8-9 lists the IKEv2 name mangler commands to extract name from the EAP identity. The format of EAP identity depends on the EAP method.
IKEv2 Authorization Policy
The IKEv2 authorization policy is FlexVPN’s local AAA database that is used with FlexVPN authorization. The authorization policy supports all the policy attributes that can be defined on an external AAA server. The list of all the FlexVPN AAA attributes and their description is covered in Chapter 9 “FlexVPN Server.” The following example illustrates configuring an IKEv2 authorization policy along with its use with FlexVPN authorization.
The IKEv2 authorization policy is defined using the crypto ikev2 authorization policy command in the router global configuration mode. The policy attributes are defined using subcommands and/or through a AAA attribute list.
Router(config)#crypto ikev2 authorization policy ikev2_author_policy
Router(config-ikev2-author-policy)#?
IKEv2 authorization policy commands:
aaa Specify aaa attribute list
backup-gateway Specify backup gateway
banner Specify mode config banner
configuration Push configuration to the client
def-domain Set default domain name to send to client
dhcp Specify DHCP server for config address
assignment
dns Specify DNS Addresses
exit Exit from crypto ikev2 author policy sub mode
include-local-lan Enable Local LAN Access with no split tunnel
ipsec Specify ipsec parameters
ipv6 Specify the ipv6 attributes
mobileopt-serv Specify Mobile Optimization Server Addr and
Port
netmask Specify netmask of the config address
no Negate a command or set its defaults
pfs The client should propose PFS
pool Specify local address pool
route Specify route parameters
session-lifetime Specify maximum session lifetime
smartcard-removal-disconnect Enables smartcard-removal-disconnect
split-dns Split DNS names
wins Specify WINS Addresses
The policy attributes can also be defined, using an AAA attribute list that can be referenced from the IKEv2 authorization policy.
Router(config-ikev2-author-policy)#aaa attribute list ?
WORD AAA attribute list name
The AAA attribute list supports all the RADIUS attributes, however they must be configured in the Cisco IOS AAA format. Use the show aaa attribute protocol radius command to get the Cisco IOS AAA format of the RADIUS attributes. Please refer Cisco IOS documentation for “AAA attribute list” for further details.
aaa attribute list attr-list1
attribute type interface-config "ip mtu 1100"
attribute type interface-config "tunnel key 10"
The following example illustrates the AAA commands required along with the IKEv2 authorization policy, and referencing the policy from IKEv2 profile.
Configure AAA method lists for authorization, using local AAA database.
aaa new-model
aaa authorization network aaa_list1 local
Configure FlexVPN authorization in the IKEv2 profile as highlighted in the following example.
crypto ikev2 profile default
match identity remote any
identity local dn
authentication local pre-share
authentication remote pre-share
aaa authorization group psk list aaa_list1 ikev2_author_policy
aaa authorization user psk list aaa_list1 ikev2_author_policy
Note that, during FlexVPN authorization based on local AAA database, the IKEv2 authorization policies are looked up based on the name string specified in the aaa authorization group command or based on the name string extracted from the peer IKE identity by the name mangler specified in the command.
The configured and the default IKEv2 authorization policies can be displayed, using the show crypto ikev2 authorization policy command.
Router#show crypto ikev2 authorization policy
IKEv2 Authorization Policy : default
route set interface
route accept any tag : 1 distance : 1
IKEv2 Authorization Policy : ikev2_author_policy
IPV4 Address Pool : ip-addr-pool
IPv4 DNS Primary : 192.168.10.10
route accept any tag : 1 distance : 1
Default IKEv2 Authorization Policy
The default IKEv2 authorization policy consists of commonly used attributes. The default policy must be referenced from the aaa authorization commands in the IKEv2 profile. The default policy can be disabled or modified to address the specific needs of users after which it is displayed in the running configuration. The default authorization policy is used by most customers without amendments, The following example shows disabling, modifying, and restoring of default IKEv2 authorization policy.
The default IKEv2 authorization policy can be displayed, using the following commands.
Router#show run all | section ikev2 authorization policy
crypto ikev2 authorization policy default
route set interface
route accept any
Router#show crypto ikev2 authorization policy default
IKEv2 Authorization Policy : default
route set interface
route accept any tag : 1 distance : 1
The route set interface command will advertise the IP address through the configuration payload that is obtained from the tunnel or virtual-access interface or from the specified interface. The route accept any command will install any prefixes sent from the peer, using configuration payload.
The default IKEv2 authorization policy is disabled, using the following command:
Router(config)#no crypto ikev2 authorization policy default
Router#show run | include ikev2 authorization policy default
no crypto ikev2 authorization policy default
Router#show crypto ikev2 authorization policy default
IKEv2 Authorization Policy : default Disabled
The default authorization policy is re-enabled, using the following command:
Router(config)#default crypto ikev2 authorization policy
The default authorization policy is modified as shown in the following code, after which it is displayed in running configuration.
Router(config)#crypto ikev2 authorization policy default
%Warning: This will Modify Default IKEv2 Authorization Policy. Exit if you don't
want
Router(config-ikev2-author-policy)#pool ip-address-pool
Router(config-ikev2-author-policy)#dns 192.168.6.10
Router#show run | begin ikev2 authorization policy default
crypto ikev2 authorization policy default
pool ip-address-pool
dns 192.168.6.10
Router#show crypto ikev2 authorization policy default
IKEv2 Authorization Policy : default
IPV4 Address Pool : ip-address-pool
IPv4 DNS Primary : 192.168.6.10
route set interface
route accept any tag : 1 distance : 1
The modified default authorization policy can be restored as follows:
Router(config)#default crypto ikev2 authorization policy
FlexVPN Authorization
FlexVPN authorization provides policy attributes for an IKEv2/IPsec session based on the authenticated peer IKE identity. FlexVPN uses either the local AAA database or an external AAA server to store the policy and uses AAA authorization for policy lookup. The policy obtained using AAA authorization consists of local and remote attributes. The remote attributes are pushed to the peer, using IKEv2 configuration exchange, and local attributes are applied locally to the session/interface corresponding to that peer. Implicit authorization occurs when attributes received during authentication are re-used for authorization.
Figure 8-2 illustrates FlexVPN authorization and highlights the key points that the authorization can be performed both on the FlexVPN initiator and responder and only after successful peer authentication. The AAA username used for authorization lookup is typically based on the authenticated peer IKE identity. The AAA infrastructure provides an abstracted interface to AAA database to the clients regardless of whether the database is local or external.
FlexVPN supports three types of authorization. Table 8-10 lists the FlexVPN authorization types and the AAA databases they support.
Figure 8-3 illustrates FlexVPN authorization, using a local AAA database. The IKEv2 authorization policy acts as the local AAA database for FlexVPN. IKEv2 invokes AAA with an authorization request specifying the AAA method list and the username. When the method list specifies local authorization, AAA invokes IKEv2 that looks up an IKEv2 authorization policy matching the username. After that, it returns the parameters configured under that authorization policy as AAA attributes, and then AAA returns these attributes back to IKEv2 in the authorization response.
Figure 8-4 illustrates FlexVPN authorization, using a RADIUS server as an external AAA server. IKEv2 invokes AAA with an authorization request that specifies the AAA method list and the username. When the method list specifies RADIUS-based authorization, AAA acting as a RADIUS client sends an Access-Request to the RADIUS server. The RADIUS server looks up a policy matching the specified username and returns the corresponding RADIUS attributes. AAA converts the RADIUS attributes into AAA attributes and returns them to IKEv2 in authorization response.
Configuring FlexVPN Authorization
FlexVPN authorization is configured in the IKEv2 profile, using the aaa authorization command that specifies the AAA method list and the name string to be used as the AAA username for the authorization lookup. The AAA method list specifies the AAA databases that the authorization request will look up. The authorization name string can be directly specified or can be extracted from the peer IKE identity, using an IKEv2 name mangler. Each of the three FlexVPN authorization types can be configured multiple times, one for every peer authentication method. This allows the flexibility to use a different AAA database and name string, based on the peer authentication method. The following example illustrates configuring FlexVPN authorization.
Specify the authorization type:
Router(config-ikev2-profile)#aaa authorization ?
group AAA group authorization
user AAA user authorization
Specify the peer authentication method for which this configuration would be used:
Router(config-ikev2-profile)#aaa authorization user ?
anyconnect-eap AAA list to use when IKEv2 remote auth method is anyconnect
eap based
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
override Override user authorization with group authorization. By
default, group authorization is overridden with user
authorization
psk AAA list to use when IKEv2 remote auth method is PSK
The cached keyword enables implicit authorization. Note that with implicit authorization, the AAA method list and the name string for lookup are not specified. Implicit authorization can be useful when retrieving AAA keyrings containing authorization attributes, or when EAP is used. A major benefit of implicit authorization is that a single lookup is required, compared to a separate lookup once for authentication and once for authorization.
Router(config-ikev2-profile)#aaa authorization user psk ?
cached Use cached attributes from EAP authentication or AAA pre-shared key
fetch
list AAA method list
Router(config-ikev2-profile)#aaa authorization user psk cached ?
<cr>
Specify the AAA method list:
Router(config-ikev2-profile)#aaa authorization user psk list ?
WORD AAA list name
Specify the name string to be used for authorization lookup or specify a name mangler that will extract the name from peer IKE identity:
Router(config-ikev2-profile)#aaa authorization user psk list aaa_list ?
WORD AAA username
name-mangler Specify the name-mangler to derive AAA username
password Specify the AAA password
<cr>
Router(config-ikev2-profile)#aaa authorization user psk list aaa_list
name-mangler ?
WORD mangler name
Router(config-ikev2-profile)#aaa authorization user psk list aaa_list name-mangler
name_mangler ?
password Specify the AAA password
<cr>
Specify the password to authenticate to the AAA server:
Router(config-ikev2-profile)# aaa authorization user psk list aaa_list
name-mangler name_mangler password ?
0 Specifies an UNENCRYPTED password will follow
6 Specifies an ENCRYPTED password will follow
WORD The UNENCRYPTED (cleartext) user password
FlexVPN User Authorization
FlexVPN user authorization is used to provide session policy attributes that are specific to a user. The user authorization lookup is typically based on the portion of the authenticated IKE identity that is unique to a user, such as the hostname portion of the FQDN identity. The IKEv2 name mangler is used to extract the desired portion of IKE identity for policy lookup. FlexVPN user authorization is configured in the IKEv2 profile, using the aaa authorization user command.
FlexVPN user authorization is supported with both an external AAA server and a local AAA as the policy database. However, when user authorization policy needs to be configured for a large number of users, using an external AAA server is a more scalable option.
FlexVPN User Authorization, Using an External AAA Server
The following example illustrates FlexVPN user authorization configuration, using an external AAA server. The user authorization is configured for pre-shared key and certificate-based remote authentication methods, that is, for peer authentication, using pre-shared key or certificate-based methods. Note that the two user authorization statements use a different AAA method list, pointing to a different RADIUS server and a different name mangler to obtain the name string for authorization lookup. The authorization is performed, using the user authorization statement corresponding to the peer authentication method.
aaa new-model
Step 2. Define RADIUS server groups.
aaa group server radius radius_group1
server name radius_server1
aaa group server radius radius_group2
server name radius_server2
Step 3. Define AAA method lists for authorization, using an external AAA server.
aaa authorization network aaa_list1 group radius_group1
aaa authorization network aaa_list2 group radius_group2
Step 4. Define the RADIUS servers.
radius server radius_server1
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_server1_key
radius server radius_server2
address ipv4 172.16.1.4 auth-port 1645 acct-port 1646
key radius_server2_key
Step 5. Define IKEv2 name manglers.
crypto ikev2 name-mangler name_mangler1
fqdn hostname
crypto ikev2 name-mangler name_mangler2
dn common-name
Step 6. Configure FlexVPN user authorization in the IKEv2 profile as highlighted in the following example:
crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
authentication remote rsa-sig
aaa authorization user psk list aaa_list1 name-mangler name_mangler1
aaa authorization user cert list aaa_list2 name-mangler name_mangler2
The following example illustrates the FlexVPN user authorization process during IKEv2 negotiation, using the selected output from debug crypto ikev2, debug aaa subsys, and debug radius authentication logs. The user authorization is based on the configuration shown in the previous example. The relevant debug outputs are highlighted.
Note that the peer is authenticating by using the pre-shared-key method and is using an IKE identity of type FQDN with value router1.domain1.
IKEv2:(SESSION ID = 96,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 338E72677B66C73E - Responder SPI : 4C220FBE34587D45 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:(SESSION ID = 96,SA ID = 1):Peer's authentication method is 'PSK'
IKEv2:(SESSION ID = 96,SA ID = 1):Searching policy based on peer's identity
'router1.domain1' of type 'FQDN'
IKEv2:(SESSION ID = 96,SA ID = 1):Verification of peer's authenctication data
PASSED
Note that the authorization is performed after successful peer authentication. The user authorization command corresponding to the pre-shared-key method, aaa authorization user psk, is used. The server group radius_group1 and the radius server 172.16.1.3 correspond to the specified AAA method list aaa_list1. The name string “router1” used in the authorization request and the RADIUS Access-Request is extracted from the peer FQDN identity “router1.domain” by the specified name mangler name_mangler1.
IKEv2:Using mlist aaa_list1 and username router1 for user author request
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorization request sent
AAA SRV(00000062): Author method=SERVER_GROUP radius_group1
RADIUS/ENCODE(00000062):Orig. component type = VPN IPSEC
RADIUS/ENCODE: Best Local IP-Address 172.16.1.2 for Radius-Server 172.16.1.3
RADIUS(00000062): Send Access-Request to 172.16.1.3:1645 id 1645/85, len 132
RADIUS: User-Name [1] 9 "router1"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 12 "172.16.1.1"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS(00000062): Sending a IPv4 Radius Packet
RADIUS: Received from id 1645/85 172.16.1.3:1645, Access-Accept, len 128
RADIUS: Cisco AVpair [1] 27 "ipsec:route-set=interface"
RADIUS: Cisco AVpair [1] 24 "ipsec:route-accept=any"
RADIUS: Cisco AVpair [1] 39 "ipsec:route-set=prefix 192.168.1.1/24"
AAA SRV(00000062): protocol reply PASS for Authorization
AAA SRV(00000062): Return Authorization status=PASS
IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorization response
FlexVPN Group Authorization
FlexVPN group authorization is used to provide session policy attributes that are common to a related set of peers. The group authorization lookup is typically based on the common portion of the authenticated IKE identity, such as the domain portion of the FQDN identity. The IKEv2 name mangler is used to extract the desired portion of the IKE identity for policy lookup. FlexVPN group authorization is configured in IKEv2 profile, using the aaa authorization group command.
FlexVPN group authorization is supported with both an external AAA server and a local AAA as policy database. A local AAA database is supported because the group authorization policy is common for a set of peers and hence is not likely to pose a scale problem.
FlexVPN Group Authorization, Using a Local AAA Database
The following example illustrates FlexVPN group authorization configuration, using a local AAA database. The group authorization is configured for a certificate-based remote authentication method, that is, for peer authentication, using the certificate-based method. The authorization command references an AAA method list that specifies the local AAA database. The referenced name mangler extracts the name string from the domain portion of the DN identity received from the peer.
Step 1. Enable AAA.
aaa new-model
Step 2. Define AAA method lists for authorization, using a local AAA database.
aaa authorization network aaa_list1 local
Step 3. Define IKEv2 name mangler.
crypto ikev2 name-mangler name_mangler1
dn domain
Step 4. Define an IKEv2 authorization policy which acts as a local AAA database for FlexVPN.
crypto ikev2 authorization policy domain1
route set interface
route set remote ipv4 192.168.2.0 255.255.255.0
Step 5. Configure the FlexVPN group authorization in the IKEv2 profile as highlighted in the following example:
crypto ikev2 profile default
match identity remote any
identity local dn
authentication local rsa-sig
authentication remote pre-share
authentication remote rsa-sig
pki trustpoint ca_server1
aaa authorization group cert list aaa_list1 name-mangler name_mangler1
The following example illustrates the FlexVPN group authorization process during the IKEv2 negotiation using the selected output from debug crypto ikev2, debug crypto ikev2 internal, and debug aaa subsys logs. The group authorization is based on the configuration shown in the previous example. The relevant debug outputs are highlighted.
Note that the peer is authenticating, using a certificate-based method and is using an IKE identity of type DN.
IKEv2:(SESSION ID = 42,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 91BDE56BC7C68593 - Responder SPI : 0BC460361D49F928 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:(SESSION ID = 42,SA ID = 1):Searching policy based on peer's identity 'hostn
ame=router1,cn=router1,dc=domain1' of type 'DER ASN1 DN'
IKEv2:(SESSION ID = 42,SA ID = 1):Peer's authentication method is 'RSA'
IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] Verification of signed authentication
data PASSED
Note that the authorization is performed after successful peer authentication. The group authorization command corresponding to the certificate method, aaa authorization user cert, is used. The name string domain1 used in the authorization request and to look up the IKEv2 authorization policy is extracted from the peer DN identity by the specified name mangler name_mangler1.
IKEv2:Using mlist aaa_list1 and username domain1 for group author request
AAA/AUTHOR (0x21): Pick method list 'aaa_list1'
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorization request sent
AAA SRV(00000021): process author req
AAA SRV(00000021): Author method=LOCAL
AAA/LOCAL/AUTHEN: starting
AAA/LOCAL/AUTHEN(21): authorizing crypto domain1
IKEv2-INTERNAL:IKEv2 local AAA author request for 'domain1'
AAA SRV(00000021): protocol reply PASS for Authorization
AAA SRV(00000021): Return Authorization status=PASS
IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorization response
IKEv2-INTERNAL:Received group author attributes:
route-set-interface: 1, route-set-remote-ipv4: 192.168.2.0 255.255.255.0
route-accept any tag:1 distance:1,
FlexVPN Group Authorization, Using an External AAA Server
The following example illustrates a FlexVPN group authorization configuration, using an external AAA server. The group authorization is configured for certificate-based remote authentication methods, that is, for peer authentication, using certificate-based methods. The group authorization statement references an AAA method list that specifies a RADIUS server group. The name mangler derives the name string for authorization lookup.
Step 1. Enable AAA.
aaa new-model
Step 2. Define RADIUS server groups.
aaa group server radius radius_group1
server name radius_server1
Step 3. Define AAA method lists for authorization, using external AAA server.
aaa authorization network aaa_list1 group radius_group1
Step 4. Define the RADIUS servers.
radius server radius_server1
address ipv4 172.16.1.4 auth-port 1645 acct-port 1646
key radius_server1_key
Step 5. Define IKEv2 name mangler.
crypto ikev2 name-mangler name_mangler1
dn domain
Step 6. Configure the FlexVPN group authorization in the IKEv2 profile as highlighted in the following example:
crypto ikev2 profile default
match identity remote any
identity local dn
authentication local rsa-sig
authentication remote pre-share
authentication remote rsa-sig
pki trustpoint ca_server1
aaa authorization group cert list aaa_list1 name-mangler name_mangler1
The following example illustrates FlexVPN group authorization process during the IKEv2 negotiation, using the selected output from debug crypto ikev2, debug aaa subsys, and debug radius authentication logs. The group authorization is based on the configuration shown in the previous example. The relevant debug outputs are highlighted.
Note that the peer is authenticating, using a certificate-based method and is using an IKE identity of type DN.
IKEv2:(SESSION ID = 61,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 5FC7B323505CC9F8 - Responder SPI : C8F23357295216E3 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:(SESSION ID = 61,SA ID = 1):Searching policy based on peer's identity 'hostn
ame=router1,cn=router1,dc=domain1' of type 'DER ASN1 DN'
IKEv2:(SESSION ID = 61,SA ID = 1):Peer's authentication method is 'RSA'
IKEv2:(SA ID = 1):[Crypto Engine -> IKEv2] Verification of signed authentication
data PASSED
Note that the authorization is performed after successful peer authentication. The server group radius_group1 and the radius server 172.16.1.4 correspond to the specified AAA method list aaa_list1. The name string “domain” used in the authorization request and the RADIUS Access-Request is extracted from the peer DN identity by the specified name mangler name_mangler1.
IKEv2:Using mlist aaa_list1 and username domain1 for group author request
IKEv2:(SA ID = 1):[IKEv2 -> AAA] Authorization request sent
AAA SRV(00000034): process author req
AAA SRV(00000034): Author method=SERVER_GROUP radius_group1
RADIUS/ENCODE(00000034):Orig. component type = VPN IPSEC
RADIUS/ENCODE: Best Local IP-Address 172.16.1.2 for Radius-Server 172.16.1.4
RADIUS(00000034): Send Access-Request to 172.16.1.4:1645 id 1645/19, len 132
RADIUS: authenticator BA D7 AE 45 D6 33 76 21 - 20 F8 4F 7A 4C DE E5 1D
RADIUS: User-Name [1] 9 "domain1"
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=L2L4AC1G102ZO2L4AC1G101Z
I1F401F4ZN3D"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: NAS-IP-Address [4] 6 172.16.1.2
RADIUS(00000034): Sending a IPv4 Radius Packet
RADIUS(00000034): Started 5 sec timeout
RADIUS: Received from id 1645/19 172.16.1.4:1645, Access-Accept, len 128
RADIUS: authenticator EF C6 8B 50 26 AE C2 F3 - 82 2A F1 07 B0 23 C2 ED
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"
AAA SRV(00000034): protocol reply PASS for Authorization
AAA SRV(00000034): Return Authorization status=PASS
IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorisation response
IKEv2-INTERNAL:Received group author attributes:
route-set-interface: 1, route-accept any tag:1 distance:1,
FlexVPN Implicit Authorization
When FlexVPN uses an external AAA server, such as a RADIUS server for EAP authentication or to fetch AAA-based pre-shared keys, the AAA server may return all the configured policy attributes corresponding to the username used for EAP authentication or pre-shared key lookup. These unsolicited policy attributes 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. The implicit authorization avoids the need for an explicit user authorization and saves a round trip to the external AAA server.
Figure 8-5 illustrates FlexVPN implicit authorization with EAP authentication and a RADIUS-based EAP server. When EAP authentication is successful, the RADIUS server along with the EAP-Success message returns the policy attributes corresponding to the authenticated EAP username. When caching is enabled, these policy attributes are cached and used as implicit authorization attributes.
Figure 8-6 illustrates FlexVPN implicit authorization with AAA-based, pre-shared keys hosted on a RADIUS server. When an AAA authorization request is sent to fetch the pre-shared keys for a username, the RADIUS server, along with the pre-shared keys, returns the policy attributes corresponding to the username used for the key lookup. When enabled, these policy attributes are cached and used as implicit authorization attributes.
FlexVPN Implicit Authorization Example
The following example illustrates FlexVPN implicit authorization configuration when a RADIUS server is used for storing pre-shared keys.
Step 1. Enable AAA.
aaa new-model
Step 2. Define RADIUS server group.
aaa group server radius radius_group1
server name radius_server1
Step 3. Define the AAA method lists for authorization, using an external AAA server.
aaa authorization network aaa_list1 group radius_group1
Step 4. Define the RADIUS server.
radius server radius_server1
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_server1_key
Step 5. Define the IKEv2 name mangler.
crypto ikev2 name-mangler name_mangler1
fqdn hostname
Step 6. Configure AAA-based pre-shared keys and FlexVPN implicit authorization in the IKEv2 profile as highlighted in the following example:
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 example illustrates the fetching of pre-shared keys from a AAA server, and the caching of unsolicited policy attributes received from the AAA server for FlexVPN implicit authorization, using the selected output from debug crypto ikev2, debug aaa subsys, and debug radius authentication logs. 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'
Fetch pre-shared keys from 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=L2L4AC1G102ZO2L4AC1G101Z
I1F401F4ZO3"
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: 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 symmmetric 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
FlexVPN Authorization Types: Co-existence and Precedence
The three FlexVPN authorization types namely user, group, and implicit authorization, can coexist in the IKEv2 profile and be used to fetch policy attributes for an IKEv2/IPsec session. The policy attributes obtained through each of the authorization type are merged and then applied to the session. The precedence between the authorization types comes into play when the same attribute is obtained from multiple authorization types. Figure 8-7 illustrates how authorization attributes from the different FlexVPN authorization types are merged.
Following are the steps for merging the attributes and the precedence between the authorization types.
Step 1. The user authorization attributes are merged with the implicit authorization attributes, and the former takes precedence in case of duplicate attributes. The resulting attributes are called merged user attributes.
Step 2a. The merged user attributes are then combined with group authorization attributes, and the former takes precedence in case of duplicate attributes.
Step 2b. In Step 2a, the group authorization attributes can be configured to take precedence over the merged user attributes, using the aaa authorization group override command.
Step 3. The final merged attributes from Step 2 are sent to the peer through configuration exchange and/or are applied to the peer session.
User Authorization Taking Higher Precedence
The following example illustrates the merging of attributes from FlexVPN user authorization, group authorization and implicit authorization. The user authorization attributes take precedence over group authorization attributes, and this is the default behavior. IKEv2 name manglers are used to derive the name string for each of the authorization types. The AAA-based pre-shared-key feature is used for implicit authorization and configured to use the peer FQDN identity string for key lookup. User authorization is configured to use an external AAA server and the hostname portion of the peer FQDN identity string. Group authorization is configured to use a local AAA database and the domain portion of the peer FQDN identity string.
Step 1. Enable AAA and configure AAA authorization method lists, the AAA server group, and the RADIUS server.
aaa new-model
aaa group server radius radius_group1
server name radius_server1
aaa authorization network aaa_psk_list group radius_group1
aaa authorization network user_author_list group radius_group1
aaa authorization network group_author_list local
radius server radius_server1
address ipv4 172.16.1.3 auth-port 1645 acct-port 1646
key radius_server1_key
Step 2. Configure the IKEv2 name manglers.
crypto ikev2 name-mangler aaa_psk_name_mangler
fqdn all
crypto ikev2 name-mangler user_author_name_mangler
fqdn hostname
crypto ikev2 name-mangler group_author_name_mangler
fqdn domain
Step 3. Configure IKEv2 authorization policy for group authorization.
crypto ikev2 authorization policy domain1
pool pool3
def-domain domain1
Step 4. Enable AAA-based pre-shared-keys, and user, group, and implicit authorizations.
crypto ikev2 profile default
match identity remote any
authentication local pre-share
authentication remote pre-share
keyring aaa aaa_psk_list name-mangler aaa_psk_name_mangler
aaa authorization group psk list group_author_list name-mangler
group_author_name_mangler
aaa authorization user psk cached
aaa authorization user psk list user_author_list name-mangler
user_author_name_mangler
The selected output from debug crypto ikev2 and debug crypto ikev2 internal logs illustrates the attribute merging process. The relevant output is highlighted.
Pre-shared key is fetched from the AAA server and the unsolicited attributes received are cached.
IKEv2-INTERNAL:Fetching shared secret from AAA
IKEv2-INTERNAL:Using AAA method list aaa_psk_list for peer router1.domain1
IKEv2-INTERNAL:Received symmmetric password from radius server
IKEv2-INTERNAL:Received cached attributes:
ipv4-pool: pool1, route-set-interface: 1,
Group authorization attributes are received.
IKEv2:Using mlist group_author_list and username domain1 for group author request
IKEv2-INTERNAL:Received group author attributes:
ipv4-pool: pool3, def-domain: domain1, route-accept any tag:1 distance:1,
User authorization attributes are received.
IKEv2:Using mlist user_author_list and username router1 for user author request
IKEv2-INTERNAL:Received user author attributes:
ipv4-pool: pool2, route-accept any tag:1 distance:1,
User authorization attributes are merged with implicit authorization attributes. Note that the ipv4-pool attribute is received in both user and implicit authorization, and the one from user authorization takes precedence and overrides the other.
IKEv2-INTERNAL:Merging and overriding cached attributes with user attributes
IKEv2-INTERNAL:Merged user attributes:
ipv4-pool: pool2, route-set-interface: 1, route-accept any tag:1 distance:1,
Merged user authorization attributes are merged with group authorization attributes. Note that the ipv4-pool attribute is available in both, and the one from user authorization takes precedence and overrides the other.
IKEv2-INTERNAL:Merging and overriding group attributes with user attributes
IKEv2-INTERNAL:Merged attributes:
ipv4-pool: pool2, def-domain: domain1, route-set-interface: 1, route-accept any
tag:1 distance:1,
Group Authorization Taking Higher Precedence
The following example illustrates the merging of attributes from FlexVPN user authorization, group authorization and implicit authorization. The group authorization attributes are configured to take precedence over the user authorization attributes using the aaa authorization group command with the override option. The other configuration remains the same as in the previous example.
crypto ikev2 profile default
match identity remote any
authentication local pre-share
authentication remote pre-share
keyring aaa aaa_psk_list name-mangler aaa_psk_name_mangler
aaa authorization group override psk list group_author_list name-mangler
group_author_name_mangler
aaa authorization user psk cached
aaa authorization user psk list user_author_list name-mangler
user_author_name_mangler
The selected output from debug crypto ikev2 and debug crypto ikev2 internal logs illustrates the attribute merging process. The relevant output is highlighted.
Pre-shared key is fetched from AAA server, and the unsolicited attributes received are cached.
IKEv2-INTERNAL:Fetching shared secret from AAA
IKEv2-INTERNAL:Using AAA method list aaa_psk_list for peer router1.domain1
IKEv2-INTERNAL:Received symmmetric password from radius server
IKEv2-INTERNAL:Received cached attributes:
ipv4-pool: pool1, route-set-interface: 1,
Group authorization attributes are received.
IKEv2:Using mlist group_author_list and username domain1 for group author request
IKEv2-INTERNAL:Received group author attributes:
ipv4-pool: pool3, def-domain: domain1, route-accept any tag:1 distance:1,
User authorization attributes are received.
IKEv2:Using mlist user_author_list and username router1 for user author request
IKEv2-INTERNAL:Received user author attributes:
ipv4-pool: pool2, route-accept any tag:1 distance:1,
User authorization attributes are merged with implicit authorization attributes. Note that the ipv4-pool attribute is received in both and the one from user authorization takes precedence and overrides the other.
IKEv2-INTERNAL:Merging and overriding cached attributes with user attributes
IKEv2-INTERNAL:Merged user attributes:
ipv4-pool: pool2, route-set-interface: 1, route-accept any tag:1 distance:1,
Merged user authorization attributes are merged with group authorization attributes. Note that the ipv4-pool attribute is available in both and the one from group authorization takes precedence and overrides the other.
IKEv2-INTERNAL:Merging and overriding user attributes with group attributes
IKEv2-INTERNAL:Merged attributes:
ipv4-pool: pool3, def-domain: domain1, route-set-interface: 1, route-accept any
tag:1 distance:1,
FlexVPN Configuration Exchange
The IKEv2 protocol provides a mechanism for IKEv2 peers to exchange configuration information, using the configuration payload (CP) that is typically carried in the IKE_AUTH and INFORMATIONAL exchanges. The configuration payload can be of type CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK and carries configuration attributes. The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request information from its peer, and the CFG_SET and CFG_ACK pair allows an IKE endpoint to push configuration data to its peer.
The configuration payloads are mainly used by remote-access clients to request an IP address from the remote-access server and other parameters such as DNS server, DHCP server, and so forth. The payloads are also used by IKEv2 nodes to exchange vendor-specific configuration attributes and to exchange the subnets protected by each node that determine which traffic must go through the IPsec tunnel and which traffic must not.
Enabling Configuration Exchange
Table 8-11 lists the IKEv2 profile commands that enable configuration exchange.
FlexVPN Usage of Configuration Payloads
Table 8-12 lists the IKEv2 configuration payload types and their usage in FlexVPN. Note that the configuration payloads are not sent when crypto maps are used.
Figure 8-8 illustrates FlexVPN’s usage of CFG_REQUEST and CFG_REPLY to push configuration data from FlexVPN responder to an IKEv2 initiator. The merged attributes from FlexVPN authorizations source the values for the configuration attributes sent in the CFG_REPLY.
Figure 8-9 illustrates FlexVPN’s usage of CFG_SET and CFG_ACK to push configuration data from FlexVPN responder to an IKEv2 initiator when CFG_REQUEST is not received. The merged attributes from FlexVPN authorizations source the values for the configuration attributes sent in the CFG_SET in an informational exchange.
Configuration Attributes and Authorization
The information in the configuration payload is carried in the form of TLV (type, length, value) structures known as configuration attributes. Table 8-13 lists the categories of configuration attributes supported by FlexVPN.
FlexVPN derives the values for most of the configuration attributes sent in CFG_REPLY and CFG_SET payloads from the AAA attributes obtained through FlexVPN authorization. The final merged AAA attributes from the FlexVPN authorization types are used to source the values for the configuration attributes.
Table 8-14 lists the IKEv2 standard configuration attributes supported by FlexVPN, their usage, and the corresponding AAA attributes from which their values are derived. The following table lists AAA attributes as RADIUS attributes, however most of the AAA attributes can be configured locally in the IKEv2 authorization policy as well. The RADIUS attributes supported by the FlexVPN server along with the corresponding IKEv2 authorization policy commands are listed in Chapter 9 - “FlexVPN Server”.
Following are the Cisco private use configuration attributes supported by FlexVPN. These attributes are sent in CFG_REPLY and CFG_SET only to Cisco peers. The implementation of these attributes is client and feature specific
Cisco unity attributes sent only to Cisco peers (FlexVPN client and AnyConnect)
MODECFG_BANNER
MODECFG_DEFDOMAIN
MODECFG_SPLITDNS_NAME
MODECFG_INCLUDE_LOCAL_LAN
MODECFG_PFS
MODECFG_BACKUPSERVERS
MODECFG_SMARTCARD_REMOVAL_DISCONNECT
MODECFG_SPLIT_EXCLUDE
Attribute sent only to FlexVPN client
MODECFG_CONFIG_URL
MODECFG_CONFIG_VERSION
Attribute sent only to AnyConnect client
MODECFG_ANYCONNECT_SESSION_ID
MODECFG_ANYCONNECT_SESSION_DATA
MODECFG_ANYCONNECT_SESSION_TOKEN
MODECFG_ANYCONNECT_DPD_INTERVAL
MODECFG_ANYCONNECT_CLEAN_UP_INTERVAL
MODECFG_ANYCONNECT_IP4_MOS_ADDR
MODECFG_ANYCONNECT_MOS_PORT
MODECFG_RECONNECT_CLUSTER_IP
Following is the FlexVPN behavior with respect to configuration payloads and configuration attributes.
FlexVPN responder includes INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS attributes along with the assigned IPv4/IPv6 addresses in CFG_REPLY only when these attributes are requested in CFG_REQUEST. These attributes are never sent unsolicited in CFG_REPLY.
FlexVPN responder returns INTERNAL_ADDRESS_FAILURE if the requested addresses cannot be allocated.
For attributes other than INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS requested in the CFG_REQUEST, FlexVPN responder includes the values for the requested attributes in the CFG_REPLY, if the requested attribute values are available through FlexVPN authorization. If not available, the attribute values are not included in the CFG_REPLY.
FlexVPN responder includes the attribute values obtained through FlexVPN authorization in the CFG_REPLY, even if those attributes are not requested in received CFG_REQUEST. If CFG_REQUEST is not received, these attributes are sent through CFG_SET.
FlexVPN supports dual stack with GRE encapsulation and not with native IPsec encapsulation. For clients that use dual stack over GRE such as FlexVPN and AnyConnect and that request both IPv4 and IPv6 configuration attributes in the CFG_REQUEST, both IPv4 and IPv6 attributes are included in the CFG_REPLY.
For clients that use dual stack over native IPsec, such as Microsoft Windows IKEv2 client, and that request both IPv4 and IPv6 configuration attributes in CFG_REQUEST, either IPv4 or IPv6 attributes are included in the CFG_REPLY, depending on whether the negotiated IPsec Security Association traffic selectors are IPv4 or IPv6.
FlexVPN nodes send Cisco private use configuration attributes and the standard APPLICATION_VERSION attribute only to Cisco peers determined by vendor ID.
Configuration Exchange Examples
The following example shows the exchange of configuration attributes between FlexVPN initiator and responder, using CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_SET. The relevant output from debug crypto ikev2 and debug crypto ikev2 internal is highlighted.
Following is the configuration on initiator and responder. The IKEv2 profile has configuration exchange enabled by default and has group authorization configured, using a local AAA database.
aaa new-model
aaa authorization network default local
crypto ikev2 authorization policy default
route set interface
route accept any
crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
aaa authorization group psk list default default
config-exchange set send
config-exchange set accept
config-exchange request
The following logs capture the CFG_REQUEST payload sent by the initiator in the IKE_AUTH request message.
IKEv2:Config data to send:
IKEv2:(SESSION ID = 1,SA ID = 1):Config-type: Config-request
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-dns, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-dns, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-nbns, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-nbns, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-subnet, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv6-dns, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv6-subnet, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: split-dns, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: banner, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: config-url, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: backup-gateway, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: def-domain, length: 0
IKEv2:(SESSION ID = 1,SA ID = 1):Have config mode data to send
IKEv2:(SESSION ID = 1,SA ID = 1):Sending Packet [To 172.16.1.2:500/From
172.16.1.1:500/VRF i0:f0]
Initiator SPI : F66257AAE66F66A5 - Responder SPI : 6F177E021F80071F Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
The following logs capture group authorization performed after peer authentication and the CFG_REPLY payload received by the initiator in the IKE_AUTH response message.
IKEv2:(SESSION ID = 1,SA ID = 1):Received Packet [From 172.16.1.2:500/To
172.16.1.1:500/VRF i0:f0]
Initiator SPI : F66257AAE66F66A5 - Responder SPI : 6F177E021F80071F Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
IKEv2:(SESSION ID = 1,SA ID = 1):Verification of peer's authenctication data
PASSED
IKEv2-INTERNAL:IKEv2 local AAA author request for 'default'
IKEv2:(SA ID = 1):[AAA -> IKEv2] Received AAA authorisation response
IKEv2-INTERNAL:VPN route info added for 'route set interface' attribute
IKEv2-INTERNAL:Received group author attributes:
route-set-interface: 1, route-accept any tag:1 distance:1,
IKEv2:Config data received:
IKEv2:(SESSION ID = 1,SA ID = 1):Config-type: Config-reply
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data:
10.0.0.2 255.255.255.255
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
The following logs capture the CFG_SET payload sent by the initiator in the INFORMATIONAL exchange request message. Note that the configuration attributes sent are derived from group authorization AAA attributes.
IKEv2-INTERNAL:Sending config-set
IKEv2:(SESSION ID = 1,SA ID = 1):Config-type: Config-set
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data:
10.0.0.1 255.255.255.255
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
IKEv2:(SESSION ID = 1,SA ID = 1):Sending Packet [To 172.16.1.2:500/From
172.16.1.1:500/VRF i0:f0]
Initiator SPI : F66257AAE66F66A5 - Responder SPI : 6F177E021F80071F Message id: 2
IKEv2 INFORMATIONAL Exchange REQUEST
The following logs capture the CFG_ACK payload received by the initiator in the INFORMATIONAL exchange reply message.
IKEv2:(SESSION ID = 1,SA ID = 1):Received Packet [From 172.16.1.2:500/To
172.16.1.1:500/VRF i0:f0]
Initiator SPI : F66257AAE66F66A5 - Responder SPI : 6F177E021F80071F Message id: 2
IKEv2 INFORMATIONAL Exchange RESPONSE
IKEv2:Config data received:
IKEv2:(SESSION ID = 1,SA ID = 1):Config-type: Config-ack
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-subnet, length: 0
The following logs capture group authorization performed after peer authentication and the CFG_REQUEST payload received by the responder in the IKE_AUTH request message.
IKEv2:(SESSION ID = 8,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 165DFC7D8B4DDE0A - Responder SPI : 61B417D0A611857A Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:[Crypto Engine -> IKEv2] IKEv2 authentication data generation PASSED
IKEv2:Using mlist default and username default for group author request
IKEv2-INTERNAL:Received group author attributes:
route-set-interface: 1, route-accept any tag:1 distance:1,
IKEv2:Config data received:
IKEv2:(SESSION ID = 8,SA ID = 1):Config-type: Config-request
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-dns, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-dns, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-nbns, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-nbns, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-subnet, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv6-dns, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv6-subnet, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: split-dns, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: banner, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: config-url, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: backup-gateway, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: def-domain, length: 0
IKEv2:(SESSION ID = 8,SA ID = 1):Set received config mode data
The following logs capture the CFG_REPLY payload sent by the responder in the IKE_AUTH response message. Note that the configuration attributes sent are derived from group authorization AAA attributes.
IKEv2:Config data to send:
IKEv2:(SESSION ID = 8,SA ID = 1):Config-type: Config-reply
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data:
10.0.0.2 255.255.255.255
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
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 : 165DFC7D8B4DDE0A - Responder SPI : 61B417D0A611857A Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
The following logs capture the CFG_SET payload received by the responder in the INFORMATIONAL exchange request message.
IKEv2:(SESSION ID = 8,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 165DFC7D8B4DDE0A - Responder SPI : 61B417D0A611857A Message id: 2
IKEv2 INFORMATIONAL Exchange REQUEST
IKEv2:Config data received:
IKEv2:(SESSION ID = 8,SA ID = 1):Config-type: Config-set
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data:
10.0.0.1 255.255.255.255
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
The following logs capture the CFG_ACK payload sent by the responder in the INFORMATIONAL exchange reply message.
IKEv2:Config data to send:
IKEv2:(SESSION ID = 8,SA ID = 1):Config-type: Config-ack
IKEv2:(SESSION ID = 8,SA ID = 1):Attrib type: ipv4-subnet, length: 0
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 : 165DFC7D8B4DDE0A - Responder SPI : 61B417D0A611857A Message id: 2
IKEv2 INFORMATIONAL Exchange RESPONSE
The following example illustrates that when IKE responder has configuration data to send and CFG_REQUEST is not received, the data is sent, using CFG_SET. The relevant output from debug crypto ikev2 and debug crypto ikev2 internal is highlighted.
Following is the configuration on initiator that has disabled the sending of a CFG_REQUEST.
crypto ikev2 profile default
match identity remote any
identity local fqdn router1.domain1
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
aaa authorization group psk list default default
no config-exchange request
The following logs capture group authorization performed after peer authentication and that no CFG_REQUEST payload is received by the responder in the IKE_AUTH request message.
IKEv2:(SESSION ID = 9,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 789338A336F1ACC2 - Responder SPI : 599AB29DACDBC6B5 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST
IKEv2:(SESSION ID = 9,SA ID = 1):Verification of peer's authenctication data
PASSED
IKEv2:Using mlist default and username default for group author request
IKEv2-INTERNAL:Received group author attributes:
route-set-interface: 1, route-accept any tag:1 distance:1,
The following logs capture the CFG_SET payload sent by the responder in the INFORMATIONAL exchange request message. Note that the configuration attributes sent are derived from group authorization AAA attributes.
IKEv2-INTERNAL:Sending config-set
IKEv2:(SESSION ID = 9,SA ID = 1):Config-type: Config-set
IKEv2:(SESSION ID = 9,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data:
10.0.0.2 255.255.255.255
IKEv2:(SESSION ID = 9,SA ID = 1):Attrib type: app-version, length: 277, data:
Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version
15.6(1.1)T, ENGINEERING WEEKLY BUILD, synced to V155_3_M0_2
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
IKEv2:(SESSION ID = 9,SA ID = 1):Sending Packet [To 172.16.1.1:500/From
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 789338A336F1ACC2 - Responder SPI : 599AB29DACDBC6B5 Message id: 0
IKEv2 INFORMATIONAL Exchange REQUEST
The following logs capture the CFG_ACK payload received by the responder in the INFORMATIONAL exchange reply message.
IKEv2:(SESSION ID = 9,SA ID = 1):Received Packet [From 172.16.1.1:500/To
172.16.1.2:500/VRF i0:f0]
Initiator SPI : 789338A336F1ACC2 - Responder SPI : 599AB29DACDBC6B5 Message id: 0
IKEv2 INFORMATIONAL Exchange RESPONSE
IKEv2:Config data received:
IKEv2:(SESSION ID = 9,SA ID = 1):Config-type: Config-ack
IKEv2:(SESSION ID = 9,SA ID = 1):Attrib type: ipv4-subnet, length: 0
FlexVPN Routing
FlexVPN routing allows an IKEv2 node to automatically add routes to the subnets protected by remote IKEv2 peers in order to force traffic destined to those subnets through the IPsec tunnel. FlexVPN routes are static routes to remote subnets that point to the tunnel interface associated with the remote peer and are installed programmatically in the routing table.
One of the benefits of using FlexVPN routing is the ability to remove the need to run a routing protocol to advertise prefixes. Routing protocols incur control plane overhead and are chatty in nature; this can become costly when using low-powered products that are used in IoT or links that are charged on the amount of traffic sent.
FlexVPN routes are learned locally through FlexVPN authorization as well as from the peer through configuration exchange.
The remote subnets learned locally through FlexVPN authorization are derived from the following AAA attributes:
route-set = ipv4 address mask next-hop address tag tag distance distance
route-set = ipv6 prefix/length next-hop address tag tag distance distance
The remote subnets learned from the peer through configuration exchange are derived from the following configuration attributes:
INTERNAL_IP4_SUBNET
INTERNAL_IP4_NETMASK
INTERNAL_IP4_SUBNET
Learning Remote Subnets Locally
The following example illustrates FlexVPN routes learned locally through FlexVPN authorization. The IKEv2 profile is configured with group authorization, using the local AAA database, which uses the IKEv2 authorization policy. The authorization policy is configured with the remote subnet, using the route set local command.
aaa new-model
aaa authorization network default local
crypto ikev2 authorization policy default
route set local ipv4 192.168.6.0 255.255.255.0 tag 5000 distance 5
route set interface
crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
aaa authorization group psk list default default
A single prefix is included in the route set local command above, if multiple prefixes are required this can easily be achieved by using the route set access-list command, which allows each access control entry in the ACL to specify a prefix.
The relevant output from debug crypto ikev2 and debug crypto ikev2 internal is highlighted. The remote subnet is obtained through group authorization.
IKEv2:(SESSION ID = 1,SA ID = 1):Received Packet [From 172.16.1.2:500/To
172.16.1.1:500/VRF i0:f0]
Initiator SPI : 30DCC2A72A9F875A - Responder SPI : E2FB7F51411F1A5E Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
IKEv2:(SESSION ID = 1,SA ID = 1):Verification of peer's authentication data PASSED
IKEv2-INTERNAL:IKEv2 local AAA author request for 'default'
IKEv2-INTERNAL:Received group author attributes:
route-set-interface: 1, route-set-local-ipv4: 192.168.6.0 255.255.255.0 tag 5000
distance 5 route-accept any tag:1 distance:1,
The remote subnet obtained through group authorization is programmatically installed as a static route in the routing table.
IKEv2-INTERNAL:VPN Route Added 192.168.6.0 255.255.255.0 via Tunnel0 in vrf global
The show ip route command output displays the installed route.
Router#show ip route 192.168.6.0
Routing entry for 192.168.6.0/24
Known via "static", distance 5, metric 0 (connected)
Tag 5000
Routing Descriptor Blocks:
* directly connected, via Tunnel0, permanent
Route metric is 0, traffic share count is 1
Route tag 5000
Learning Remote Subnets from Peer
The following example illustrates FlexVPN routes learned from the peer through configuration exchange. The IKEv2 profile is configured with group authorization, using the local AAA database pointing to the default IKEv2 authorization policy. It, in turn, is configured to accept CFG_SET using the route accept command.
aaa new-model
aaa authorization network default local
crypto ikev2 authorization policy default
no route set interface
route accept any
crypto ikev2 profile default
match identity remote any
authentication local pre-share key pre_shared_key
authentication remote pre-share key pre_shared_key
aaa authorization group psk list default default
The relevant output from debug crypto ikev2 and debug crypto ikev2 internal is highlighted.
IKEv2:(SESSION ID = 1,SA ID = 1):Received Packet [From 172.16.1.2:500/To
172.16.1.1:500/VRF i0:f0]
Initiator SPI : AE84121BC64D641B - Responder SPI : 89F6DA91AC2A2823 Message id: 1
IKEv2 IKE_AUTH Exchange RESPONSE
IKEv2:(SESSION ID = 1,SA ID = 1):Verification of peer's authentication data PASSED
IKEv2:Using mlist default and username default for group author request
IKEv2-INTERNAL:Received group author attributes:
route-accept any tag:1 distance:1,
The remote subnet information is received in the CFG_REPLY.
IKEv2-INTERNAL:Received config data from toolkit:
IKEv2:Config data received:
IKEv2:(SESSION ID = 1,SA ID = 1):Config-type: Config-reply
IKEv2:(SESSION ID = 1,SA ID = 1):Attrib type: ipv4-subnet, length: 8, data:
10.0.0.2 255.255.255.255
The remote subnet received in the CFG_REPLY is programmatically installed as a static route in the routing table.
IKEv2-INTERNAL:Subnet address: 10.0.0.2 255.255.255.255
IKEv2:VPN Route Added 10.0.0.2 255.255.255.255 via Tunnel0 in vrf global
The show ip route command output displays the installed route.
Router#show ip route
Gateway of last resort is not set
4.0.0.0/24 is subnetted, 1 subnets
S 4.4.4.0 is directly connected, Tunnel0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S 10.0.0.2/32 is directly connected, Tunnel0
Router#show ip route 10.0.0.2
Routing entry for 10.0.0.2/32
Known via "static", distance 1, metric 0 (connected)
Tag 1
Routing Descriptor Blocks:
* directly connected, via Tunnel0, permanent
Route metric is 0, traffic share count is 1
Route tag 1
For maximum security, the prefixes installed for a certain peer can be restricted, using the route set local command. This ensures that a malicious or misconfigured peer does not install prefixes it does not own. Since CSCuw23906 has been integrated into version 16.2, if a client requests an IP address using configuration payload, the no route accept command can be applied on the gateway to ensure that a route to the IP address assigned to the virtual-access interface is applied. However, the peer cannot push any prefixes to the gateway.
Summary
This chapter introduced the Cisco IOS FlexVPN building blocks, such as the Cisco IOS point-to-point tunnel interface and AAA infrastructure. The chapter explained how FlexVPN leverages AAA to support user, group, and implicit authorizations, using the local and external AAA databases. How the IKEv2 name mangler is used to derive the AAA username for authorization based on the peer IKE identity was also covered. The chapter then explained how the FlexVPN authorization sources the data for configuration exchange and forms the basis for FlexVPN routing. The most important point to remember from this chapter is how FlexVPN leverages the point-to-point tunnel interfaces, AAA, and IKEv2 configuration exchange to support advanced features.