General Logic Overview

When establishing a VPN tunnel, ASA firewall matches tunnel-group names based on the following criteria list:

1) Using the IKE ID presented by the remote peer. It may be an IP address (default) or hostname. In some cases this might be an ezVPN group name, for example when you are using Cisco ezVPN client or ezVPN Remote feature.
2) Using the OU (Organization Unit) field from the DN found in digital certificate presented by the peer OR by using the certificate mapping rules. This only works when ISAKMP phase uses digital signatures for authentication. Certificate mapping rules translate the DN (distinguished name) found in the certificate to the tunnel-group name.
3) Using the remote endpoint’s IP address. It’s the last resort rule, and this is the only way to match the identity with PSK (pre-shared keys) and IKE Main Mode.

Recall that IKE uses either of two modes of operation for Phase 1: Main Mode (default) and Aggressive Mode:

a) Main Mode (MM), which is mandatory per the RFC – creates an encrypted channel before exchanging the identities.
b) Aggressive Mode (AM), which is quicker than Main Mode, exchanges endpoint IDs in “clear text”, while performing DH (Diffie Hellman) exchange and establishing the secure channel. AM is less secure than MM is thus should be less preferred. However, there are some properties that make AM uniquely useful.


There are some important consequences of MM behavior, when implementing authentication based on pre-shared keys (PSK). When pre-shared keys are used for authentication, they are also used to generate the shared encryption key for ISAKMP SA (along with the DH generated key). This feature is very important to prevent man-in-the middle attacks. When ISAKMP responder receives a MM proposal from initiator and choses authentication based on pre-shared keys, it should generate the shared encryption key. This procedure requires knowing the PSK of the remote peer in advance. However, the responder does NOT know the IKE ID of the initiator yet, only its IP address. Therefore, the only way to select the proper pre-shared key in MM is by looking the key in the database based on the initiator’s IP address. Even if you use of hostnames for IKE IDs with PSK authentication, the keys and tunnel-group names are still matched based on the IP addresses. This is the unique “feature” of ISAKMP MM with PSK.

IKE MM with digital signatures

Now consider the case when you are using IKE MM along with digital signatures (RSA sigs) authentication. In this situation, session encryption key is not derived based on the pre-shared authentication key. Thus, the respondent that accepts the policy based on digital signatures may delay the proper tunnel-group selection until it learns the IKE ID of the initiator. More than that, it may use the information from the DN field of the digital certificate presented by the initiator for more detailed matching. With the default configuration, the subject’s OU field in the certificate is used to match the tunnel group names, but it is possible to set up flexible mapping rules.

In ASA firewall, the following default commands enable tunnel-group name lookup based on the OU (first) than IKE-ID (if present) and finally the Peer IP address:

tunnel-group-map enable ou
tunnel-group-map enable ike-id
tunnel-group-map enable peer-ip

IKE AM and names matching

When the responding node receives an AM proposal, the proposal already contains the initiator’s IKE ID, regardless of the authentication method selected. The IKE ID might be an IP address or hostname or just any text string – e.g. ezVPN group name. The responder may use it to match the local tunnel-group and pre-shared key if needed. Thus, you may utilize tunnel-group names based on hostnames with IKE AM even with PSK authentication.

Activating IKE AM

IKE AM is automatically enabled with some VPN features, such as ezVPN remote. In order to engage AM negotiation in ASA firewalls manually, use the command crypto map [TAG] [SEQ#] set phase1-mode aggressive. Enabling this feature in IOS is a bit more trickier. You should configure an ISAKMP profile first and then use it with a crypto map similar to the following:

crypto isakmp profile AGGRESSIVE
 initiate mode aggressive
 self-identity fqdn
 keyring default
crypto map VPN isakmp-profile AGGRESSIVE
crypto map VPN 10 ipsec-isakmp

You may globally disable AM in Cisco IOS router using the command crypto isakmp aggressive-mode disable or using the command isakmp am-disable in ASA firewall. This will prevent the devices from ever accepting or initiaing any IKE AM connections.

Fallback Matching

What happens if none of the configured tunnel groups matches? In this case, the firewall would use the default group that is always present in the system: DefaultRAGroup. Thus, if you don’t have a specific group configured for the remote endpoint, but the authentication using the default group succeeds, the system will use the default policy for the new tunnel. In case you wonder, you may change the default tunnel-group name using the command tunnel-group-map default-group <NAME> and specify your own group.

Certificate Mapping Rules

When using digital signatures authentication, ASA firewall supports certificate mapping rules to translate issuer and subject names in the certificate to the tunnel-group name. The rules are configured using the command crypto ca certificate map [<NAME>] <SEQ#>. If no name is specified, the default map named DefaultCertificateMap is used for this purpose. Every entry in this map matches either part of issuer or subject DN in the certificate. For example

crypto ca certificate map MYMAP 10
 issuer-name attr cn eq IESERVER1
 subject-name co R3

You may match the DN as a whole string, without specifying any particular attribute like the second line in the above example does. When you have the map configured, you need to perform the following two steps:

1) Enable the mapping rules using the command tunnel-group-map enable rules.
2) Configure certificate map to tunnel-group mapping using the global commands tunnel-group-map [<NAME>] <SEQ#> <Tunnel-Group-Name>.

You may repeat the second step how many times you want to map the particular entry to a tunnel group that exists in the sytem. If you don’t specify the name for the certificate map, the default is DefaultCertificateMap used. Notice that OR logic is implemented by mapping multiple certificate map entries to the same group. Thus, any of the matching entries will result in the incoming session being matched on the same group.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

8 Responses to “Understanding how ASA Firewall matches Tunnel-Group Names”

  1. Piotr Kaluzny says:

    Good Day,

    I wish you posted this few months ago. It would have saved me few days trying to figure out the differences between src ISAKMP packet IP, IKE_ID, MM with PSK etc… Could not have realized why we can’t match based on IKE_ID in MM with PSK – after all IKE_ID shows in the 4-th packet along with HASH_I. And this is all because of DH which happens before Auth Phase.

    By the way, did you find any difference between setting Request ISAKMP profile like in this post and via “set” inside the profile?

    Piotr Kaluzny

  2. [...] Understanding how ASA Firewall matches Tunnel-Group Names [...]

  3. [...] defined in the system. You may find the description of the procedure used by the ASA firewalls here Understanding how ASA Firewall Matching tunnel-group Names . IOS router use similar procedure, which is somewhat simplified when using just ezVPN clients. As [...]

  4. Stuart Hare says:

    A great post Petr.

    Finally an explanation as to why my custom tunnel groups have not matched and I have had to configure the default group and policy for RAVPN to work.


  5. tacack says:

    Great resource Petr!

    This always acts as a quick reference or cheatsheet when i forget about certificates and tunnel-groups!

    However, i’d be super glad if you write an article on matching hostnames in aggressive mode? Because i tried labbing that many times and it doesn’t work as expected.

    Just a sample config/explanation would be awesome! :)


  6. Chris Miller says:

    Fantastic essay, this helped me understand the tunnel-group process well enough to get a mixed static/dynamic tunnel config working on our ASA’s


  7. Mahesh says:


    Could you please help me on below error:

    “Tunnel group search using certificate maps failed for peer certificate”

  8. mirofahmy says:

    Dear Petr

    the problem inundrstand the topic
    that is not clear where vpn use MAIN mode or aggrisive mode
    we need to identify that exactly

    with both preshared and certificate
    we need to final that

    that is clear with ASA
    what about normal IOS


Leave a Reply


CCIE Bloggers