The newly introduced IPsec system logs are:
- IKE Phase-1: Responder starts Main mode negotiations—The remote peer at the specified IP address has initiated Phase 1 negotiations in either Main or Aggressive mode, and the local security device (the Responder) has begun its response. No recommended action.
- IKE Phase-1: (Initiator) symmetric crypto key has been generated successfully—The P1 or manual key used for encryption has been generated successfully. No recommended action.
- IKE Phase-1: Negotiation completed—The local security device has sent the initial message for IKE Phase 2 negotiations to the specified peer. No recommended action.
- IKE Phase-1 Failure: Main mode – no proposal chosen—There were no acceptable Phase 1 proposals. The specified negotiations to the identified IKE failed. Examine the local log and VPN configuration, and request the remote IKE user to examine the configuration on their VPN client for possible causes.
- IKE Phase-1 Failure: ISAKMP negotiation retry limit reached—ISAKMP negotiation retry limit reached. No recommended action.
- IKE Phase-1 Failure: Received delete notification—Received delete notification. No recommended action.
- IKE Phase-2: (Responder) Quick mode – negotiation initiated—The local security device has sent the initial message for IKE Phase 2 negotiations to the specified peer. No recommended action.
- IKE Phase-2: (Initiator) The symmetric crypto key has been generated successfully—The P2 or manual key used for encryption has been generated successfully. No recommended action.
- IKE Phase-2: (Responder) Quick mode – Responded to the first peer message—The local security device has responded to the specified peer, which sent the first message for Phase 2 IKE negotiations. No recommended action.
- IKE Phase-2: Completed negotiations—The local security device has successfully negotiated a Phase 2 session with the specified peer. The Phase 2 session consists of the specified attributes. No recommended action.
- IKE Phase-2 Failure: Quick mode – no proposal chosen—There were no acceptable Phase 2 proposals. The specified negotiations to the identified IKE failed. Examine the local log and VPN configuration, and request the remote IKE user to examine the configuration on the VPN client for possible causes.
- IKE Phase-2: (Responder) Policy lookup for Phase-2 failed—Received a message but did not check a policy because ID mode was set to IP or policy checking was disabled.
When the local security device received an IKE Phase 2 message from the specified peer, it could not check for a policy because the ID mode was set to IP or policy checking was disabled. If the ID mode is set to IP, the remote peer does not send the proxy ID payload when initiating a Phase 2 session. The proxy ID consists of the local end entity’s IP address and netmask, protocol, and port number, as well as those items for the remote end entity. Consequently, the local peer cannot use the information in the proxy ID to match the information in a local policy. If policy checking is disabled for IKE traffic with the specified peer, the IKE module builds security association (SA) without verifying the policy configuration.
Verify if this behavior is intended. If not, set the ID mode to subnet (set IKE ID mode subnet) and enable policy checking ( set IKE policy checking ).
- IKE Phase-2: Failed to match the peer proxy IDs—The peer sent a proxy ID that did not match the one in the SA configuration. An IKE Phase 2 quick mode message was received and a corresponding Phase 1 SA was found, but the proxy ID (local and remote subnets protected by this tunnel) within the message was not consistent with the proxy ID setting for this tunnel’s configuration.
Verify the proxy ID (local and remote subnets) setting for this tunnel and try again.
- IKE Phase-2 Failure: IKE Phase-2 negotiation retry limit reached—The local security device has reached the retransmission limit (10 failed attempts) during Phase 2 negotiations with the specified remote peer because the local device has not received a response.
Note: If the local device continues receiving outbound traffic for the remote peer after the first 10 failed attempts, it makes another 10 attempts, and continues to do so until it either succeeds at contacting the remote gateway or it no longer receives traffic bound for that gateway.
Verify network connectivity to the peer gateway. Request the remote gateway admin to consult the log to determine if the connection requests reached it and, if so, why the device did not respond.