Für Phase 1 gibt es zwei verschiedene, alternative Varianten: den Aggressive Mode und den Main Mode. Der Aggressive Mode verzichtet dabei auf eine Diffie-Hellman-Schlüsselvereinbarung, was die Sicherheit wesentlich reduziert. Der Aggressive Mode ist deswegen auf dem Intra2net System nicht implementiert. Verwenden Sie ausschließlich den Main Mode.

Phase 1 beginnt mit dem Aushandeln der zu verwendenden Verschlüsselungsalgorithmen, den sog. Proposals. Diejenige Seite die mit dem Verbindungsaufbau beginnt (Initiator), sendet eine Liste mit Kombinationen von ihr gewünschter Verschlüsselungsalgorithmen, sortiert nach absteigender Präferenz. Die Gegenseite (Responder) pickt sich daraus die erste Kombination heraus, die sie auch akzeptiert. Diese wird dann verwendet.

Die Seite, die auf die Anfrage antwortet (Responder), sieht in diesem Moment ausschließlich die Liste mit Kombinationen von gewünschten Verschlüsselungsalgorithmen. Sie weiß aber nicht um welche Verbindung es sich handelt die in diesem Moment aufgebaut werden soll. Die dafür nötigen IKE-IDs werden erst später übertragen. Ist für die Gegenseite eine feste IP konfiguriert, kann diese für die Auswahl der konfigurierten Verschlüsselungsalgorithmen verwendet werden. Für alle Verbindungen mit unbekannten oder dynamischen IPs bleibt nur die Möglichkeit einen gemeinsamen Satz an Kombinationen mit Verschlüsselungsalgorithmen festzulegen.

Gleichzeitig werden auch die jeweils unterstützten Erweiterungen von IKEv1 ausgehandelt. Erweiterungen sind Dinge wie z.B. NAT-Traversal. Dafür werden sog. Vendor Payloads mit der Liste der Proposals gesendet. Die Gegenseite antwortet auf die Vendor Payloads die sie kennt und ignoriert alle unbekannten.

Nach der Einigung auf einen Satz an Verschlüsselungsalgorithmen wird als nächstes mit dem Diffie-Hellman-Verfahren ein Satz an Sitzungsschlüsseln ausgehandelt. Mit diesen Sitzungsschlüsseln wird der Rest des IKE-Protokolls geschützt, nicht aber die eigentlichen Nutzdaten.

Darauf folgt der Austausch der IKE-IDs und die Authentifizierung. Jede der beiden Seiten muss sich zwingend gegenüber ihrer Gegenseite authentifzieren.

Ist eine Authentifizierung per Zertifikat konfiguriert, werden hier die passenden Zertifikate ausgewählt und zur Gegenseite übertragen. Für die eigentliche Authentifizierung wird eine Zufallszahl genommen, für den öffentlichen Schlüssel der Gegenseite verschlüsselt und gesendet. Nur der Inhaber des privaten Schlüssels kann diese entschlüsseln und damit die Authentifizierungsanfrage korrekt beantworten.

Bei der Authentifizierung per Pre-Shared-Key wird dagegen das gesamte Paket mit dem Pre-Shared-Key verschlüsselt. Das Paket enthält dabei auch die IKE-IDs. Die Gegenseite braucht daher einen anderen Mechanismus, um zu entscheiden welcher Pre-Shared-Key genutzt werden soll. Sind die IP-Adressen beider Seiten statisch, können diese dafür verwendet werden. Alle Verbindungen mit dynamischen IP-Adressen müssen dagegen den selben Pre-Shared-Key verwenden.

	Achtung
	Den selben Pre-Shared-Key für mehere Verbindungen zu verwenden stellt ein Sicherheitsrisiko dar. Es wird daher ausdrücklich von dieser Konfiguration abgeraten. Verwenden Sie statt dessen besser IKEv2 oder bei IKEv1 die Authentifizierung per Zertifikat.

Eine erfolgreiche Authentifizierung wird in den Logs als "IKE SA" oder "ISAKMP SA" protokolliert. SA steht dabei für Security Association. Damit ist Phase 1 abgeschlossen. Phase 1 benötigt 6 aufeinander folgende Nachrichten.

Mode Config ist eine optionale Erweiterung von IKEv1. Es dient dazu einem VPN-Client Verbindungsparameter vorzugeben. Übliche Parameter sind dabei die vom Client für das VPN zu nutzende IP-Adresse, die IP-Netze im VPN-Tunnel und ein DNS-Server im VPN-Tunnel. Die Übertragung von Mode Config findet zwischen Phase 1 und 2 statt.

Mode Config gibt es in den zwei Varianten Push und Pull.

Bei Mode Config Push sendet der VPN-Server dem Client ungefragt die Verbindungsparameter. Kommt es in diesem Moment zu einer Übertragungsstörung oder Überschreitung der maximalen Paketgröße, ist keine Möglichkeit vorgesehen die Übertragung zu wiederholen und der Verbindungsaufbau schlägt fehl. Daher ist die Variante Push weniger robust.

Bei Mode Config Pull fragt der VPN-Client die Verbindungsparameter von sich aus an. Bei einer Störung wiederholt er die Anfrage. Mode Config Pull ist daher robuster und klar der bevorzugte Modus.

Für Phase 2 gibt es dagegen nur eine Variante, den Quick Mode.

Dabei wird eine Liste der gewünschten Tunnel zusammen mit einer Kombination an gewünschten Verschlüsselungsalgorithmen (Proposals) gesendet. Ein Tunnel besteht dabei immer aus der Kombination von Quell- und Zielnetz, jeweils inkl. Netzmaske. Die Gegenseite vergleicht diese Tunnel mit der bei ihr vorliegenden Konfiguration. Die Konfiguration eines Tunnels muss auf beiden Seiten exakt identisch vorliegen.

Die Gegenseite pickt sich dann die erste Kombination an den gesendeten Verschlüsselungsalgorithmen heraus die sie akzeptiert. Sie leitet dann entweder aus dem Sitzungsschlüssel von Phase 1 Sitzungsschlüssel für die Nutzdaten ab oder handelt per Diffie-Hellman-Verfahren neue aus. Mit den Daten wird der Tunnel der Gegenseite bestätigt. In den Logs wird dies dann üblicherweise als erfolgreiche "IPSec SA" protokolliert.

Stimmen die Tunneldaten nicht überein, wird die Fehlerkennung INVALID-ID-INFORMATION gesendet. Konnte kein übereinstimmender Satz an Verschlüsselungsalgorithmen gefunden werden, wird NO-PROPOSAL-CHOSEN gesendet.

Die vorher ausgehandelten Sitzungsschlüssel werden verwendet um die eigentlichen Nutzdaten zu verschlüsseln. Diese werden über das ESP-Protokoll (Encapsulating Security Payload, IP Protokollnr. 50) übertragen. Wurde dagegen NAT-Traversal zum Überbrücken eines NAT-Routers aktiviert, werden die Nutzdaten in UDP-Pakete an Port 4500 eingepackt. Dies hat aber einen größeren Protokolloverhead zur Folge als bei ESP.

Phase 2 benötigt 3 aufeinander folgende Nachrichten. Phase 1 und 2 zusammen kommen daher auf mindestens 9 aufeinander folgende Nachrichten.

Sowohl Phase 1 als auch Phase 2 werden regelmäßig erneuert. Bei Phase 1 geschieht dies zum Erneuern der Sitzungsschlüssel und um sicherzustellen, dass die beiden Gegenseiten weiterhin berechtigt sind die Verbindung aufzubauen. Bei Phase 2 geschieht dies um regelmäßig neue Sitzungsschlüssel auszuhandeln. Bei zu langer Verwendung der selben Sitzungsschlüssel wären ansonsten evtl. Angriffe auf die Verschlüsselung über statistische Muster möglich.

Die Lebensdauer für Phase 1 ist dabei üblicherweise deutlich länger als die von Phase 2. Typische Lebensdauern für Phase 1 reichen von mehreren Stunden bis zu einem Tag. Übliche Lebensdauern für Phase 2 reichen dagegen von 30 Minuten bis zu 3 Stunden.

Phase 1 und Phase 2 können unabhängig voneinander erneuert werden.

Wurde die Offline-Erkennung, auch Dead-Peer-Detection (DPD) genannt, aktiviert, wird die in Phase 1 ausgehandelte Verbindung genutzt um regelmäßig zu prüfen ob die Gegenseite noch antwortet. Es werden dann regelmäßig DPD-Anfragen gesendet. Kommt auf diese keine Antwort mehr, wird nach einiger Zeit die Verbindung als unterbrochen erkannt. Abhängig von der Konfiguration wird dann versucht sie neu aufzubauen.