UTM/VPN/IPSec-Troubleshooting.lang - Versionsgeschichte

Marcels am 11. Januar 2024 um 13:58 Uhr

2024-01-11T13:58:23Z

Lauritzl am 26. August 2022 um 14:53 Uhr

2022-08-26T14:53:38Z

Lauritzl am 22. Juli 2022 um 18:14 Uhr

2022-07-22T18:14:39Z

@@ Zeile 13: / Zeile 13: @@
 		| Preparation - Increase log level }}
 {{var	| Vorbereitung--desc
-		| Als Voraussetzung für das erfolgreiche Troubleshooting muss das Log-Level zunächst erhöht werden.<br>
+		| Alternative Möglichkeiten, das Log-Level zu ändern:
-Das kann entweder über eine '''extc-Variable inklusive Neustart des IPSec-Dienstes''' oder '''per SSH zur Laufzeit als root''' vollzogen werden:
 		| As a prerequisite for successful troubleshooting, the log level must first be increased.<br>
 This can be accomplished either via an '''extc variable including restart of the IPSec service''' or '''via SSH at runtime as root''':
@@ Zeile 23: / Zeile 20: @@
 * SSH connection as root (only up to version 12.1.8):<br> {{code|ipsec stroke loglevel ike 2}}<br><small>With this command the setting is back to its original value after a reboot!</small>{{a|4}}
 * SSH-Verbindung als root (ab Version 12.2):<br>{{code|spcli extc value set application ipsec variable DBG_LVL_IKE value 2<br>spcli appmgmt config<br>swanctl --reload-settings}} }}
 {{var	| IKEv1 Troubleshooting
 		| IKEv1 Troubleshooting
@@ Zeile 175: / Zeile 207: @@
 		| Verwendung von ''swanctl''
 		| Use of ''swanctl'' }}
 {{var	|
+		|

Lauritzl am 10. Januar 2022 um 17:27 Uhr

2022-01-10T17:27:32Z

Änderungen zeigen

Lauritzl: Die Seite wurde neu angelegt: „{{Lang}} {{#vardefine:headerIcon| spicon-utm }} {{var | display | IPSec Troubleshooting | }} {{var | head | IPSec Troubleshooting | }} {{var | Vorb…“

2021-09-30T10:36:03Z

Die Seite wurde neu angelegt: „{{Lang}} {{#vardefine:headerIcon| spicon-utm }} {{var | display | IPSec Troubleshooting | }} {{var | head | IPSec Troubleshooting | }} {{var | Vorb…“

Neue Seite

{{Lang}}

{{#vardefine:headerIcon| spicon-utm }}

{{var | display
| IPSec Troubleshooting
| }}
{{var | head
| IPSec Troubleshooting
| }}
{{var | Vorbereitung
| Vorbereitung - Log-Level erhöhen
| }}
{{var | Vorbereitung--desc
| Als Voraussetzung für das erfolgreiche Troubleshooting muss das Log-Level zunächst erhöht werden. 
Das kann entweder über eine '''extc-Variable inklusive Neustart des IPSec-Dienstes''' oder '''per SSH zur Laufzeit als root''' vollzogen werden:
* CLI-Befehl: {{code|extc value set application "ipsec" variable "DBG_LVL_IKE" value [ "2" ] }} Oder in den Erweiterten Einstellungen: {{Menu|Extras|Erweiterte Eistellungen|extc-Variablen}} Suche nach {{ic|DBG_LVL_IKE}} Wert ändern {{Button||w}} auf {{cb|2}} {{Hinweis|! § Anschließend muss derIPSec-Dienst neu gstartet werden. Das Unterbricht sämtliche IPSec-Verbindungen!}}{{a|6}}
* SSH-Verbindung als root (nur bis Version 12.1.8): {{code|ipsec stroke loglevel ike 2}} Mit diesem Befehl ist die Einstellung nach einem Neustart wieder auf ihrem Ursprungswert!{{a|4}}
* SSH-Verbindung als root (ab Version 12.2): {{code|spcli extc value set application ipsec variable DBG_LVL_IKE value 2 spcli appmgmt config swanctl --reload-settings}}
| }}
{{var | IKEv1 Troubleshooting
| IKEv1 Troubleshooting
| }}
{{var | IKEv1 Troubleshooting--desc
| Der Aufbau einer IPSec-Verbindung unter Verwendung von IKEv1 erfolgt in zwei Phasen. In der Phase 1 erfolgt die Authentifizierung beider Gateways gegeneinander. Dies kann auf zwei verschiedene Arten erfolgen: Dem „Agressive Mode“ oder dem „Main Mode“. Der Agressive Mode verschlüsselt den Pre Shared Key (PSK) über einen einfachen HashAlgorithmus.
Außer diesem PSK sind keine weiteren Identifikationen vorgesehen. Daraus ergeben sich folgende Nachteile:
*Bei Anbindung von mehreren Gegenstellen können diese in der Phase 1 nicht voneinander unterschieden werden. Deshalb muss in allen Verbindungen der gleiche PSK verwendet werden. Die Wahrscheinlichkeit der Kompromittierung steigt mit der Anzahl der Gegenstellen.
*Die einfache Hash-Verschlüsselung des PSK macht ihn gegen Wörterbuch-Attacken verwundbar, und zwar umso mehr, je einfacher dieser ist. Da außer dem PSK kein weiteres Identifikationsmerkmal vorgesehen ist, können solche Attacken von jedem beliebigen Rechner mit Internetzugang durchgeführt werden.

Aus diesen Gründen findet der Agressive Mode von IPSec keine Verwendung in Verbindung mit Securepoint NextGen UTM. Es wird ausschließlich der sichere Main Mode eingesetzt. Dieser fordert außer dem PSK noch ein weiteres Identifikationsmerkmal, die sog. ID. Zudem wird die Übertragung des PSK durch das Diffie-Hellman-Schlüsselaustauschverfahren abgesichert. Dieses macht, mathematisch bewiesen, das Abhören eines übertragenen Schlüssels unmöglich. Weiterhin gestattet der Main Main Mode außer PSKs auch RSA-Schlüssel oder X.509-Zertifikate zur Authentifizierung.
| }}
{{var | IKEv1 Troubleshooting--Bild
| ipsec_troubleshooting01.png
| }}
{{var | Phase 1
| Phase 1
| }}
{{var | Der normale Verbindungsaufbau
| Der normale Verbindungsaufbau
| }}
{{var | Der normale Verbindungsaufbau--Bild
| ipsec_troubleshooting02.png
| }}
{{var | Der normale Verbindungsaufbau--desc
| Kommt es in der Phase 1 zu keinem Fehler, ist dies durch einen Eintrag im LiveLog zu erkennen, der die erfolgreiche Etablierung einer IKE_SA meldet. Findet sich dieser Eintrag sowohl im Log des Initiators als auch in dem des Responders, ist die Phase 1 fehlerfrei konfiguriert und ein eventueller Konfigurationsfehler in der Phase 2 zu suchen.
| }}
{{var | Logmeldung
| Logmeldung
| }}
{{var | Falsches Proposal
| Falsches Proposal
| }}
{{var | Falsches Proposal--Bild
| ipsec_troubleshooting03.png
| }}
{{var | Falsches Proposal--desc
| Können sich beide Seiten nicht auf für beide Seiten annehmbare Verschlüsselungsparameter einigen, dann meldet dies der Responder in seinem Livelog. Der Initiator bekommt die Meldung „NO_PROPOSAL_CHOSEN“.
| }}
{{var | Initiator-Log
| Initiator-Log
| }}
{{var | Responder-Log
| Responder-Log
| }}
{{var | Falsche Remote-Gateway-Adresse
| Falsche Remote-Gateway-Adresse
| }}
{{var | Falsche Remote-Gateway-Adresse--desc
| Versucht der Initiator den Verbindungsaufbau von einer anderen als der auf Seiten des Responders konfigurierten Gateway-Adresse, kann der Responder diese Verbindung nicht zuordnen. Dies wird entsprechend im LiveLog gemeldet. Der Initiator bekommt die Meldung NO_PROPOSAL_CHOSEN.
| }}
{{var | Falsche ID Initiator
| Falsche ID Initiator
| }}
{{var | Falsche ID Initiator--desc
| Meldet sich der Initiator mit einem anderen Identifikator (ID) als in der Konfiguration des Responders hinterlegt, kann dieser keine PSK-Konfiguration für diesen Verbindungsversuch feststellen und meldet dies entsprechend im LiveLog. Der Initiator erhält die Fehlermeldung AUTHENTICATION_FAILED.
| }}
{{var | Falsche ID Responder
| Falsche ID Responder
| }}
{{var | Falsche ID Responder--desc
| Meldet sich der Responder mit einer anderen ID als in der Konfiguration des Initiators, dann wird dies im Log des Initiators entsprechend gemeldet.
| }}
{{var | Falscher PSK
| Falscher PSK
| }}
{{var | Falscher PSK--desc
| Im Gegensatz zu älteren Software-Versionen findet sich bei nicht übereinstimmenden PSKs bei Verwendung von IKEv1 kein klar lesbarer Hinweis im Log. Indirekt weist der Hinweis auf „deformierte“ Pakete auf diesen Fehler hin.
| }}
{{var | Falscher RSA-Key Initiator
| Falscher RSA-Key Initiator
| }}
{{var | Falscher RSA-Key Initiator--desc
| Verwendet der Initiator der Verbindung einen anderen RSA-Key als in der Konfiguration des Responders eingestellt, kann keine Authentifizierung erfolgen. Der Initiator erhält die Fehlermeldung „AUTHENTICATION_FAILED“.
| }}
{{var | Falscher RSA-Key Responder
| Falscher RSA-Key Responder
| }}
{{var | Falscher RSA-Key Responder--desc
| Verwendet der Responder einen anderen RSA-Schlüssel als in der Konfiguration des Initiators angegeben, dann schlägt wiederum auf Seiten des Initiators die Authentifizierung fehl. Der Responder, der bereits eine IKE_SA etabliert hat, wird angewiesen, diese wieder zu löschen.
| }}
{{var | Phase 2
| Phase 2
| }}
{{var | Phase2-Der normale Verbindungsaufbau--desc
| Ist auch die Phase 2 korrekt konfiguriert, wird der erfolgreiche Aufbau einer CHILD_SA im Livelog beider Seiten dokumentiert.
| }}
{{var | Falsche Subnetzkonfiguration
| Falsche Subnetzkonfiguration
| }}
{{var | Falsche Subnetzkonfiguration--desc
| Stimmen die konfigurierten Subnetze (die sogenannten Traffic-Selektoren) in der Phase 2 von Initiator und Responder nicht überein, kann auf der zuvor etablierten IKE_SA kein Tunnel aufgesetzt werden, d.h. es wird keine CHILD_SA etabliert. Dieser Hinweis findet sich im Livelog des Responders.
| }}
{{var | IKEv2 Troubleshooting
| IKEv2 Troubleshooting
| }}
{{var | IKEv2 Troubleshooting--desc
| Der Aufbau der Verbindung mit IKEv2 ist im Vergleich zu IKEv1 massiv vereinfacht worden. Er wird nun nicht mehr aufgeteilt in Phase 1 (Authentifizierung) und Phase 2 (Tunnelaufbau), vielmehr werden mit jeweils einem Nachrichtenpaar zunächst Proposals und DH-Schlüssel und anschließend die Authentifizierung und die Traffic-Selektoren (Subnetze) ausgetauscht. Das macht den Verbindungsaufbau einfacher und weniger störanfällig.

| }}
{{var | IKEv2 Troubleshooting--Bild
| ipsec_troubleshooting10.png
| }}
{{var | IKEv2 Troubleshooting--cap
| IKEv2 Verbindungsaufbau
| }}
{{var | Verbindungsaufbau
| Verbindungsaufbau
| }}
{{var | IKEv1--Verbindung kommt zustande
| Verbindung kommt zustande
| }}
{{var | IKEv2--Verbindung kommt zustande--desc
| Einen erfolgreichen Verbindungsaufbau erkennt man an einer Meldung im Livelog, die die erfolgreiche Etablierung einer CHILD_SA dokumentiert.
| }}
{{var | IKEv2: Falsche Remote-Gateway-Adresse
| Falsche Remote-Gateway-Adresse
| }}
{{var | IKEv2: Falsche Remote-Gateway-Adresse--desc
| Stimmen die Gateway-Adresse des Initiators und die in der Konfiguration des Responders angegebene Remote-Gateway-Adresse nicht überein, kann der Verbindungsversuch nicht zugeordnet werden. Dies wird so im Log des Responders gemeldet. Der Initiator erhält die Fehlermeldung „NO_PROPOSAL_CHOSEN“.
| }}
{{var | IKEv2: Falsche ID Initiator
| Falsche ID Initiator
| }}
{{var | IKEv2: Falsche ID Initiator--desc
| Stimmt die konfigurierte Remote ID nicht mit der ID überein, die der Initiator meldet, dann kann auch hier der Verbindungsversuch nicht zugeordnet werden und dies wird im Responder-Log dokumentiert. Der Initiator bekommt die Fehlermeldung AUTHENTICATION_FAILED.
| }}
{{var | IKEv2 Falsche ID Responder
| Falsche ID Responder
| }}
{{var | IKEv2 Falsche ID Responder--desc
| Umgekehrt wird eine andere als die beim Initiator konfigurierte Responder-ID entsprechend im Log des Initiators gemeldet.
| }}
{{var | IKEv2: Falscher PSK
| Falscher PSK
| }}
{{var | IKEv2: Falscher PSK--desc
| Stimmt der PSK nicht überein, meldet der Responder, dass der MAC (Message Authentication Code) nicht übereinstimmt. Der Initiator bekommt die Fehlermeldung „AUTHENTICATION_FAILED“
| }}
{{var | IKEv2: Falsche Subnetzkonfiguration
| Falsche Subnetzkonfiguration
| }}
{{var | IKEv2: Falsche Subnetzkonfiguration--desc
| Stimmen im zweiten Schritt die konfigurierten Subnetze (die sogenannten Traffic-Selektoren) von Initiator und Responder nicht überein, kann auf der zuvor etablierten IKE_SA kein Tunnel aufgesetzt werden, d.h. es wird keine CHILD_SA etabliert. Dieser Hinweis findet sich im Livelog des Responders.
| }}
{{var |
|
| }}
{{var |
|
| }}

----

{{var |
|
| }}

</div>