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 das Intra2net System 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'

Das Intra2net System sendet daher eine kurze Fehlerinformation an die Gegenstelle:

sending encrypted notification INVALID_KEY_INFORMATION to 192.168.1.200:500

Baut das Intra2net System 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.

Versucht die Gegenstelle eine Verbindung mit einem falschen Authentifizierungsverfahren aufzubauen, oder wird von dieser Gegenstellen-IP keine Verbindung erwartet, so wird folgendes protokolliert:

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

Statt "policy=PUBKEY" können auch "policy=PSK" oder "policy=XAUTHRSASIG+XAUTHSERV" vorkommen wenn die Gegenstelle eine entsprechende Authentifizierung gewählt hat. Kontrollieren Sie die eingestellten Authentifizierungsverfahren, die IP der Gegenstelle sowie die Tunnelkonfiguration, da letztere Auswirkungen auf die IPs hat, von denen eine Verbindung erwartet wird.

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 das Intra2net System 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 muss das Verschlüsselungsprofil auf dem Intra2net System oder der Gegenseite so angepasst werden, dass 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