IPSec - End to Site / Roadwarrior

Konfiguration einer End-to-Site-Verbindung mit IPSec für Roadwarrior

Letzte Anpassung zur Version: 12.5.0

Neu:

IKEv2 Lifetime und Rekeying werden ggf. automatisch getauscht
Schwache Algorithmen werden in den Auswahldialogen nur nach ausdrücklicher Aktivierung angezeigt
Ausblendung von IKEv1 L2TP. Einblendung erst bei spezieller Aktivierung (v12.4)
PSK in Zwischenablage kopieren (v12.4)
Hinweis auf Config_mode bei NCP- oder Greenbow-Clients (v12.4)

Vorherige Versionen: 12.4 12.2.5 12.2.3 11.8 11.7 11.6.12

Einleitung

Eine Roadwarrior-Verbindung verbindet einzelne Hosts mit dem lokalen Netzwerk. Dadurch kann sich beispielsweise ein Außendienstmitarbeiter mit dem Netzwerk der Zentrale verbinden.
In dieser Schritt für Schritt Anleitung wird die Konfiguration einer End-to-Site Verbindung gezeigt. Der gewählte Verbindungstyp ist native IPSec mit IKEv1.
Für native IPSec Verbindungen mit IKEv1 benötigt der Client ein separates Programm.

Konfiguration einer nativen IPSec Verbindung

Neue Verbindungen werden im Menü → VPN →IPSecReiter Verbindungen mit der Schaltfläche IPSec Verbindung hinzufügen hinzugefügt.

Einrichtungsassistent

Verbindungstyp Schritt 1 - Verbindungstyp
Beschriftung	Wert	Beschreibung	Einrichtungsschritt 1
Auswahl des Verbindungs-Typs	Es stehen folgende Verbindungen zur Verfügung: Roadwarrior Site to Site	Für die Konfiguration einer E2S / End-to-Site-Verbindung wird Roadwarrior ausgewählt.

Allgemein Schritt 2 - Allgemein
Name:	IPSec Roadwarrior	Name für die Verbindung	Einrichtungsschritt 2
Verbindungstyp:	IKEv1 - Native	Mögliche Verbindungstypen: IKEv1 - XAuth IKEv1 - Native IKEv2 - Native IKEv1 - L2TP Neu ab: 12.4Neu ab: 12.4 Der Verbindungstyp IKEv1 - L2TP ist nur auswählbar, wenn L2TP auf Autostart steht, oder explizit im Admininterface aktiviert wird. L2TP aktivieren unter: → Extras →Erweiterte EinstellungenReiter Ausgeblendete Funktionen L2TP aktivieren: Ja Ausgeblendete Menüschaltflächen aktivieren: Strg + Alt + A Bitte beachten, welcher Typ vom Betriebssystem unterstützt wird.

Beim Einrichtungsschritt 2 stehen zwei grundverschiedene Verbindungstypen zur Auswahl. Je nachdem ob ein Verbindungstyp von IKEv1, oder IKEv2 ausgewählt wird, unterscheiden sich die kommenden Einrichtungsschritte 3 und 4: Beim Einrichtungsschritt 2 stehen zwei grundverschiedene Verbindungstypen zur Auswahl. Je nachdem ob ein Verbindungstyp von IKEv1, oder IKEv2 ausgewählt wird, unterscheiden sich die kommenden Einrichtungsschritte 3 und 4:
Lokal – IKEv1 Schritt 3 - Lokal - IKEv1
Local Gateway ID:		Die Gateway ID fließt in die Authentifizierung mit ein. Dies kann eine IP-Adresse, ein Hostname oder eine Schnittstelle sein. Wird bei einer Auswahl eines X.509 Zertifikats automatisch ausgefüllt	Einrichtungsschritt 3 - IKEv1
Authentifizierungsmethode:	Pre-Shared Key	Ein Pre-Shared Key wird verwendet
	Zertifikat	Ein vorhandenes Zertifikat wird verwendet
	RSA	Ein vorhandener privater RSA-Schlüssel wird verwendet
Pre-Shared Key:		Ein beliebiger PSK
X.509 Zertifikat: Nur bei Authentifizierungsmethode Zertifikat und EAP-TLS	Server-Zertifikat	Auswahl eines Zertifikates
Privater RSA-Schlüssel:	IPSec Key	Auswahl eines RSA-Schlüssels
Netzwerke freigeben: Nur bei IKEv1 - Native	192.168.250.0/24	Netzwerke für die IPSec-Verbindung freigeben

Lokal – IKEv2 Schritt 3 - Lokal - IKEv2
Local Gateway ID:		Die Gateway ID fließt in die Authentifizierung mit ein. Dies kann eine IP-Adresse, ein Hostname oder eine Schnittstelle sein. Wird bei einer Auswahl eines X.509 Zertifikats automatisch ausgefüllt	Einrichtungsschritt 3 - IKEv2
Authentifizierungsmethode:	Pre-Shared Key	Ein Pre-Shared Key wird verwendet
	Zertifikat	Ein vorhandenes Zertifikat wird verwendet
	RSA	Ein vorhandener privater RSA-Schlüssel wird verwendet
	EAP-TLS Nur bei IKEv2	EAP-TLS wird verwendet. Wird für MSCHAPv2 benötigt.
Pre-Shared Key:		Ein beliebiger PSK
		Erstellt einen sehr starken Schlüssel
		Kopiert den PSK in die Zwischenablage
X.509 Zertifikat: Nur bei Authentifizierungsmethode Zertifikat und EAP-TLS	Server-Zertifikat	Auswahl eines Zertifikates
Privater RSA-Schlüssel:	IPSec Key	Auswahl eines RSA-Schlüssels
Netzwerke freigeben:	192.168.250.0/24	Netzwerke für die IPSec-Verbindung freigeben

Gegenstelle – IKEv1 Schritt 4 - Gegenstelle - IKEv1
Öffentlicher RSA-Schlüssel: Nur bei Authentifizierungsmethode RSA	IPSec Key	Der benötigte öffentlicher RSA-Schlüssel der Gegenstelle	Einrichtungsschritt 4 - IKEv1
IP-Adresse / Pool: Nur bei IKEv1 - XAuth	192.168.22.35/24	IP-Adresse, bzw. Pool für den Aufbau der IPSec-Verbindungen
Öffne Benutzerdialog nach Beendigung: Nur bei IKEv1 - L2TP und IKEv1 - XAuth	Ja	Öffnet im Anschluss an den Assistenten den Benutzer-Dialog der UTM. Für den Aufbau dieser Verbindung ist die Eingabe von Benutzerdaten nötig. Der Benutzer benötigt die nötigen Rechte.
Remote Gateway ID: Nur bei IKEv1 - Native	192.0.2.192 oder Mein_Roadwarrior	Wird mehr als eine IPSec-Verbindung eingerichtet, sollte hier unbedingt eine eindeutige ID eingetragen werden. Das Kennwort ankommender Verbindungen wird anhand der ID der IPSec-Verbindung überprüft. Wird als ID keine IP-Adresse angegeben, sind bei Site-to-Site-Verbindungen weitere Einstellungen vorzunehmen.
IP-Adresse(n): Nur bei IKEv1 - Native	192.168.222.35	Zusätzliche IP-Adresse für den Roadwarrior, mit der die IPSec-Verbindung aufgebaut wird. Für dieses Beispiel wird nach Beendigung des Assistenten die soeben angegebene Adresse bearbeitet und für das Remote-Netzwerk der Wert 192.168.222.0/24 eingetragen.

Gegenstelle – IKEv2 Schritt 4 - Gegenstelle - IKEv2
Öffentlicher RSA-Schlüssel: Nur bei Authentifizierungsmethode RSA	IPSec Key	Der benötigte öffentlicher RSA-Schlüssel der Gegenstelle	Einrichtungsschritt 4 - IKEv2
IP-Adresse / Pool:	192.168.22.35/24	IP-Adresse, bzw. Pool für den Aufbau der IPSec-Verbindungen
Authentifizierungsmethode: Nur bei Authentifizierungsmethode Zertifikat oder EAP-TLS	Zertifikat	Ein vorhandenes Zertifikat wird verwendet
	EAP-MSCHAPV2	EAP-MSCHAPV2 wird verwendet
	EAP-TLS	EAP-TLS wird verwendet. Wird für MSCHAPv2 benötigt.
X.509 Zertifikat: Nur bei Authentifizierungsmethode Zertifikat oder EAP-TLS	IPSec Cert	Das Zertifikat für die Gegenstelle Es müssen zwei unterschiedliche Zertifikate für die lokale und die remote Seite ausgewählt werden.
Benutzergruppe: Nur bei EAP-MSCHAPv2	IPSec Benutzergruppe	Auswahl der berechtigten Benutzergruppe. Diese muss vorher erstellt werden.

Beenden des Einrichtungsassistenten mit Fertig

Regelwerk

Um den Zugriff, auf das Interne Netz zu gewähren muss die Verbindung erlaubt werden.

Implizite Regeln Es ist möglich, aber nicht empfehlenswert dies mit impliziten Regeln unter → Firewall →Implizite Regeln Abschnitt VPN und Abschnitt IPSec Traffic zu konfigurieren. Diese Impliziten Regeln geben die Ports, die für IPSec Verbindungen genutzt werden, jedoch auf allen Schnittstellen frei. Es ist möglich, aber nicht empfehlenswert dies mit impliziten Regeln unter → Firewall →Implizite Regeln Abschnitt VPN und Abschnitt IPSec Traffic zu konfigurieren. Diese Impliziten Regeln geben die Ports, die für IPSec Verbindungen genutzt werden, jedoch auf allen Schnittstellen frei.			Implizite Regeln, Abschnitt VPN Implizite Regeln, Abschnitt IPSec Traffic

Netzwerkobjekt anlegen → Firewall →PortfilterReiter Netzwerkobjekte Schaltfläche Objekt hinzufügen
Beschriftung	Wert	Beschreibung	Netzwerkobjekte
Name:	ngrp-IPSec-Roadwarrior	Name für das IPSec-Netzwerkobjekt
Typ	VPN-Netzwerk	zu wählender Typ
Adresse:	192.168.222.0/24	Roadwarrior IP-Adresse oder der Roadwarrior Pool angegeben, der im Installationsassistenten im Schritt 4 eingetragen (oder nachträglich in Phase 2 angepasst) wurde. In diesem Beispiel also das Netzwerk 192.168.222.0/24.
Zone	vpn-ipsec	zu wählende Zone
Gruppe:		Optional: Gruppe

Portfilter Regeln		Portfilter-Regel mit Test-Ping auf die Schnittstelle der internen dmz1
Portfilter Regel anlegen unter → Firewall →PortfilterReiter Portfilter Schaltfläche Regel hinzufügen Die erste Regel ermöglicht, dass der IPSec-Tunnel überhaupt aufgebaut wird.
Quelle	internet	Quelle, aus welcher der Zugriff auf das interne Netz erfolgen soll.
Ziel	external-interface	Schnittstelle, auf der die Verbindung ankommt.
Dienst	ipsec	Vordefinierte Dienstgruppe für IPSec Dienst / Protokoll, Port isakmp / udp 500 nat-traversal / udp 4500 Protokoll esp
Eine zweite Regel erlaubt dem Roadwarrior den Zugriff auf das gewünschte Netzwerk, einen Host oder eine Netzwerkgruppe.
Quelle	IPSec Roadwarrior	Roadwarrior-Host oder -Netzwerk
Ziel	dmz1-network	Netzwerk, auf das zugegriffen werden soll.
Dienst	xyz	Gewünschter Dienst oder Dienstgruppe

Jetzt kann eine Verbindung mit einem Roadwarrior hergestellt werden.
Hierzu muss ggf. ein Client verwendet werden. Es muss darauf geachtet werden, dass in allen Phasen der Verbindung die Parameter auf beiden Seiten jeweils identisch sind.

Notwendige Änderungen, bei Verwendung eines NCP- oder Greenbow-Clients:

UTM
- Diffie-Hellman Group (Phase 1)
- DH-Gruppe (PFS) (Phase 2)
  oder
NCP- oder Greenbow-Client:
- IKE-DH-Gruppe

Bei Verwendung von IKEv1 außerdem:

NCP- oder Greenbow-Client:
- Austausch-Modus: Main Mode (IKEv1)
- Config_mode aktivieren

Weitere Einstellungen

Neben den Einstellungen, die auch schon im Assistenten festgelegt wurden, lassen sich weitere Parameter konfigurieren:

IKEv1

{{var | DH-Gruppe (PFS) | DH-Gruppe (PFS): | DH-Group (PFS):

Beschriftung	Wert	Beschreibung
Phase 1
→ VPN →IPSecReiter Verbindungen Schaltfläche Phase 1 Allgemein Reiter Allgemein
Beschriftung	Wert	Beschreibung	Phase 1 Allgemein	Phase 1 Allgemein	Phase 1 Allgemein	Phase 1 Allgemein
Beliebige Remote-Adressen erlauben:	Ein Default	Diese Option deaktivieren für Site to Site-Verbindungen mit DynDNS-Hosts, wenn mehrere IPsec-Verbindungen mit a priori unbekannten Adressen (DynDNS S2S, Roadwarrior) konfiguriert sind.
Startverhalten:	Outgoing	Der Tunnel wird von der UTM initiiert, auch wenn keine Pakete gesendet werden. Eingehende Anfragen werden entgegen genommen.
	Incoming Default wenn Remote Host beliebig	Die UTM nimmt eingehende Tunnelanfragen entgegen. Ausgehend wird keine Verbindung erstellt.
	Route Default wenn Remote Host benannnt	Der Tunnel wird von der UTM nur dann initiiert, wenn Pakete gesendet werden sollen. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist.
	Route Default wenn Remote Host benannnt	Der Tunnel wird von der UTM nur dann initiiert, wenn Pakete gesendet werden sollen. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist.
Ignore	Deaktiviert den Tunnel
Verkehr generieren: Neu ab v12.4Neu ab v12.4 Bei Startverhalten Route	Ein	Verhindert unerwünschte Verbindungsabbrüche, wenn kein Datenverkehr stattfindet
Dead Peer Detection:	Ein	Überprüft in einem festgelegtem Intervall, ob der Tunnel noch besteht. Wurde der Tunnel unerwartet beendet, werden die SAs abgebaut. (Nur dann ist es auch möglich einen neuen Tunnel wieder herzustellen.) Bei Aus Deaktivierung wird automatisch auch die Option Neustart nach Abbruch in Phase 2 deaktiviert.
DPD Timeout:	30 Sekunden	Zeitraum, bevor der Zustand unter Startverhalten wieder hergestellt wird Unter IKEv2 steht dieser Parameter nicht zur Verfügung. Hier werden die gleichen Werte verwendet, wie für normale Pakete.
DPD Intervall:	10 Sekunden	Intervall der Überprüfung
Compression:	Aus	Kompression wird nicht von allen Gegenstellen unterstützt
MOBIKE aktivieren:	Ja Default	Dient zur Deaktivierung der MOBIKE Option Die Deaktivierung verhindert, dass verschlüsselte Daten von einer Gegenstelle zusätzlich in 4500udp gekapselt werden, was zu Problemen in der Kommunikation führt.

Reiter IKE Einstellungen, die in der UTM und im Client identisch sein müssen: IKE
Beschriftung	Default-Werte UTM	Default-Werte NCP-Client	Phase 1 IKEv1	Phase 1 IKEv2
Verschlüsselung:	aes128	AES 128 Bit
Authentifizierung:	sha2_256	Hash: SHA2 256 Bit
Diffie-Hellman Gruppe:	ecp521	IKE DH-Gruppe: DH2 (modp1024)
Diffie-Hellman Gruppe:	Neuer Default Wert ab v12.5.1

Reiter IKE Weitere Einstellungen:
Schwache Algorithmen anzeigen: Neu ab v12.5Neu ab v12.5	Aus	Zeigt in den Auswahldialogen auch Algorithmen an, die als schwach gelten und die nicht verwendet werden sollten.
Strict:	Aus	Die konfigurierten Parameter (Authentisierungs- und Verschlüsselungsalgorithmen) werden bevorzugt für Verbindungen verwendet
Strict:	Ein	Es werden keine weiteren Proposals akzeptiert. Eine Verbindung ist nur mit den konfigurierten Parametern möglich.
IKE Lifetime: Änderung ab v12.5Änderung ab v12.5	Aus 3 Stunden	Gültigkeitsdauer der Security Association: Vereinbarung zwischen zwei kommunizierenden Einheiten in Rechnernetzen. Sie beschreibt, wie die beiden Parteien Sicherheitsdienste anwenden, um sicher miteinander kommunizieren zu können. Beim Einsatz mehrerer Dienste müssen auch mehrere Sicherheitsverbindungen aufgebaut werden. (Quelle: Wikipedia 2022) in Phase 1 Kann zusätzlich zu IKE Rekeytime aktiviert Ein werden. Wird die Lifetime gesetzt, muss der Wert größer als die Rekeytime sein.
IKE Lifetime:	1 Stunde	Gültigkeitsdauer der Security Association: Vereinbarung zwischen zwei kommunizierenden Einheiten in Rechnernetzen. Sie beschreibt, wie die beiden Parteien Sicherheitsdienste anwenden, um sicher miteinander kommunizieren zu können. Beim Einsatz mehrerer Dienste müssen auch mehrere Sicherheitsverbindungen aufgebaut werden. (Quelle: Wikipedia 2022) in Phase 1
IKE Rekeytime: Neu ab: v12.4Neu ab: v12.4Änderung ab v12.5Änderung ab v12.5	2 Stunden	Die Gültigkeitsdauer, in der die Verbindung hergestellt wird (initial oder nach Abbruch)
	Ab der Version 12.5.0 wird bei bereits bestehenden Verbindungen, die keine Rekeytime gesetzt haben an dieser Stelle der Wert der Lifetime eingetragen und der Wert der Lifetime auf 0 gesetzt. Dies erhöht die Stabilität der Verbindung signifikant und sollte keinerlei Nachteile mit sich bringen. Wurde bereits ein Wert für die Rekeytime gesetzt (möglich ab v12.4) wird keine Änderung vorgenommen. Beispiel: Aktive Version: ike_lifetime = 2 ike_rekeytime = 0 Nach Update: ike_lifetime = 0 ike_rekeytime = 2 ---- Aktive Version: ike_lifetime = 2 ike_rekeytime = 1 Nach Update: (ohne Änderung) ike_lifetime =2 ike_rekeytime = 1 Ab der Version 12.5.0 wird bei bereits bestehenden Verbindungen, die keine Rekeytime gesetzt haben an dieser Stelle der Wert der Lifetime eingetragen und der Wert der Lifetime auf 0 gesetzt. Dies erhöht die Stabilität der Verbindung signifikant und sollte keinerlei Nachteile mit sich bringen. Wurde bereits ein Wert für die Rekeytime gesetzt (möglich ab v12.4) wird keine Änderung vorgenommen. Beispiel: Aktive Version: ike_lifetime = 2 ike_rekeytime = 0 Nach Update: ike_lifetime = 0 ike_rekeytime = 2 ---- Aktive Version: ike_lifetime = 2 ike_rekeytime = 1 Nach Update: (ohne Änderung) ike_lifetime =2 ike_rekeytime = 1
Rekeying:	unbegrenzt (empfohlen)	Anzahl der Versuche, um die Verbindung herzustellen (initial oder nach Abbruch) Bei E2S-Verbindungen (Roadwarrior) kann die Einstellung 3 mal vermeiden, daß endlos versucht wird eine Verbindung zu nicht korrekt abgemeldeten Geräten herzustellen

Phase 2
→ VPN →IPSecReiter Verbindungen Schaltfläche Phase 2 Allgemein Reiter Allgemein : Einstellungen, die in der UTM und im Client identisch sein müssen:
Beschriftung	Default-Werte UTM	Default-Werte NCP-Client	Phase 2 / Reiter Allgemein mit / IKEv1 / Roadwarrior	Phase 2 / Reiter Allgemein mit / IKEv2 / Roadwarrior	Phase 2 / Reiter Allgemein mit / IKEv1 / S2S	Phase 2 / Reiter Allgemein mit / IKEv2 / S2S
Verschlüsselung:	aes128	AES 128 Bit
Authentifizierung:	sha2_256	SHA2 256 Bit
Diffie-Hellman Gruppe:	ecp521	IKE DH-Gruppe: DH2 (modp1024)
Diffie-Hellman Gruppe:	Neuer Default Wert ab v12.5.1
Diffie-Hellman Gruppe:	Keine	IKE DH-Gruppe: DH2 (modp1024)
Schlüssel-Lebensdauer:	8 Stunden	Schlüssel Lebensdauer in Phase 2
Austausch-Modus	Main Mode (nicht konfigurierbar)	Aggressive Mode (IKEv1) Muss im NCP-Client auf Main Mode geändert werden! Die UTM unterstützt aus Sicherheitsgründen keinen Aggressive Mode.

Reiter Allgemein: Weitere Einstellungen
Schwache Algorithmen anzeigen: Neu ab v12.5Neu ab v12.5	Aus	Zeigt in den Auswahldialogen auch Algorithmen an, die als schwach gelten und die nicht verwendet werden sollten.
Neustart nach Abbruch:	Nein	Wurde die Verbindung unerwartet beendet wird bei Aktivierung Ja der Zustand, der unter Startverhalten in Phase 1 konfiguriert wurde wiederhergestellt. Es wird automatisch die Dead Peer Detection in Phase 1 aktiviert.
Subnetzkombinationen gruppieren:	Ja Wird das Gruppieren von der Gegenstelle nicht unterstützt, wird trotz gegenteiliger Statusanzeige in der Übersicht nur das erste Subnetz verbunden.	Sind auf lokaler Seite oder auf der Gegenstelle mehr als ein Netz konfiguriert, wird bei Deaktivierung für jede Subnetzkombination eine eigene SA ausgehandelt. Dies hat besonders bei mehreren Subnetzen viele Subnetzkombinationen und damit viele SAs zur Folge und führt durch das Design des IPSec-Protokolls zu Limitierungen und zu Einbußen in der Stabilität der Verbindungen.
DHCP:	Aus	Bei Aktivierung (Ein) erhalten die Clients IP-Adressen aus einem lokalen Netz. Dazu sind weitere Konfigurationen erforderlich, siehe Wiki Artikel zu DHCP für IPSec.

Subnetze Reiter Subnetze
	Szenario: Alle Subnetze haben untereinander Zugriff Durch den Assistenten wird automatisch jedes lokale Netz mit jedem remote Netz verbunden. Mit einem SSH-Login als root lässt sich das Verhalten besonders gut nachvollziehen. Beispiel mit jeweils zwei Subnetzen. Subnetzkombinationen gruppieren Aktiviert Ein `root@firewall:~# swanctl --list-conns` `IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 192.168.219.0/24 remote: 192.168.192.0/24 192.168.193.0/24` Subnetzkombinationen gruppieren Deaktiviert Aus `root@firewall:~# swanctl --list-conns` IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.192.0/24 IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.193.0/24 IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.192.0/24 IPSec$20S2S_7: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.193.0/24	Alle Subnetze haben untereinander Zugriff

	Szenario: Nicht alle Subnetze dürfen auf jedes Netz der Gegenstelle zugreifen Wird in Phase zwei ein lokales Netzwerk nicht mit allen remote Netzwerken (oder ein remote Netzwerk nicht mit allen lokalen) verbunden, wird das bei aktiver Option Subnetkombiantionen gruppieren nicht berücksichtigt! Durch die Option Subnetzkombinationen gruppieren werden alle lokalen Netzwerke mit allen remote Netzwerken verbunden! Durch die Option Subnetzkombinationen gruppieren werden alle lokalen Netzwerke mit allen remote Netzwerken verbunden! Portfilterregeln ermöglichen es, den Zugriff zu steuern. Portfilterregeln ermöglichen es, den Zugriff zu steuern. Mit einem SSH-Login als root lässt sich das Verhalten besonders gut nachvollziehen. Beispiel mit jeweils zwei Subnetzen. Subnetzkombinationen gruppieren Aktiviert Ein `root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s` `local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 192.168.219.0/24 remote: 192.168.192.0/24 192.168.193.0/24` Subnetzkombinationen gruppieren Deaktiviert Aus `root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s` `local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.192.0/24 IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.193.0/24 IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.192.0/24`	Das zweite lokale Subnetz wird nur mit einem remote Subnetz verbunden

Troubleshooting

Detaillierte Hinweise zum Troubleshooting finden sich im Troubleshooting-Guide Sollte als Gateway-ID eine E-Mail-Adresse verwendet werden, ist es erforderlich vor die ID ein doppeltes @@ einzufügen (aus mail@… wird @@mail@…). Andernfalls wird die ID als FQDN behandelt

IKEv2

{{var | DH-Gruppe (PFS) | DH-Gruppe (PFS): | DH-Group (PFS):

Beschriftung	Wert	Beschreibung
Phase 1
→ VPN →IPSecReiter Verbindungen Schaltfläche Phase 1 Allgemein Reiter Allgemein
Beschriftung	Wert	Beschreibung	Phase 1 Allgemein	Phase 1 Allgemein	Phase 1 Allgemein	Phase 1 Allgemein
Beliebige Remote-Adressen erlauben:	Ein Default	Diese Option deaktivieren für Site to Site-Verbindungen mit DynDNS-Hosts, wenn mehrere IPsec-Verbindungen mit a priori unbekannten Adressen (DynDNS S2S, Roadwarrior) konfiguriert sind.
Startverhalten:	Outgoing	Der Tunnel wird von der UTM initiiert, auch wenn keine Pakete gesendet werden. Eingehende Anfragen werden entgegen genommen.
	Incoming Default wenn Remote Host beliebig	Die UTM nimmt eingehende Tunnelanfragen entgegen. Ausgehend wird keine Verbindung erstellt.
	Route Default wenn Remote Host benannnt	Der Tunnel wird von der UTM nur dann initiiert, wenn Pakete gesendet werden sollen. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist.
	Route Default wenn Remote Host benannnt	Der Tunnel wird von der UTM nur dann initiiert, wenn Pakete gesendet werden sollen. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist. Wird nur als Default-Wert gesetzt, wenn als Remote Host / Gateway nicht Beliebige Gegenstelle ausgewählt ist.
Ignore	Deaktiviert den Tunnel
Verkehr generieren: Neu ab v12.4Neu ab v12.4 Bei Startverhalten Route	Ein	Verhindert unerwünschte Verbindungsabbrüche, wenn kein Datenverkehr stattfindet
Dead Peer Detection:	Ein	Überprüft in einem festgelegtem Intervall, ob der Tunnel noch besteht. Wurde der Tunnel unerwartet beendet, werden die SAs abgebaut. (Nur dann ist es auch möglich einen neuen Tunnel wieder herzustellen.) Bei Aus Deaktivierung wird automatisch auch die Option Neustart nach Abbruch in Phase 2 deaktiviert.
DPD Timeout:	30 Sekunden	Zeitraum, bevor der Zustand unter Startverhalten wieder hergestellt wird Unter IKEv2 steht dieser Parameter nicht zur Verfügung. Hier werden die gleichen Werte verwendet, wie für normale Pakete.
DPD Intervall:	10 Sekunden	Intervall der Überprüfung
Compression:	Aus	Kompression wird nicht von allen Gegenstellen unterstützt
MOBIKE aktivieren:	Ja Default	Dient zur Deaktivierung der MOBIKE Option Die Deaktivierung verhindert, dass verschlüsselte Daten von einer Gegenstelle zusätzlich in 4500udp gekapselt werden, was zu Problemen in der Kommunikation führt.

Reiter IKE Einstellungen, die in der UTM und im Client identisch sein müssen: IKE
Beschriftung	Default-Werte UTM	Default-Werte NCP-Client	Phase 1 IKEv1	Phase 1 IKEv2
Verschlüsselung:	aes128	AES 128 Bit
Authentifizierung:	sha2_256	Hash: SHA2 256 Bit
Diffie-Hellman Gruppe:	ecp521	IKE DH-Gruppe: DH2 (modp1024)
Diffie-Hellman Gruppe:	Neuer Default Wert ab v12.5.1

Reiter IKE Weitere Einstellungen:
Schwache Algorithmen anzeigen: Neu ab v12.5Neu ab v12.5	Aus	Zeigt in den Auswahldialogen auch Algorithmen an, die als schwach gelten und die nicht verwendet werden sollten.
Strict:	Aus	Die konfigurierten Parameter (Authentisierungs- und Verschlüsselungsalgorithmen) werden bevorzugt für Verbindungen verwendet
Strict:	Ein	Es werden keine weiteren Proposals akzeptiert. Eine Verbindung ist nur mit den konfigurierten Parametern möglich.
IKE Lifetime: Änderung ab v12.5Änderung ab v12.5	Aus 3 Stunden	Gültigkeitsdauer der Security Association: Vereinbarung zwischen zwei kommunizierenden Einheiten in Rechnernetzen. Sie beschreibt, wie die beiden Parteien Sicherheitsdienste anwenden, um sicher miteinander kommunizieren zu können. Beim Einsatz mehrerer Dienste müssen auch mehrere Sicherheitsverbindungen aufgebaut werden. (Quelle: Wikipedia 2022) in Phase 1 Kann zusätzlich zu IKE Rekeytime aktiviert Ein werden. Wird die Lifetime gesetzt, muss der Wert größer als die Rekeytime sein.
IKE Lifetime:	1 Stunde	Gültigkeitsdauer der Security Association: Vereinbarung zwischen zwei kommunizierenden Einheiten in Rechnernetzen. Sie beschreibt, wie die beiden Parteien Sicherheitsdienste anwenden, um sicher miteinander kommunizieren zu können. Beim Einsatz mehrerer Dienste müssen auch mehrere Sicherheitsverbindungen aufgebaut werden. (Quelle: Wikipedia 2022) in Phase 1
IKE Rekeytime: Neu ab: v12.4Neu ab: v12.4Änderung ab v12.5Änderung ab v12.5	2 Stunden	Die Gültigkeitsdauer, in der die Verbindung hergestellt wird (initial oder nach Abbruch)
	Ab der Version 12.5.0 wird bei bereits bestehenden Verbindungen, die keine Rekeytime gesetzt haben an dieser Stelle der Wert der Lifetime eingetragen und der Wert der Lifetime auf 0 gesetzt. Dies erhöht die Stabilität der Verbindung signifikant und sollte keinerlei Nachteile mit sich bringen. Wurde bereits ein Wert für die Rekeytime gesetzt (möglich ab v12.4) wird keine Änderung vorgenommen. Beispiel: Aktive Version: ike_lifetime = 2 ike_rekeytime = 0 Nach Update: ike_lifetime = 0 ike_rekeytime = 2 ---- Aktive Version: ike_lifetime = 2 ike_rekeytime = 1 Nach Update: (ohne Änderung) ike_lifetime =2 ike_rekeytime = 1 Ab der Version 12.5.0 wird bei bereits bestehenden Verbindungen, die keine Rekeytime gesetzt haben an dieser Stelle der Wert der Lifetime eingetragen und der Wert der Lifetime auf 0 gesetzt. Dies erhöht die Stabilität der Verbindung signifikant und sollte keinerlei Nachteile mit sich bringen. Wurde bereits ein Wert für die Rekeytime gesetzt (möglich ab v12.4) wird keine Änderung vorgenommen. Beispiel: Aktive Version: ike_lifetime = 2 ike_rekeytime = 0 Nach Update: ike_lifetime = 0 ike_rekeytime = 2 ---- Aktive Version: ike_lifetime = 2 ike_rekeytime = 1 Nach Update: (ohne Änderung) ike_lifetime =2 ike_rekeytime = 1
Rekeying:	unbegrenzt (empfohlen)	Anzahl der Versuche, um die Verbindung herzustellen (initial oder nach Abbruch) Bei E2S-Verbindungen (Roadwarrior) kann die Einstellung 3 mal vermeiden, daß endlos versucht wird eine Verbindung zu nicht korrekt abgemeldeten Geräten herzustellen

Phase 2
→ VPN →IPSecReiter Verbindungen Schaltfläche Phase 2 Allgemein Reiter Allgemein : Einstellungen, die in der UTM und im Client identisch sein müssen:
Beschriftung	Default-Werte UTM	Default-Werte NCP-Client	Phase 2 / Reiter Allgemein mit / IKEv1 / Roadwarrior	Phase 2 / Reiter Allgemein mit / IKEv2 / Roadwarrior	Phase 2 / Reiter Allgemein mit / IKEv1 / S2S	Phase 2 / Reiter Allgemein mit / IKEv2 / S2S
Verschlüsselung:	aes128	AES 128 Bit
Authentifizierung:	sha2_256	SHA2 256 Bit
Diffie-Hellman Gruppe:	ecp521	IKE DH-Gruppe: DH2 (modp1024)
Diffie-Hellman Gruppe:	Neuer Default Wert ab v12.5.1
Diffie-Hellman Gruppe:	Keine	IKE DH-Gruppe: DH2 (modp1024)
Schlüssel-Lebensdauer:	8 Stunden	Schlüssel Lebensdauer in Phase 2
Austausch-Modus	Main Mode (nicht konfigurierbar)	Aggressive Mode (IKEv1) Muss im NCP-Client auf Main Mode geändert werden! Die UTM unterstützt aus Sicherheitsgründen keinen Aggressive Mode.

Reiter Allgemein: Weitere Einstellungen
Schwache Algorithmen anzeigen: Neu ab v12.5Neu ab v12.5	Aus	Zeigt in den Auswahldialogen auch Algorithmen an, die als schwach gelten und die nicht verwendet werden sollten.
Neustart nach Abbruch:	Nein	Wurde die Verbindung unerwartet beendet wird bei Aktivierung Ja der Zustand, der unter Startverhalten in Phase 1 konfiguriert wurde wiederhergestellt. Es wird automatisch die Dead Peer Detection in Phase 1 aktiviert.
Subnetzkombinationen gruppieren:	Ja Wird das Gruppieren von der Gegenstelle nicht unterstützt, wird trotz gegenteiliger Statusanzeige in der Übersicht nur das erste Subnetz verbunden.	Sind auf lokaler Seite oder auf der Gegenstelle mehr als ein Netz konfiguriert, wird bei Deaktivierung für jede Subnetzkombination eine eigene SA ausgehandelt. Dies hat besonders bei mehreren Subnetzen viele Subnetzkombinationen und damit viele SAs zur Folge und führt durch das Design des IPSec-Protokolls zu Limitierungen und zu Einbußen in der Stabilität der Verbindungen.
DHCP:	Aus	Bei Aktivierung (Ein) erhalten die Clients IP-Adressen aus einem lokalen Netz. Dazu sind weitere Konfigurationen erforderlich, siehe Wiki Artikel zu DHCP für IPSec.

Beschriftung	Wert	Beschreibung
Adress-Pool Reiter Adress-Pool
Lokales Netzwerk:	192.168.250.0/24	Das lokale Netzwerk, auf das über die VPN-Verbindung zugegriffen werden soll (wie im Assistenten in Schritt 3 konfiguriert)
Adress-Pool: Nicht bei IPSec DHCP	192.168.22.35/24	Die IP-Adresse (z.B.: 192.168.22.35/32), oder Pool in Form eines Subnetzes (z.B.: 192.168.22.35/26 für den Pool von 192.168.22.0 -192.168.22.63) welche unter IPSec genutzt wird.

Subnetze Reiter Subnetze
	Szenario: Alle Subnetze haben untereinander Zugriff Durch den Assistenten wird automatisch jedes lokale Netz mit jedem remote Netz verbunden. Mit einem SSH-Login als root lässt sich das Verhalten besonders gut nachvollziehen. Beispiel mit jeweils zwei Subnetzen. Subnetzkombinationen gruppieren Aktiviert Ein `root@firewall:~# swanctl --list-conns` `IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 192.168.219.0/24 remote: 192.168.192.0/24 192.168.193.0/24` Subnetzkombinationen gruppieren Deaktiviert Aus `root@firewall:~# swanctl --list-conns` IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.192.0/24 IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.193.0/24 IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.192.0/24 IPSec$20S2S_7: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.193.0/24	Alle Subnetze haben untereinander Zugriff

	Szenario: Nicht alle Subnetze dürfen auf jedes Netz der Gegenstelle zugreifen Wird in Phase zwei ein lokales Netzwerk nicht mit allen remote Netzwerken (oder ein remote Netzwerk nicht mit allen lokalen) verbunden, wird das bei aktiver Option Subnetkombiantionen gruppieren nicht berücksichtigt! Durch die Option Subnetzkombinationen gruppieren werden alle lokalen Netzwerke mit allen remote Netzwerken verbunden! Durch die Option Subnetzkombinationen gruppieren werden alle lokalen Netzwerke mit allen remote Netzwerken verbunden! Portfilterregeln ermöglichen es, den Zugriff zu steuern. Portfilterregeln ermöglichen es, den Zugriff zu steuern. Mit einem SSH-Login als root lässt sich das Verhalten besonders gut nachvollziehen. Beispiel mit jeweils zwei Subnetzen. Subnetzkombinationen gruppieren Aktiviert Ein `root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s` `local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 192.168.219.0/24 remote: 192.168.192.0/24 192.168.193.0/24` Subnetzkombinationen gruppieren Deaktiviert Aus `root@firewall:~# swanctl --list-conns IPSec$20S2S: IKEv2, reauthentication every 3060s, no rekeying, dpd delay 10s` `local: %any remote: 192.0.2.192 local pre-shared key authentication: id: 192.168.175.218 remote pre-shared key authentication: id: 192.0.2.192 IPSec$20S2S_4: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.192.0/24 IPSec$20S2S_5: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.218.0/24 remote: 192.168.193.0/24 IPSec$20S2S_6: TUNNEL, rekeying every 28260s, dpd action is restart local: 192.168.219.0/24 remote: 192.168.192.0/24`	Das zweite lokale Subnetz wird nur mit einem remote Subnetz verbunden

Troubleshooting

Detaillierte Hinweise zum Troubleshooting finden sich im Troubleshooting-Guide Sollte als Gateway-ID eine E-Mail-Adresse verwendet werden, ist es erforderlich vor die ID ein doppeltes @@ einzufügen (aus mail@… wird @@mail@…). Andernfalls wird die ID als FQDN behandelt

Einleitung

Konfiguration einer nativen IPSec Verbindung

Einrichtungsassistent

Verbindungstyp

Allgemein

Lokal – IKEv1

Lokal – IKEv2

Gegenstelle – IKEv1

Gegenstelle – IKEv2

Regelwerk

Implizite Regeln

Netzwerkobjekt anlegen

Portfilter Regeln

Weitere Einstellungen

IKEv1

Phase 1

Allgemein

IKE

Phase 2

Allgemein

Adress-Pool

Subnetze

Troubleshooting

IKEv2

Phase 1

Allgemein

IKE

Phase 2

Allgemein

Adress-Pool

Subnetze

Troubleshooting