PDF(111.7 KB) View with Adobe Reader on a variety of devices
ePub(119.2 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(127.6 KB) View on Kindle device or Kindle app on multiple devices
Updated:January 14, 2020
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to set up a site-to-site Internet Key Exchange version 2 (IKEv2) tunnel between a Cisco Adaptive Security Appliance (ASA) and a router that runs Cisco IOS® software.
Cisco recommends that you have knowledge of these topics:
Internet Key Exchange version 2 (IKEv2)
Certificates and Public Key Infrastructure (PKI)
Network Time Protocol (NTP)
The information in this document is based on these software and hardware versions:
Cisco ASA 5510 Adaptive Security Appliance that runs software version 9.1(3)
Cisco 2900 Series Integrated Services Router (ISR) that runs Cisco IOS software version 15.3(3)M1
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
This document can also be used with these hardware and software versions:
Cisco ASA that runs software version 8.4(1) or later
Cisco ISR Generation 2 (G2) that runs Cisco IOS software version 15.2(4)M or later
Cisco ASR 1000 Series Aggregation Services Routers that run Cisco IOS-XE software version 15.2(4)S or later
Cisco Connected Grid Routers that run software version 15.2(4)M or later
Configuration of an IKEv2 tunnel between an ASA and a router with the use of pre-shared keys is straightforward. However, when you use certificate authentication, there are certain caveats to keep in mind.
Certificate authentication requires that the clocks on all participating devices be synchronized to a common source. While the clock can be set manually on each device, this is not very accurate and can be cumbersome. The easiest method to synchronize the clocks on all devices is to use NTP. NTP synchronizes timekeeping among a set of distributed time servers and clients. This synchronization allows events to be correlated when system logs are created and when other time-specific events occur. For more information on how to configure NTP, refer to Network Time Protocol: Best Practices White Paper.
Tip: When a Cisco IOS software Certificate Authority (CA) server is used, it is common practice to configure the same device as the NTP master. In this example, the CA server also serves as the NTP server.
HTTP-URL-Based Certificate Lookup
Certificate lookup based on the HTTP URL avoids the fragmentation that results when large certificates are transferred. This feature is enabled on Cisco IOS software devices by default, so the cert req type 12 is used by Cisco IOS software.
If software versions that do not have the fix for Cisco bug ID CSCul48246 are used on the ASA, then the HTTP-URL-based lookup is not negotiated on the ASA, and Cisco IOS software causes the authorization attempt to fail.
On the ASA, if IKEv2 protocol debugs are enabled, these messages appear:
IKEv2-PROTO-1: (139): Auth exchange failed IKEv2-PROTO-1: (140): Unsupported cert encoding found or Peer requested HTTP URL but never sent HTTP_LOOKUP_SUPPORTED Notification
In order to avoid this issue, use the no crypto ikev2 http-url cert command in order to disable this feature on the router when it peers with an ASA.
Peer ID Validation
During IKE AUTH stage Internet Security Association and Key Management Protocol (ISAKMP) negotiations, the peers must identify themselves to each other. However, there is a difference in the way routers and ASAs select their local identity.
ISAKMP ID Selection on Routers
When IKEv2 tunnels are used on routers, the local identity used in the negotiation is determined by the identity local command under the IKEv2 profile:
R1(config-ikev2-profile)#identity local ? address address dn Distinguished Name email Fully qualified email string fqdn Fully qualified domain name string key-id key-id opaque string - proprietary types of identification
By default, the router uses the address as the local identity.
ISAKMP ID Validation on Routers
The expected peer ID is also configured manually in the same profile with the match identity remote command:
R1(config-ikev2-profile)#match identity remote ? address IP Address(es) any match any peer identity email Fully qualified email string [Max. 255 char(s)] fqdn Fully qualified domain name string [Max. 255 char(s)] key-id key-id opaque string
ISAKMP ID Selection on ASAs
On ASAs, the ISAKMP identity is selected globally with the crypto isakmp identity command:
ciscoasa/vpn(config)# crypto isakmp identity ? configure mode commands/options: address Use the IP address of the interface for the identity auto Identity automatically determined by the connection type: IP address for preshared key and Cert DN for Cert based connections hostname Use the hostname of the router for the identity key-id Use the specified key-id for the identity
By default, the command mode is set to auto, which means that the ASA determines ISAKMP negotiation by connection type:
IP address for pre-shared key.
Cert Distinguished Name for certificate authentication.
Note: Cisco bug ID CSCul48099 is an enhancement request for the ability to configure on a per-tunnel-group basis rather than in the global configuration.
ISAKMP ID Validation on the ASA
Remote ID validation is done automatically (determined by the connection type) and cannot be changed. Validation can be enabled or disabled on a per-tunnel-group basis with the peer-id-validate command:
ciscoasa/vpn(config-tunnel-ipsec)# peer-id-validate ? tunnel-group-ipsec mode commands/options: cert If supported by certificate nocheck Do not check req Required
The difference in ID selection/validation causes two separate interoperability issues:
When cert auth is used on the ASA, the ASA tries to validate the peer ID from the Subject Alternative Name (SAN) on the received certificate. If peer ID validation is enabled and if IKEv2 platform debugs are enabled on the ASA, these debugs appear:
IKEv2-PROTO-3: (172): Getting configured policies IKEv2-PLAT-3: attempting to find tunnel group for ID: 172.16.1.1 IKEv2-PLAT-3: mapped to tunnel group 172.16.1.1 using phase 1 ID IKEv2-PLAT-3: (172) tg_name set to: 172.16.1.1 IKEv2-PLAT-3: (172) tunn grp type set to: L2L IKEv2-PLAT-3: Peer ID check started, received ID type: IPv4 address IKEv2-PLAT-2: Peer ID check: failed to retreive IP from SAN IKEv2-PLAT-2: Peer ID check: failed to retreive DNS name from SAN IKEv2-PLAT-2: Peer ID check: failed to retreive RFC822 name from SAN IKEv2-PLAT-1: retrieving SAN for peer ID check IKEv2-PLAT-1: Peer ID check failed IKEv2-PROTO-1: (172): Failed to locate an item in the database IKEv2-PROTO-1: (172): IKEv2-PROTO-5: (172): SM Trace-> SA: I_SPI=833D2323FCB46093 R_SPI=F0B4D318DDDDB783 (I) MsgID = 00000001 CurState: I_PROC_AUTH Event: EV_AUTH_FAIL IKEv2-PROTO-3: (172): Verify auth failed IKEv2-PROTO-5: (172): SM Trace-> SA: I_SPI=833D2323FCB46093 R_SPI=F0B4D318DDDDB783 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_FAIL IKEv2-PROTO-3: (172): Auth exchange failed
For this issue, either the IP address of the certificate needs to be included in the peer's certificate, or peer ID validation needs to be disabled on the ASA.
Similarly, by default the ASA selects the local ID automatically so, when cert auth is used, it sends the Distinguished Name (DN) as the identity. If the router is configured to receive the address as the remote ID, the peer ID validation fails on the router. If IKEv2 debugs are enabled on the router, these debugs appear:
Nov 30 22:49:14.464: IKEv2:(SESSION ID = 172,SA ID = 1):SM Trace-> SA: I_SPI=E9E4B7FD0A336C97 R_SPI=F2CF438C0CCA281C (R) MsgID = 1 CurState: R_WAIT_AUTH Event: EV_GET_POLICY_BY_PEERID Nov 30 22:49:14.464: IKEv2:(SESSION ID = 172,SA ID = 1):Searching policy based on peer's identity 'hostname=asa.cisco.com' of type 'DER ASN1 DN' Nov 30 22:49:14.464: IKEv2:%Profile could not be found by peer certificate. Nov 30 22:49:14.468: IKEv2:% IKEv2 profile not found Nov 30 22:49:14.468: IKEv2:(SESSION ID = 172,SA ID = 1):: Failed to locate an item in the database
For this issue, either configure the router in order to validate the fully qualified domain name (FQDN) or configure the ASA in order to use address as the ISAKMP ID.
Note: On the router, a certificate map that is attached to the IKEv2 profile must be configured in order to recognize the DN. Refer to the Certificate to ISAKMP Profile Mapping section of the Internet Key Exchange for IPsec VPNs Configuration Guide, Cisco IOS XE Release 3S Cisco document for information about how to set this up.
Size of Auth Payload
If certificates (rather than pre-shared keys) are used for authentication, the auth payloads are considerably larger. This usually results in fragmentation, which can then cause the authentication to fail if a fragment is lost or dropped in the path. If the tunnel does not come up because of the size of the auth payload, the usual causes are:
Control plane policing on the router that might block the packets.
Incorrect maximum transition unit (MTU) negotiation, which can be corrected with the crypto ikev2 fragmentation mtu size command.
Resource Allocation in Multi-Context Mode on ASA
As of ASA version 9.0, the ASA supports a VPN in multi-context mode. However, when you configure the VPN in multi-context mode, be sure to allocate appropriate resources in the system that will use the VPN.
A certificate revocation list (CRL) is a list of revoked certiﬁcates that have been issued and subsequently revoked by a given CA. Certiﬁcates might be revoked for a number of reasons such as:
Failure or compromise of a device that uses a given certificate.
Compromise of the key pair used by a certiﬁcate.
Errors within an issued certiﬁcate, such as an incorrect identity or the need to accommodate a name change.
The mechanism used for certiﬁcate revocation depends on the CA. Revoked certiﬁcates are represented in the CRL by their serial numbers. If a network device attempts to verify the validity of a certiﬁcate, it downloads and scans the current CRL for the serial number of the presented certificate. Therefore, if CRL validation is enabled on either peer, a proper CRL URL must be configured as well so the validity of the ID certificates can be verified.
If the ASA is configured with a certificate that has Intermediate CAs and it's peer might or might not have the same Intermediate CA, then the ASA needs to be explicitly configured to send the complete certificate chain to the router. The router does this by default. In order to do this, when you define the trustpoint under the crypto map add the chain keyword as shown here:
crypto map outside-map 1 set trustpoint ios-ca chain
If this is not done, then the the tunnel will only get negotiated as long as the ASA is the responder. If it is an initiator, the tunnel will fail and PKI and IKEv2 debugs on the router will show this:
2328304: Jun 8 19:14:38.051 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68): Get peer's authentication method 2328305: Jun 8 19:14:38.051 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68): Peer's authentication method is 'RSA' 2328306: Jun 8 19:14:38.051 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68): SM Trace-> SA: I_SPI=E4368647479E50EF R_SPI=97B2C8AA5268271A (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_CHK_CERT_ENC 2328307: Jun 8 19:14:38.051 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68): SM Trace-> SA: I_SPI=E4368647479E50EF R_SPI=97B2C8AA5268271A (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_VERIFY_X509_CERTS 2328308: Jun 8 19:14:38.051 GMT: CRYPTO_PKI: (A16A8) Adding peer certificate 2328309: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: Added x509 peer certificate -(1359) bytes 2328310: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: ip-ext-val: IP extension validation not required 2328311: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: create new ca_req_context type PKI_VERIFY_CHAIN_CONTEXT,ident 4177 2328312: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: (A16A8)validation path has 1 certs 2328313: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: (A16A8) Check for identical certs 2328314: Jun 8 19:14:38.055 GMT: CRYPTO_PKI : (A16A8) Validating non-trusted cert 2328315: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: (A16A8) Create a list of suitable trustpoints 2328316: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: Unable to locate cert record by issuername 2328317: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: No trust point for cert issuer, looking up cert chain 2328318: Jun 8 19:14:38.055 GMT: CRYPTO_PKI: (A16A8) No suitable trustpoints found 2328319: Jun 8 19:14:38.059 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68):: Platform errors 2328320: Jun 8 19:14:38.059 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68):SM Trace-> SA: I_SPI=E4368647479E50EF R_SPI=97B2C8AA5268271A (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_CERT_FAIL 2328321: Jun 8 19:14:38.059 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68):Verify cert failed 2328322: Jun 8 19:14:38.059 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68): SM Trace-> SA: I_SPI=E4368647479E50EF R_SPI=97B2C8AA5268271A (R) MsgID = 1 CurState: R_VERIFY_AUTH Event: EV_AUTH_FAIL 2328323: Jun 8 19:14:38.059 GMT: IKEv2:(SESSION ID = 14607,SA ID = 68) :Verification of peer's authentication data FAILED
ip domain name cisco.com ! crypto pki trustpoint tp_ikev2 enrollment url http://192.168.254.254:80 usage ike fqdn R1.cisco.com ! ! necessary only in this example as no crl has been configured on the IOS CA. On the ASA this is enabled by default. When using proper 3rd party certificates this is not necessary. ! revocation-check none rsakeypair ikev2_cert eku request server-auth ! crypto pki certificate chain tp_ikev2 certificate 0B 308202F4 3082025D A0030201 0202010B 300D0609 2A864886 F70D0101 05050030 1B311930 17060355 04031310 696F732D 63612E63 6973636F 2E636F6D 301E170D 31333131 32353233 35363537 5A170D31 33313230 35323335 3635375A 301D311B 30190609 2A864886 F70D0109 02160C52 312E6369 73636F2E 636F6D30 82012230 0D06092A 864886F7 0D010101 05000382 010F0030 82010A02 82010100 A1032A61 A3F14539 87816C22 8C66A170 3A9661EA 4AF6F063 3FC305B8 E525B84D AA74A9CE 666B1BF5 3C7DF025 31FEB161 CE49845F 3EC2DE7B D3FCC685 D6F80C8C 0AA12772 1B4AB15C 90C04446 068A0DBA 7BFA4E40 E978364F A2B07F7C 02C691A8 921A5481 A4AF07B4 BA0C9DBA D35F4566 6CB70553 DAF09A45 F2948C5A 1621E5D2 98508D49 A2EF61D3 AAF3A9DB 87F2D763 89AD0BBE 916A6CF8 1B59C426 7960013B 061AA0A5 F6870319 87A35ABA 8C1B5CF5 42976739 B8C936D3 24276E56 F59E3CFD 9B9B4A0D 2E5294AB C4470376 5D96915F 275CBC78 586D6755 F45C7592 62DCA916 CEC1A450 3FF090A9 15088CD2 13B90391 B0795263 071C7002 8CBF98F2 89788A0B 02030100 01A381C1 3081BE30 3C060355 1D1F0435 30333031 A02FA02D 862B6874 74703A2F 2F313932 2E313638 2E323534 2E323534 2F696F73 2D636163 64702E69 6F732D63 612E6372 6C303106 03551D25 042A3028 06082B06 01050507 03010608 2B060105 05070305 06082B06 01050507 03060608 2B060105 05070307 300B0603 551D0F04 04030205 A0301F06 03551D23 04183016 80140828 96B9F4AF 20755143 21D072F1 61D09D2E C8AA301D 0603551D 0E041604 14C63949 4CA10DBB 2BBB6F98 BAFF0EE2 B3716CEE 3B300D06 092A8648 86F70D01 01050500 03818100 3080FEF6 9160357B 6F28ED60 428BA6CE 203706F6 F91DA273 AF6E81D3 46539E13 B4C89A9A 19E1F0BC A631A418 C30DFC8E 0585039D EB07D35D E719F5FE A4EE47B5 CED31B12 745C9EE8 5B6B0F17 67C3B965 C927B379 C674933F 84E7A1F7 851A6CF0 8775B1C5 3A033D90 75965DCA 86E4A842 E2C35AC0 6BFA8144 699B1582 C094BF35 quit certificate ca 01 3082020F 30820178 A0030201 02020101 300D0609 2A864886 F70D0101 04050030 1B311930 17060355 04031310 696F732D 63612E63 6973636F 2E636F6D 301E170D 31333131 31353231 33353533 5A170D31 33313231 35323133 3535335A 301B3119 30170603 55040313 10696F73 2D63612E 63697363 6F2E636F 6D30819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 81009EBB 48957C44 C940236F A1CDA758 AA930E8C 91390734 B8EF814D 0BF7AEC9 7EC40379 7749D3C6 154F6A32 00738655 33B20207 037A9E15 3229FA72 478424FB 409F518D B13D328D E761BE08 8023B4FF F410054B 4423156D 66C99788 69AB5956 966D5E1B 4D1C1120 A05AD08C F036A134 3B2FC425 E4A2524F 36E0A129 2C8F6CEE 971D0203 010001A3 63306130 0F060355 1D130101 FF040530 030101FF 300E0603 551D0F01 01FF0404 03020186 301F0603 551D2304 18301680 14082896 B9F4AF20 75514321 D072F161 D09D2EC8 AA301D06 03551D0E 04160414 082896B9 F4AF2075 514321D0 72F161D0 9D2EC8AA 300D0609 2A864886 F70D0101 04050003 81810087 A06D354A F7423E0E 64A7C5EC 6006FBDE 914D7BFD F86ADA50 B1A00D17 0BF06EC1 5423D514 FBEB0A76 986EB63F F7FCE99A 81C4B112 61FD69CE A2CE750E B1B3A6F9 84E92490 8F213613 451DD9A8 3FC3406A 854B20ED 27E4DDD8 62F6DEA5 DD8B4396 1879B3E7 651CB9D1 3DD46B8B 32796963 9F6854F1 389F0060 AA0D1B8D F83E09 quit ! crypto ikev2 proposal aes-cbc-256-proposal encryption aes-cbc-256 integrity sha1 group 5 2 14 ! crypto ikev2 policy policy1 match address local 172.16.1.1 proposal aes-cbc-256-proposal ! crypto ikev2 profile profile1 description IKEv2 profile ! ! router configured to use address as the remote identity. By default local identity is address ! match address local 172.16.1.1 match identity remote address 172.16.1.2 255.255.255.255 authentication remote rsa-sig authentication local rsa-sig pki trustpoint tp_ikev2 ! ! disable http-url based cert lookup ! no crypto ikev2 http-url cert ! crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac mode tunnel ! crypto map SDM_CMAP_1 1 ipsec-isakmp set peer 172.16.1.2 set transform-set ESP-AES-SHA set pfs group2 set ikev2-profile profile1 match address 103 ! interface Loopback0 ip address 172.16.2.1 255.255.255.255 ! interface GigabitEthernet0/0 ip address 172.16.1.1 255.255.255.0 duplex auto speed auto crypto map SDM_CMAP_1 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 duplex auto speed auto ! ip route 192.168.0.0 255.255.255.0 172.16.1.2 ip route 192.168.254.254 255.255.255.255 192.168.1.254 ! ! access list that defines crypto domains, must be mirror images on both peers. ! access-list 103 permit ip 172.16.2.0 0.0.0.255 192.168.0.0 0.0.0.255 ! ! ntp configuration ! ntp trusted-key 1 ntp server 192.168.254.254 ! end
Sample IOS CA Configuration
ip domain name cisco.com ! ! CA server configuration ! crypto pki server ios-ca database archive pkcs12 password 7 02050D4808095E731F issuer-name CN=ios-ca.cisco.com grant auto lifetime certificate 10 lifetime ca-certificate 30 cdp-url http://192.168.254.254/ios-cacdp.ios-ca.crl eku server-auth ipsec-end-system ipsec-tunnel ipsec-user ! ! this trustpoint is generated automatically when the CA server is enabled. ! crypto pki trustpoint ios-ca revocation-check crl rsakeypair ios-ca ! ! crypto pki certificate chain ios-ca certificate ca 01 3082020F 30820178 A0030201 02020101 300D0609 2A864886 F70D0101 04050030 1B311930 17060355 04031310 696F732D 63612E63 6973636F 2E636F6D 301E170D 31333131 31353231 33353533 5A170D31 33313231 35323133 3535335A 301B3119 30170603 55040313 10696F73 2D63612E 63697363 6F2E636F 6D30819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281 81009EBB 48957C44 C940236F A1CDA758 AA930E8C 91390734 B8EF814D 0BF7AEC9 7EC40379 7749D3C6 154F6A32 00738655 33B20207 037A9E15 3229FA72 478424FB 409F518D B13D328D E761BE08 8023B4FF F410054B 4423156D 66C99788 69AB5956 966D5E1B 4D1C1120 A05AD08C F036A134 3B2FC425 E4A2524F 36E0A129 2C8F6CEE 971D0203 010001A3 63306130 0F060355 1D130101 FF040530 030101FF 300E0603 551D0F01 01FF0404 03020186 301F0603 551D2304 18301680 14082896 B9F4AF20 75514321 D072F161 D09D2EC8 AA301D06 03551D0E 04160414 082896B9 F4AF2075 514321D0 72F161D0 9D2EC8AA 300D0609 2A864886 F70D0101 04050003 81810087 A06D354A F7423E0E 64A7C5EC 6006FBDE 914D7BFD F86ADA50 B1A00D17 0BF06EC1 5423D514 FBEB0A76 986EB63F F7FCE99A 81C4B112 61FD69CE A2CE750E B1B3A6F9 84E92490 8F213613 451DD9A8 3FC3406A 854B20ED 27E4DDD8 62F6DEA5 DD8B4396 1879B3E7 651CB9D1 3DD46B8B 32796963 9F6854F1 389F0060 AA0D1B8D F83E09 quit voice-card 0 ! ! interface Loopback0 ip address 192.168.254.254 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.0.254 255.255.255.0 duplex auto speed auto ! interface GigabitEthernet0/1 ip address 192.168.1.254 255.255.255.0 duplex auto speed auto ! ! http-server needs to be enabeld for SCEP ! ip http server no ip http secure-server ! ip route 0.0.0.0 0.0.0.0 10.122.162.129 ip route 172.18.108.26 255.255.255.255 10.122.162.129 ! ! ntp configuration ! ntp trusted-key 1 ntp master 1 ! end
Use this section in order to confirm that your configuration works properly.
Note: The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output.
These commands work on both ASAs and routers:
show crypto ikev2 sa - Displays the state of the phase 1 Security Association (SA).
show crypto ipsec sa - Displays the state of the phase 2 SA.
Note: In this output, unlike in IKEv1, the Perfect Forwarding Secrecy (PFS) Diffie-Hellman (DH) group value displays as 'PFS (Y/N): N, DH group: none' during the first tunnel negotiation; after a rekey occurs, the correct values appear. This is not a bug even though the behavior is described in Cisco bug ID CSCug67056.
The difference between IKEv1 and IKEv2 is that, in IKEv2, the Child SAs are created as part of the AUTH exchange itself. The DH Group configured under the crypto map is used only during a rekey. Thus, you see 'PFS (Y/N): N, DH group: none' until the first rekey. With IKEv1, you see a different behavior because Child SA creation happens during Quick Mode, and the CREATE_CHILD_SA message has the provision to carry the Key Exchange payload, which specifies the DH parameters to derive the new shared secret.
Phase 1 Verification
This procedure verifies phase 1 activity:
Enter the show crypto ikev2 sa command on the router:
Caution: On the ASA, you can set various debug levels; by default, level 1 is used. If you change the debug level, the verbosity of the debugs might increase. Do this with caution, especially in production environments!
The ASA debugs for tunnel negotiation are:
debug crypto ikev2 protocol
debug crypto ikev2 platform
The ASA debug for certificate authentication is:
debug crypto ca
Debugs on Router
The router debugs for tunnel negotiation are:
debug crypto ikev2
debug crypto ikev2 error
debug crypto ikev2 internal
The router debugs for certificate authentication are: