IPsec-Verschlüsselung: Fehlererkennung beim Verbindungsaufbau

IPSec ist, wie auch SSL, ein Protokoll für die Verschlüsselung von Datenverbindungen. Im Gegensatz zu SSL, welches gewöhnlicher Weise für eine Client-to-Server-Verschlüsselung genutzt wird, kommt IPSec häufig bei Site-to-Site-Verschlüsselung zum Einsatz. IPSec ist im Gegensatz zu SSL anspruchsvoller in Sachen Rechenleistung und wird daher von speziellen Prozessoren, wie man sie zum Beispiel in Routern oder Firewalls findet, übernommen.

Site-to-Site-Verschlüsselung verbindet im Prinzip zwei Netzwerke über eine verschlüsselte Verbindung, die umgangssprachlich meist als „Tunnel“ bezeichnet wird.

Ein IPSec-Verbindungsaufbau vollzieht sich in 2 Phasen, genannt IKE1 und IKE2. Das ist nicht zu verwechseln mit den IKE Versionen 1 & 2 (IKEv1, IKEv2). IKE ist ein Kürzel für das Protokoll „Internet Key Exchange“ und ermöglicht den Aufbau einer abhörsicheren Verbindung in zwei Stufen.

In jeder Phase können Fehler auftreten, verursacht meist durch den Administrator selbst. So müssen zum Beispiel für jede der beiden Phasen Verschlüsselungen zwischen den Teilnehmern ausgehandelt werden. Sollten sich die Teilnehmer, beispielsweise Router oder Firewalls (nachfolgend: Peers), nicht auf eine Verschlüsselung einigen können, schlägt der Verbindungsaufbau fehl.

Im folgenden Beispiel wird das Profil „IKE Crypto“ für IKE Phase 1 erstellt. Die sogenannte „DH Group“ (Diffie-Hellman-Gruppe) ist für den geheimen Schlüsselaustausch über das „unsichere“ Internet verantwortlich. In PanOS 8.0.x von Palo Alto Networks werden derzeit die Gruppen 1,2,5,14,19 und 20 unterstützt. (Aktivierte Checkboxen haben keine Bedeutung für die Funktionalität und beziehen sich auf die Auswahl.)

Als Verschlüsselung geben wir der Phase 1 für die Aushandlung mit dem Peer folgende Möglichkeiten:

  • AES-128-CBC
  • AES-192-CBC
  • AES-256-CBC

Für das Hashing innerhalb des Tunnels erlauben wir folgende Algorithmen:

  • SHA256
  • SHA384
  • SHA512

Die Diffie-Hellman-Group, die Verschlüsselung und das Hashing zusammen ergeben ein sogenanntes „Proposal“ (deutsch: Vorschlag). Während des Verbindungsaufbaus der Phase 1 sendet der „Initiator“ dieses Proposal an den „Responder“. Dieser prüft folgende Dinge:

  • IP oder Hostnamen des Initiators (es gibt noch weitere Möglichkeiten der Identifikation)
  • Pre-Shared Key (Passwort)
  • Diffie-Hellman-Gruppe
  • Verschlüsselung
  • Hashing

Je nachdem wie der Initiator sich bei seinem Peer „vorstellt“ (IP oder Hostname), gibt es hierbei nur ein richtig oder falsch. Entweder der Wert, welcher vom Responder erwartet wird, stimmt, oder er stimmt nicht. Dasselbe gilt für den Pre-Shared Key.

Anders sieht es bei dem mitgesendeten Proposal aus. Hier ist generell eine Mehrfachauswahl gegeben. In unserem Beispiel haben wir zwar nur eine Diffie-Hellman-Gruppe, aber wir könnten, wie bei Hashing oder der Verschlüsselung, auch hier mehrere Werte angeben.

Der „Responder“ wertet nun das Proposal aus, um zu prüfen, ob seine Konfiguration sich mit dem Proposal des „Initiators“ auf einen Wert einigen kann. Kann der Responder einen der geforderten Algorithmen nicht bedienen, schläft der Verbindungsaufbau fehl.

Beispiel:

Dieser Verbindungsaufbau wird auf Grund des „Proposals“ fehlschlagen, da sich die Peers nicht auf einen gemeinsamen Wert einigen können.

In diesem Beispiel steht einem Verbindungsaufbau nichts mehr im Weg.

Im Troubleshooting eines IPSec Tunnels sollte man immer auf der Responder Seite prüfen, wo der Fehler liegt. Der Initiator wird vom Responder natürlich nicht informiert, wieso der Tunnel nicht erstellt worden ist. Wie in der Tabelle angezeigt, wird auf Seiten des Initiators für mehrere Fehler nur das Ergebnis „Timeout“ angegeben. Auf Seiten des Responders sieht man allerdings klar, warum die Verbindung abgelehnt worden ist.

  • Wrong IP/no connection: Der „Initiator“ konnte seinen Peer nicht erreichen (mögliche Gründe sind: keine Verbindung ins Internet, Firewalls blocken den Verbindungsaufbau, eine falsche IP wurde angegeben) 
  • No matching P1 proposal: Sagt aus, dass sich der „Responder“ mit dem Peer nicht auf ein Proposal einigen konnte
  • Mismachted peer ID: Gibt an, dass sich der Initiator falsch vorgestellt oder seinen Peer falsch angesprochen hat

Wie in der Abbildung zu sehen, gibt es einen „Local Identifier“ (wie stellt sich der Initiator vor) und einen „Peer Identifier“ (wie spricht der Initiator seinen Peer an).

Vereinfacht gesagt müssen alle Werte, bis auf die IP Adressen, auf beiden Seiten des Tunnels identisch sein. Die IP Adressen werden natürlich auf jeder Seite vertauscht eingetragen.