In previous articles in this IKEv2 series, we have seen how to advertise routes in IKE SAs using the IKEv2 authorization policy. In this article, we will focus on this feature and look at different ways we can use authorization to apply different policies to different clients.

In the last article, we used the lab setup below:

Note: Even though we will keep using the setup above, we will focus only on one FlexVPN server – the configuration can be replicated to the other one.

If you take a look at the FlexVPN configuration we currently have on the FlexVPN server, you will notice that the same policy will be applied to all clients. What if we want to apply different policies to clients based on certain criteria? There are two ways we can go about this:

  1. We can configure different IKEv2 profiles to match the different client groups. For example, if digital certificates are being used to authenticate, then we can match remote identities on certain fields on the certificate (e.g. common name, email address) and create different IKEv2 policies for these groups.
  2. Or, we can create AAA policies that apply to different groups.

In this article, we will consider the 2nd option because the first option is intuitive enough.

IKEv2 Name Mangler

To apply policies to different groups using AAA, we need to first understand what the IKEv2 Name Mangler is and how it works. The IKEv2 Name Mangler allows us to derive a name from a remote peer’s identity which can then be used for authorization requests and to obtain AAA preshared keys.

We can match all parts or specific parts of the remote peer’s identity including DN, FQDN, email and EAP identity; however, we cannot use the Name Mangler to match IKE identities that are IP addresses.

In our lab scenario, we will change the way the FlexVPN client identifies itself from IP address to FQDN. We will then create an IKEv2 Name Mangler that will retrieve names based on the hostname portion of the FQDN.

Hint: An FQDN is made up of two parts, hostname and domain, in the form hostname.domain. For example, if a FlexVPN client identifies itself as FLEX-CLIENT.example.com, the hostname is “FLEX-CLIENT” while the domain is “example.com”.

The configuration for our IKEv2 name mangler is as follows:

crypto ikev2 name-mangler IKEv2-NM
 fqdn hostname

So what happens is that when a connection matches the IKEv2 profile to which this name mangler is applied, the router that receives the connection (the responder) will derive the name to use for authorization as the hostname from the FQDN of the initiator’s IKE ID. It will then try to retrieve an authorization policy that has this derived name either from its local database or from an external RADIUS server, depending on the configuration. If one is found, the attributes configured under the authorization policy are applied to that particular session. If the authorization policy is not found, the tunnel will not come up because the IKE_AUTH exchange will fail.

To see this in action, let us finish the configuration on the FlexVPN server. We need to complete the following configuration on this router:

  • Configure an IKEv2 authorization policy with a name that is the same as the hostname portion of the FQDN IKE identity of the remote peer. In our scenario, we will assume that the client will identity itself as FLEX-CLIENT.example.com; therefore, we will create an authorization policy named “FLEX-CLIENT”.
  • Attach the name mangler to the IKEv2 profile.
  • Add a new “match identity remote” statement under the IKEv2 profile that will match on the domain part of the FQDN, i.e. example.com. This means that any IKE ID that has “example.com” as the domain will match this IKEv2 profile.

Just so that we can differentiate this IKEv2 authorization policy from the default that we have been using, let us change the default administrative distance of the routes we will receive from the peer. The default is 1 but we will change it to 5.

aaa new-model
aaa authorization network IKE_LIST local
!
crypto ikev2 name-mangler IKEv2-NM
 fqdn hostname
!
crypto ikev2 authorization policy FLEX-CLIENT
 no route set interface
 route accept any distance 5
 route set access-list PROTECTED_ACL
!
crypto ikev2 profile FLEX_SERVER_PROF
 match identity remote fqdn domain example.com
 no aaa authorization group psk list IKE_LIST default
 aaa authorization group psk list IKE_LIST name-mangler IKEv2-NM

We also need to configure the FlexVPN client to identify itself using an FQDN:

crypto ikev2 profile FLEX_CLIENT_PROF
 identity local fqdn FLEX-CLIENT.example.com

To test our configuration, we can bring down the tunnel (if it is already up) and bring it back up.

On the FlexVPN server, we can check the IKE SA to verify that the client used its FQDN as its IKE ID.

Finally, we can check the FlexVPN server’s routing table to see if the administrative distance for the 192.168.20.0/24 received from the client is 5.

Just to make sure you understand what we have done so far, let us change the FQDN that the FlexVPN client uses to identify itself to FLEX-CLIENT2.example.com. It means we will create another authorization policy called “FLEX-CLIENT2”. Under this policy, we can set the route tag to 20 just to see the difference.

The configuration on the FlexVPN client is as follows:

crypto ikev2 profile FLEX_CLIENT_PROF
 identity local fqdn FLEX-CLIENT2.example.com

The configuration on the FlexVPN server is as follows:

crypto ikev2 authorization policy FLEX-CLIENT2
 no route set interface
 route accept any tag 20
 route set access-list PROTECTED_ACL

To see these changes, we can clear the IKE SAs so that they are formed again. Once the tunnel is back up, we can check the tag on the route advertised by the client to the server:

AAA Attribute Lists

To conclude this article, let us discuss how we can apply more specific attributes like QoS and ACLs to different sessions. These attributes can be downloaded from an external RADIUS server or they can be configured locally on the Cisco IOS using AAA attribute lists.

For example, let us say we want to apply an ACL that allows only TCP traffic when the “FLEX-CLIENT2” client connects. The configuration below will achieve this:

ip access-list extended PERMIT-TCP
 permit tcp any any
 deny any any log
!
aaa attribute list FLEX-CLIENT2-AAA
 attribute type interface-config “ip access-group PERMIT-TCP in”
 attribute type interface-config “ip access-group PERMIT-TCP out”
!
crypto ikev2 authorization policy FLEX-CLIENT2
 aaa attribute list FLEX-CLIENT2-AAA

Again, we will clear the IKE SAs so that the configuration change can take effect. Let us first determine the virtual-access interface that the session is using:

Now we can check the access list that has been applied to this Virtual-access1 interface:

To test that this ACL works, turn on the HTTP server (or enable Telnet) on the FlexVPN client and then try to connect to that client on the open port:

We can also test something that won’t be allowed, like ping. Since we are logging denied packets on the access list, then we should see a packet deny log on the console:

I have not found any Cisco guide that properly documents the attribute types under an AAA attribute list but you may be able to infer them from this document.

Summary

This brings us to the end of this article where we have looked at how to apply different authorization policies to different clients by creating an IKEv2 name mangler. We also saw how to apply specific attributes to sessions using AAA attribute lists. Even though we have used the local database for our authorization policies, keep in mind that this can also be achieved using an external RADIUS server.

I hope you have found this article insightful and I look forward to the next article in the series.

References and Further reading