IKEv2 to a cloud VPN gateway stays in negotiation. The peer address answers ping. The router's IKEv2 policy for this peer has no proposal attached. What is missing?
Select an answer to reveal the explanation.
Short Explanation
You walked up to the peer and had nothing to offer. You add an IKEv2 proposal this router can send. The peer already answers ping, so the path is there, and BGP is not what gets IKE out of negotiation.
Full Explanation
IKEv2 cannot leave negotiation if the router has no proposal to offer the peer. Ping proves the address is reachable. The missing piece is a proposal, attached to the policy this peer uses, with a group and cipher the gateway will also accept. BGP does not start before IKE on a native VPN, and it does not pull IKE out of negotiation. OSPF hellos do not carry an IKEv2 proposal. Anti-replay does not complete IKE. There is no SA yet for it to widen. Exam caveat: a proposal that the gateway rejects looks similar. After you add one, compare it with the gateway if the state stays in negotiation. Operational check: show crypto ikev2 proposal should list the proposal, and the SA should leave negotiation once the peer accepts it.