Errors in phase 1 usually mean an incorrect authentication configuration (e.g. incorrectly configured certificates or a different IPSec ID used) or in rare cases, incorrectly configured encryption algorithms.

At the beginning of each connection, the peers typically exchange information about their capabilities and recognize whether the connection is NAT:

packet from 192.168.1.200:500: received Vendor ID payload [draft-ietf-
    ipsec-nat-t-ike-00]
packet from 192.168.1.200:500: received Vendor ID payload [draft-ietf-
    ipsec-nat-t-ike-02_n]
responding to Main Mode from unknown peer 192.168.1.200
ignoring Vendor ID payload [47bbe7c993f1fc13b4e6d0db565c68e50102010...]
ignoring Vendor ID payload [da8e937880010000]
received Vendor ID payload [Dead Peer Detection]
received Vendor ID payload [XAUTH]
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
ignoring informational payload, type IPSEC_REPLAY_STATUS
ignoring informational payload, type IPSEC_INITIAL_CONTACT

Then the one who initiates the connection sends their certificate:

Peer ID is ID_DER_ASN1_DN: 'CN=client1'

The system checks whether the certificate is trustworthy via certification authorities. Since the Intra2net system does not use this function, it always fails:

issuer cacert not found
X.509 certificate rejected

Next, the system checks whether the certificate is known. In this example, this fails because a different certificate is configured:

no RSA public key known for 'CN=client1'

The Intra2net system therefore sends a short error message to the peer:

sending encrypted notification INVALID_KEY_INFORMATION to 192.168.1.200:500

If the Intra2net system establishes a connection on its own, we get much less information in case of the same error:

we have a cert and are sending it
ignoring informational payload, type INVALID_CERTIFICATE

In this case, the log of the peer should be examined in more detail, where more detailed information can be found.

If the peer tries to establish a connection with an incorrect authentication method, or if no connection is expected from this peer IP, the following is logged:

initial Main Mode message received on 192.168.1.254:500 but no connection 
        has been authorized with policy=PUBKEY

Instead of "policy=PUBKEY" it is possible to get "policy=PSK" or "policy=XAUTHRSASIG+XAUTHSERV" if the other party has chosen a corresponding authentication. Check the authentication methods set, the IP of the peer and the tunnel configuration, as the latter affects the IPs that are expected to connect.

If the peer wants to establish the connection with an unauthorized encryption algorithm (in this example a simple DES), the following is logged:

OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM

The peer can propose multiple algorithms. If there are no acceptable ones, the Intra2net system logs this and sends a corresponding message to the peer:

no acceptable Oakley Transform
sending notification NO_PROPOSAL_CHOSEN to 192.168.1.200:500

In this case, the encryption profile on the Intra2net system or on the opposite side must be adapted in such a way that at least one algorithm combination is allowed on both sides.

If everything is configured correctly, phase 1 will be completed successfully:

sent MR3, ISAKMP SA established