IKEv2 Profile Defined but Not Attached: Trace the Chain

The IKEv2 profile is in the saved configuration, the key ring is there too, and the tunnel still will not come up. On Cisco IOS XE a profile is an object that carries identity matching and authentication choices, and an object does nothing until another object references it and an interface attaches that object to a path. Most failed phase 1 debugging sessions skip one of those references. Read the chain from the key ring outward before you change any proposal or policy.

What a profile object actually is

The IKEv2 profile holds the remote identity match, the local and remote authentication methods, and a reference to a key ring for preshared-key designs. It describes how a peer is recognized and how it proves itself, and it names no interface.

The key ring is a separate object holding the preshared keys. The crypto map or IPsec profile is a third object that references the IKEv2 profile and supplies the protection settings. The interface attachment is the fourth step, where a crypto map is applied or tunnel protection is enabled. Each hop is a distinct reference, and a missing hop leaves every object looking correct in isolation.

Follow the reference chain in order

Start at the key ring the profile names, then confirm the profile name that the crypto map or IPsec profile references, then find the interface that consumes that last object. Write each name beside the object that consumes it; that short list is more useful than checking that every expected stanza exists somewhere in the configuration.

The usual breaks are mechanical. A profile name differs by one character from the one the crypto map references. The crypto map exists but was never applied to the interface. The tunnel protection command points at an IPsec profile that references a different IKEv2 profile. A responder with no explicit attachment is a documented case, but an initiator with no attachment is simply not configured for the path.

crypto ikev2 keyring KR-SITE
 peer SITE-B
  address 203.0.113.9
crypto ikev2 profile IKEV2-SITE
 match identity remote address 203.0.113.9 255.255.255.255
 keyring local KR-SITE
crypto ipsec profile IPSEC-SITE
 set ikev2-profile IKEV2-SITE
interface Tunnel100
 tunnel protection ipsec profile IPSEC-SITE

Read the snippet as a chain rather than as a template. The interface names the IPsec profile, the IPsec profile names the IKEv2 profile, and the IKEv2 profile names the key ring. Break any one of those names and the configuration still parses, which is why the router accepts it and the tunnel stays down.

Crypto map and tunnel protection are alternatives

Cisco documents two attachment arrangements. A crypto map can be applied to an interface and can reference the IKEv2 profile through its set command. Tunnel protection attaches an IPsec profile to a tunnel interface. Both are valid, and they are not meant to be installed together as a belt-and-braces measure.

The tunnel's source and destination identify the outer delivery arrangement, and they are separate from the protection attachment. A LAN interface, the tunnel interface, and the outer source interface play three different roles. A crypto map on the LAN interface does not protect the tunnel, and a tunnel with protection enabled but no reachable source address never sends a packet to its peer.

Inspect the loaded state, not only the text. The installed release has commands that connect the configured objects to the negotiated session, and those are the ones to quote in a ticket. A saved configuration proves intent; a session table proves the path.

The responder exception is not a rule for initiators

The IOS XE guide notes that an explicit IKEv2 profile attachment can be optional on a responder. That exception does not remove authentication or identity checks, and it does not make the profile optional on the side that starts the connection.

If your router initiates, treat the attachment as mandatory and trace it end to end. If your router only answers, confirm which profile actually matched the incoming peer, because a responder can select a profile by identity rather than by an interface reference.

Check the path, not the saved configuration

After the attachments line up, test one permitted application and record its inner source, destination, and route. A request originated by the router can use a different source address from traffic forwarded from the LAN, and the protection scope may cover only one of them.

A correctly attached definition does not prove that the selectors, the return route, and the interface policy cover your flow. Send real traffic and read the negotiated state, then repeat after a reconnect so you know the chain survives a fresh negotiation. Keep the explanation scoped to IOS XE IKEv2; a historical IKEv1 crypto-map deployment has a different object model and should not be debugged with this chain.

Write the four names into the change record when the tunnel works. The next person to touch the crypto map will need them, and the chain is the part of the design that the running configuration does not explain.