Configuring, Verifying, & Troubleshooting IKEv2 Name Mangler Feature

Ok, so let's continue to build from previous FlexVPN labs/blogs. This post specifically will hit on utilizing the IKEv2 Name Mangler feature & understanding how to tie the components together to make it work. If you are not sure what the Name Mangler feature is see: IKEv2 Name Mangler Tidbit

Before we begin let's cover the building blocks on how to utilize the Name Mangler feature. The 3 main configuration blocks are as follows:

  1. Enable AAA & add AAA authorization (authz)

  2. Configure the IKEv2 name mangler

  3. Configure an IKEv2 authorization policy

  4. Attach the name mangler to IKEv2 profile

  5. Add a new match identity remote or match certificate <certmap> statement under your IKEv2 profile that you wish to match the remote IKE identity against. For our case below we match via cert map.

Note: Our lab topology is purely a point-to-point connection using two CSRs.

Step1: Enable AAA & AAA authz

aaa new-model
aaa authorization network Cifelli-Flex local

IKEv2 Authorization policies can be defined locally on the device or retrieved from a remote AAA server. In our setup we will configure local authorization. Note that using IKEv2 authorization allows us to apply authorization policies to authenticated sessions, which can be unique for each session. Lastly, there are different types which include:

  • User authorization--Use the aaa authorization user command in the IKEv2 profile to enable user authorization. User authorization is based on the user-specific portion of the peer IKE identity such as fqdn-hostname. The attributes from user authorization are called user attributes.

  • Group authorization--Use the aaa authorization group command in the IKEv2 profile to enable group authorization. Group authorization is based on the generic portion of the peer IKE identity such as fqdn-domain. The attributes from group authorization are called group attributes.

  • Implicit user authorization--Use the aaa authorization user cached command in the IKEv2 profile to enable implicit user authorization. Implicit authorization is performed as part of EAP authentication or when obtaining the AAA preshared key. The attributes from implicit user authorization are called cached attributes.

Step2: We will create our name mangler to derive the name of our peer via the common-name from the certificate used for phase 1 authentication that was referenced in other posts.

crypto ikev2 name-mangler Cifelli-NM
 dn common-name

Step3: Now let's create our IKEv2 authorization policy. Note that since we will be extracting and using the common-name (CN) as the identifier the authz policy name must match the CN for the respective peer (in our case csr4):

crypto ikev2 authorization policy 
..<excluding authz config for later labs>..

Step 4: Attach the name mangler created in Step 1 to our IKEv2 profile:

crypto ikev2 profile Cifelli-Lab
 match certificate Cifelli-Lab
 identity local dn 
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint Cifelli-Lab
 aaa authorization group cert list Cifelli-Flex name-mangler Cifelli-NM

Step 5: Add your match identity statement (see above). We use a cert map since we are using PKI authentication (rsa-sig) which allows us to map our peer to our unique IKEv2 profile as referenced in PKI posts from earlier.

crypto pki certificate map Cifelli-Lab 10
 subject-name co

Now that the components needed are configured and integrated lets attempt to establish our session & verify the configuration. This is done by pinging the remote client.

Debugging IKEv2 profile matching & authorization successes:

As you can see our cert map matched us to our unique IKEv2 profile, the peer was successfully authenticated via RSA method, we use our Cifelli-Flex list with our derived username from the name-mangler to process the group authorization request, & receives a response (all done locally in this demo).

Further down in debugs we can then see that our IKEv2 SA is created:

Debugging IKEv2 authorization failures:

I purposely configured our remote peer trustpoint with the wrong subject name so we could debug authorization failures. As you can see our Name Mangler extracted the CN from the IKE identity presented to perform authorization, but there was no match since our authorization policy is configured for

So in this post we show how to configure, verify, & troubleshoot using an IKEv2 name-mangler to derive a name to be used for AAA authorization. Cheers!


Recent Posts

See All

In the post I want to cover understanding IKEv1 status messages & debugging IKEv1 main mode. It is important as each message has its own unique meaning, and these messages are typically seen when att

"The What?" - In this post I will cover configuring & verifying a basic site-to-site VPN tunnel between two Cisco ASAs using IKEv1 with pre-shared keys (PSK). These types of VPNs are also known as L2