Der Verbindungsaufbau von IKEv2 ist dafür optimiert, möglichst wenige aufeinander folgende Nachrichten zu benötigen. Daher werden unterschiedliche logische Aspekte des Verbindungsaufbaus gemeinsam übertragen.
Im Gegensatz zu IKEv1 gibt es nur eine einzige Variante des Verbindungsaufbaus und keine Alternativen oder unterschiedliche Modi.
Beim ersten Schritt zum Aufbau der IKE_SA werden die zu verwendenden Verschlüsselungsalgorithmen, die sog. Proposals, ausgehandelt. 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 wird auch das Diffie-Hellman-Verfahren genutzt um einen Sitzungsschlüssel zu vereinbaren. Mit diesem Sitzungsschlüssel wird der Rest des IKE-Protokolls geschützt, nicht aber die eigentlichen Nutzdaten.
Als nächstes 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 eine Zufallszahl genommen und mit dem Pre-Shared-Key verschlüsselt. Im Gegensatz zu IKEv1 werden die IKE-IDs nicht mit dem Pre-Shared-Key verschlüsselt. Das Problem von IKEv1 mit der Auswahl des richtigen Pre-Shared-Keys besteht daher bei IKEv2 nicht.
Gleichzeitig mit der Authentifizierung wird bereits eine Liste der gewünschten Tunnel und die Kombination an gewünschten Verschlüsselungsalgorithmen (Proposals) gesendet. Die Authentifizierung, die Aushandlung der Verschlüsselungsalgorithmen für die Nutzdaten und die Aushandlung der Tunnel finden daher gleichzeitig und untrennbar voneinander statt.
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 nicht identisch vorliegen. Es ist auch möglich, dass eine der beiden Seiten nur einen Teil des angebotenen Netzes annimmt und auf diese Weise den Tunnel verengt (das sog. Narrowing).
Gleichzeitig pickt sich die Gegenseite die erste Kombination an den gesendeten Verschlüsselungsalgorithmen heraus die sie akzeptiert. Sie leitet dann aus dem vorher vereinbarten Sitzungsschlüssel weitere Sitzungsschlüssel für die Tunnel ab und bestätigt den Tunnel an die Gegenseite.
Da Authentifizierung, Aushandlung der Verschlüsselungsalgorithmen und der Tunnel gleichzeitig stattfinden, sind alle 3 Punkte immer entweder zusammen erfolgreich oder scheitern gemeinsam. Eine genaue Fehlerursache ist nicht anhand des Protokollfortschritts, sondern nur anhand spezifischer Fehlermeldungen zu erkennen.
Für Aushandlung von IKE_SA und CHILD_SA zusammen werden nur 4 aufeinander folgende Nachrichten benötigt.
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.
Sowohl IKE_SAs als auch CHILD_SAs werden regelmäßig erneuert. Bei IKE_SAs geschieht dies zum Erneuern der Sitzungsschlüssel und um sicherzustellen, dass die beiden Gegenseiten weiterhin berechtigt sind die Verbindung aufzubauen. Bei CHILD_SAs 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 IKE_SAs ist dabei üblicherweise deutlich länger als die von CHILD_SAs. Typische Lebensdauern für IKE_SAs reichen von mehreren Stunden bis zu einem Tag. Übliche Lebensdauern für CHILD_SAs reichen dagegen von 30 Minuten bis zu 3 Stunden.
Der erste Aufbau einer CHILD_SA geschieht immer gleichzeitig mit der Authentifizierung und in diesem Moment ist die Aushandlung der Sitzungsschlüssel durch die direkt vorher erfolgte Schlüsselvereinbarung mit dem Diffie-Hellman-Verfahren geschützt. Daher wird beim ersten Aufbau einer CHILD_SA keine zusätzliche Schlüsselvereinbarung benötigt.
Bei den späteren Erneuerungen der CHILD_SAs ist dies anders. Wird hier Perfect-Forward-Secrecy gewünscht, ist eine weitere Diffie-Hellman-Schlüsselvereinbarung nötig. Sind sich beide Seiten an dieser Stelle in der Konfiguration ob, und mit welchem Algorithmus, uneinig, kann die Erneuerung der CHILD_SA fehlschlagen und in der Folge die Verbindung unterbrochen werden.
Ist konfiguriert, dass die Verbindung immer online sein soll, erkennt die Verbindungsüberwachung die Unterbrechung und baut die Verbindung nach kurzer Zeit neu auf. Diese kurzen Unterbrechungen wiederholen sich dann regelmäßig. Da sie u.U. nicht sofort auffallen, ist bei der Konfiguration ein besonderes Augenmerk auf die Diffie-Hellman-Gruppe bzw. Perfect-Forward-Secrecy-Einstellung für die CHILD_SAs zu richten.
Da IKE_SAs und CHILD_SAs immer gemeinsam aufgebaut werden, hängen CHILD_SAs immer fest mit einer IKE_SA zusammen. CHILD_SAs können unter Verwendung der bestehenden IKE_SA erneuert werden. Eine komplette Erneuerung der IKE_SA (=Reauthentifizierung) bedeutet dagegen, dass auch die zugehörigen CHILD_SAs neu aufgebaut werden müssen.
Abhängig von der Implementation kann diese Reauthentifizierung der IKE_SA daher zu kurzzeitigen Unterbrechungen der Verbindung führen. Deswegen steht die alternative Variante "" bereit, bei der nur die verwendeten Sitzungsschlüssel der IKE_SA erneuert werden, aber keine neue Authentifizierung durchgeführt wird. Da ohne neue Authentifizierung eine Verbindung trotz abgelaufenem Zertifikat der Gegenseite quasi ewig weiter bestehen würde, überwacht das Intra2net System den Zeitpunkt des Zertifikatsablaufs und trennt betroffene Verbindungen aktiv.
Bei VPN-Clients wird aus Sicherheitsgründen empfohlen eine regelmäßige neue Authentifizierung zu fordern, damit der Client regelmäßig beweisen muss, dass er vollen Zugriff auf den privaten Schlüssel hat. Dies erhöht die Sicherheit insbesondere im Zusammenhang mit der Nutzung von Hardware Security-Token oder Smartcards und Eingabe des zugehörigen PIN-Codes.
Bei Netz-zu-Netz-Verbindungen steht meist eher die Stabilität der Verbindung im Vordergrund und gleichzeitig hat der IPSec-Router auf der Gegenseite üblicherweise direkten Zugriff auf den Schlüssel und erfordert keine Eingabe einer PIN oder ähnliches. Daher empfiehlt sich für diesen Anwendungsfall die Nutzung von Rekeying.
Wurde die Offline-Erkennung, auch Dead-Peer-Detection (DPD) genannt, aktiviert, wird die IKE_SA 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.
IKEv2 unterstützt optional die Funktion MOBIKE. Diese erlaubt das Wechseln der externen IP-Adresse einer der Gegenstellen einer Verbindung im laufenden Betrieb und ohne erneute IKE-Aushandlung. Dies ist z.B. bei Wechsel des Zugangsmediums hilfreich.
Allerdings muss die von der IP-Änderung betroffene Gegenstelle diesen Wechsel erkennen und daraufhin von sich aus die IP-Änderung per MOBIKE starten. Findet die Änderung des Zugangsmediums nicht direkt am VPN-Clientsystem, sondern z.B. auf einem Router vornedran statt, bekommt der VPN-Client dies nicht unbedingt rechtzeitig mit.