Ein Beispiel für eine Zeile aus einer System-Logdatei:

Nov  5 10:54:40 intra pluto[2332]: "C2"[1] 192.168.1.200 #1: 
   responding to Main Mode from unknown peer 192.168.1.200

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 demselben 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

In Phase 2 werden die Daten für die IP-Tunnel ausgehandelt. Tritt hier ein Fehler auf, so sind meistens falsche IP-Adressen für den Tunnel hinterlegt. Allerdings kann es auch hier nicht passende Verschlüsselungsalgorithmen geben.

Nicht passende IP-Adressen werden wie folgt protokolliert:

cannot respond to IPsec SA request because no connection is known for 
    192.168.2.0/24===192.168.1.254[CN=server-vpn]...192.168.1.200[CN=client1]

In diesem Fall wurde beim Client vergessen, die virtuelle IP zu konfigurieren. Das kann man daran erkennen, dass hinter der IP des Clients kein Netz mehr angegeben ist. Daher möchte der Client eine Verbindung mit seiner realen IP statt mit der virtuellen aufbauen (was häufig wegen NAT fehlschlägt).

Ein Verbindungsversuch mit einer falschen virtuellen IP (hier 192.168.2.78) sähe dagegen so aus:

cannot respond to IPsec SA request because no connection is known for 
    192.168.2.0/24===192.168.1.254[CN=server-vpn]...
    192.168.1.200[CN=client1]===192.168.2.78/32

Möchte die Gegenstelle eine Verbindung ohne PFS (Perfect Forward Secrecy) aufbauen, auf dem Intra2net System ist es aber aktiviert, sieht das in den Logs so aus:

we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION
sending encrypted notification NO_PROPOSAL_CHOSEN to 192.168.1.200:500

Auch in Phase 2 müssen die Verschlüsselungsalgorithmen zusammenpassen. Tun sie dies nicht (im Beispiel möchte der Client mit einfachem DES verschlüsseln), sieht dies wie folgt aus:

IPSec Transform [ESP_DES (64), AUTH_ALGORITHM_HMAC_SHA1] refused due 
    to insecure key_len and enc. alg. not listed in "esp" string
no acceptable Proposal in IPsec SA
sending encrypted notification NO_PROPOSAL_CHOSEN to 192.168.1.200:500

Ein erfolgreicher Verbindungsaufbau wird dagegen so protokolliert:

IPsec SA established