Bei der Authentifizierung per Pre-Shared Key steht zur Auswahl, ob die Gegenstelle eine benutzerdefinierte IPSec-ID verwendet oder ihre IP-Adresse. strongSwan Version 4 prüft hier bei der Variante "" ob die IPSec-ID und die IP, von der die Verbindung kommt, identisch sind. Wird erkannt, dass die Gegenstelle hinter einem NAT-Router liegt, kommt die Verbindung nicht von der extern sichtbaren IP selbst und daher kann sie in diesem Fall nicht als IPSec-ID verwendet werden.
Bei strongSwan Version 6 werden dagegen ausschließlich zum Konfigurationszeitpunkt festgelegte IPSec-IDs geprüft. Bei Gegenstellen mit festgelegter IP wird daher die festgelegte IP als IPSec-ID erwartet. Bei per DNS-Hostname konfigurierten Gegenstellen oder Gegenstellen mit dynamischer IP werden dagegen beliebige IPSec-IDs akzeptiert.
Es wird daher empfohlen, immer benutzerdefinierte IPSec-IDs statt IP-Adressen zu verwenden, da diese unabhängig von den IP-Adressen und verwendeten Programmversionen sind. Benutzerdefinierte IPSec-IDs vom Typ E-Mail-Adresse sind hierbei erfahrungsgemäß die Form, die die höchste Kompatibilität und Eindeutigkeit bietet und werden daher empfohlen.
Sollten dennoch IPSec-IDs vom Typ IP verwendet werden, so sind diese bei strongSwan Version 6 auch mit Gegenstellen hinter NAT-Routern nutzbar, da kein Zusammenhang zwischen IPSec-ID und der IP, von der die Verbindung kommt, geprüft wird.
Sollen zu einer Gegenstelle mehrere verschiedene Tunnel aufgebaut werden, so werden in der Oberfläche des Intra2net Systems dafür mehrere Verbindungen angelegt. Auf der Ebene des IKE-Protokolls müssen diese Verbindungen aber zwingend zusammengefasst werden. strongSwan Version 4 macht diese Zusammenfassung dynamisch zur Laufzeit und kann daher z.B. anhand von DNS-Hostnamen konfigurierte Gegenstellen mit solchen zusammenfassen, die per IP-Adresse konfiguriert sind.
Bei strongSwan Version 6 muss die Zusammenfassung der Verbindungen immer zum Konfigurationszeitpunkt stattfinden. Es muss also rein anhand der konfigurierten Parameter festgestellt werden können, ob es sich um dieselbe Gegenstelle oder unterschiedliche handelt.
Die Kombination der folgenden drei Einstellungen kann zu Zuordnungsproblemen führen:
Typ der Gegenstelle: DNS-Hostname oder dynamische IP
Authentifizierung per Pre-Shared-Key
IPSec ID Gegenstelle: "Beliebig (z.B. IP)"
Gibt es mehrere Verbindungen mit identischer Kombination, ist zum Konfigurationszeitpunkt nicht eindeutig, ob es sich um dieselbe oder unterschiedliche Gegenstellen handelt.
Stellen Sie in diesem Fall die IPSec-ID auf "" um und verwenden eindeutige IPSec-IDs für alle Gegenstellen. Benutzerdefinierte IPSec-IDs vom Typ E-Mail-Adresse sind hierbei erfahrungsgemäß die Form, die die höchste Kompatibilität und Eindeutigkeit bietet und werden daher empfohlen.
Ist in einem Verschlüsselungsprofil eine Perfect Forward Secrecy (PFS) Gruppe für Phase 2 konfiguriert und baut die Gegenseite die Verbindung auf, akzeptiert strongSwan Version 4 hier jede beliebige PFS-Gruppe und nicht nur die konfigurierte. Es stellt nur sicher, dass überhaupt eine PFS-Gruppe verwendet wird.
Bei strongSwan Version 6 ist das Verhalten in diesem Fall konfigurierbar. Im Menü "" kann über die Option "" ausgewählt werden, ob dieses Verhalten gewünscht ist oder nicht. Bei der Umstellung von strongSwan Version 4 auf 6 wird diese Option automatisch aktiviert, um bestehende Verbindungen nicht zu beeinträchtigen.
Das mode-config-Protokoll wird verwendet, um Einstellungen wie IP-Adressen und DNS-Server beim Verbindungsaufbau an VPN-Clients zu übermitteln. strongSwan Version 4 unterstützt es ausschließlich in der Variante "".
strongSwan Version 6 unterstützt mode config sowohl im Modus "" als auch "". Allerdings wird ganz ausdrücklich empfohlen ausschließlich den Modus "" zu verwenden, da dieser beim Verbindungsaufbau robuster gegen Störungen ist.
Die VPN-Clients von NCP sowie Apple iOS unterstützen beide Modi und können automatisch den richtigen wählen. Daher werden Verbindungen zu diesen Clients auf dem Intra2net System automatisch auf "" umgestellt sobald strongSwan Version 6 aktiviert wird.
Der Shrew Soft VPN-Client unterstützt auch beide Modi, er kann aber nicht automatisch feststellen welcher Modus auf dem Intra2net System verwendet wird. Es wird daher empfohlen bei der Umstellung auf strongSwan Version 6 zeitnah alle Shrew Soft VPN-Clients auf den Modus "" umzustellen (Reiter "", Option "" in der Verbindungskonfiguration auf dem Client) und dies gleichzeitig auf dem Intra2net System im Menü "" anzupassen.
strongSwan Version 4 sendet beim Verbindungsaufbau von VPN-Clients eine Willkommensnachricht per mode config. Diese wird von den meisten VPN-Clients in einem Pop-up-Fenster dargestellt.
strongSwan Version 6 kann diese Willkommensnachricht nicht übertragen und sie entfällt ersatzlos.
Bei strongSwan Version 4 können Pre-Shared Keys ausschließlich in ASCII-Codierung eingegeben werden. Daher steht nur ein eingeschränkter Satz von Zeichen zur Auswahl.
strongSwan Version 6 erlaubt es zusätzlich Pre-Shared Keys auch in Hexadezimalcodierung einzugeben und ist damit flexibler.
strongSwan Version 4 kann auf IKE-Ebene fragmentierte Pakete, die die Gegenseite sendet, verarbeiten, aber selbst keine Pakete fragmentieren. Diese Pakete werden dann abhängig von Größe und Path-MTU evtl. auf UDP-Ebene fragmentiert. Im Zusammenhang mit zu strikten oder fehlkonfigurierten Routern und Firewalls kann dies in manchen Fällen zu Problemen beim Verbindungsaufbau führen.
strongSwan Version 6 kann sowohl fragmentierte IKE-Pakete verarbeiten als auch bei Bedarf selbst senden. Dies sorgt für einen robusteren Verbindungsaufbau.