Fehler in Phase 1 bedeuten meistens eine falsche Konfiguration der Authentifizierung (z.B. falsche Zertifikate konfiguriert oder eine andere IPSec-ID verwendet) oder in seltenen Fällen auch falsch konfigurierte Verschlüsselungsalgorithmen.

Am Anfang jeder Verbindung tauschen die Gegenstellen typischerweise Informationen über ihre Fähigkeiten aus und erkennen, ob die Verbindung durch NAT läuft:

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

Danach sendet derjenige, der die Verbindung initiiert, sein Zertifikat:

Peer ID is ID_DER_ASN1_DN: 'CN=client1'

Das System überprüft, ob das Zertifikat über Zertifizierungsstellen vertrauenswürdig ist. Da der Intranator diese Funktion nicht verwendet, schlägt das immer fehl:

issuer cacert not found
X.509 certificate rejected

Als nächstes wird geprüft, ob das Zertifikat bekannt ist. In diesem Beispiel schlägt das fehl, da ein anderes Zertifikat konfiguriert ist:

no RSA public key known for 'CN=client1'

Der Intranator sendet daher eine kurze Fehlerinformation an die Gegenstelle:

sending encrypted notification INVALID_KEY_INFORMATION to 192.168.1.200:500

Baut der Intranator hingegen von sich aus die Verbindung auf, bekommen wir bei dem selben Fehler nur wesentlich weniger Informationen:

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

In diesem Fall sollte das Log der Gegenstelle genauer untersucht werden, hier sind dann meistens detailliertere Informationen zu finden.

Möchte die Gegenstelle die Verbindung mit einem nicht erlaubten Verschlüsselungsalgorithmus aufbauen (in diesem Beispiel einfaches DES), wird folgendes Protokolliert:

OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM

Die Gegenstelle kann mehrere Algorithmen vorschlagen. Ist kein akzeptabler dabei, protokolliert der Intranator dies und sendet der Gegenstelle eine entsprechende Meldung:

no acceptable Oakley Transform
sending notification NO_PROPOSAL_CHOSEN to 192.168.1.200:500

In diesem Fall muß das Verschlüsselungsprofil auf dem Intranator oder der Gegenseite so angepasst werden, daß mindestens eine Algorithmenkombination auf beiden Seiten zulässig ist.

Ist dagegen alles korrekt konfiguriert, wird die Phase 1 erfolgreich abgeschlossen:

sent MR3, ISAKMP SA established