Wechseln zu:Navigation, Suche
Wiki

UTM/VPN/IPSec-Troubleshooting v12.2: Unterschied zwischen den Versionen

Aus Securepoint Wiki
KKeine Bearbeitungszusammenfassung
 
Zeile 1: Zeile 1:
{{Archivhinweis|UTM/VPN/IPSec-Troubleshooting}}
{{Set_lang}}
{{Set_lang}}


{{#vardefine:headerIcon|spicon-utm}}
{{#vardefine:headerIcon|spicon-utm}}
{{:UTM/VPN/IPSec-Troubleshooting.lang}}
 
{{var | display
| IPSec Troubleshooting
| IPSec Troubleshooting }}
{{var | head
| IPSec Troubleshooting
| IPSec Troubleshooting }}
{{var | Vorbereitung
| Vorbereitung - Log-Level erhöhen
| Preparation - Increase log level }}
{{var | Vorbereitung--desc
| Als Voraussetzung für das erfolgreiche Troubleshooting muss das Log-Level zunächst erhöht werden.<br>
Das kann entweder über eine '''extc-Variable inklusive Neustart des IPSec-Dienstes''' oder '''per SSH zur Laufzeit als root''' vollzogen werden:  
* CLI-Befehl: <br>{{code|extc value set application "ipsec" variable "DBG_LVL_IKE" value [ "2" ] }}<br>Oder in den Erweiterten Einstellungen: {{Menu|Extras|Erweiterte Eistellungen|extc-Variablen}} Suche nach {{ic|DBG_LVL_IKE}} Wert ändern {{Button||w}} auf {{cb|2}}<br>{{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):<br> {{code|ipsec stroke loglevel ike 2}}<br><small>Mit diesem Befehl ist die Einstellung nach einem Neustart wieder auf ihrem Ursprungswert!</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}}
| 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''':
* CLI command: <br>{{code|extc value set application "ipsec" variable "DBG_LVL_IKE" value [ "2" ] }}<br>Or in Advanced Settings: {{Menu|Extras|Advanced Settings|extc variables}} Search for {{ic|DBG_LVL_IKE}} Change value {{Button||w}} to {{cb|2}}<br>{{Hinweis|! § Then the IPSec service must be restarted. This will break all IPSec connections!}}{{a|6}}
* 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
| 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.
| The establishment of an IPSec connection using IKEv1 takes place in two phases. In phase 1, both gateways are authenticated against each other. This can be done in two different ways: The "Agressive Mode" or the "Main Mode". The Agressive Mode encrypts the Pre Shared Key (PSK) using a simple hash algorithm.
Apart from this PSK, no further identification is provided. This results in the following disadvantages:
*When several remote stations are connected, they cannot be distinguished from each other in phase 1. Therefore, the same PSK must be used in all connections. The probability of compromise increases with the number of remote stations.
*The simple hash encryption of the PSK makes it vulnerable to dictionary attacks, and more so the simpler it is. Since no other identification feature is provided besides the PSK, such attacks can be carried out by any computer with Internet access.
 
For these reasons, the Agressive Mode of IPSec does not find any use in connection with Securepoint NextGen UTM. Only the secure Main Mode is used. In addition to the PSK, this requires a further identification feature, the so-called ID. Furthermore, the transmission of the PSK is secured by the Diffie-Hellman key exchange method. This makes it mathematically impossible to intercept a transmitted key. In addition to PSKs, the main mode also allows RSA keys or X.509 certificates for authentication. }}
{{var | IKEv1 Troubleshooting--Bild
| ipsec_troubleshooting01.png
| ipsec_troubleshooting01.png }}
{{var | Phase 1
| Phase 1
| Phase 1 }}
{{var | Der normale Verbindungsaufbau
| Der normale Verbindungsaufbau
| The normal connection setup }}
{{var | Der normale Verbindungsaufbau--Bild
| ipsec_troubleshooting02.png
| ipsec_troubleshooting02-en.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.
| If no errors occur in phase 1, this is indicated by an entry in the LiveLog that reports the successful establishment of an IKE_SA. If this entry is found in both the initiator's log and the responder's log, phase 1 has been configured without errors and for any configuration error should be looked for in phase 2. }}
{{var | Logmeldung
| Logmeldung
| Log message }}
{{var | Falsches Proposal
| Falsches Proposal
| False proposal }}
{{var | Falsches Proposal--Bild
| ipsec_troubleshooting03.png
| ipsec_troubleshooting03-en.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. <br>Der Initiator bekommt die Meldung „NO_PROPOSAL_CHOSEN“.
| If both sides cannot agree on encryption parameters acceptable to both sides, the responder reports this in its livelog. <br>The initiator gets the message "NO_PROPOSAL_CHOSEN". }}
{{var | Initiator-Log
| Initiator-Log
| Initiator-Log }}
{{var | Responder-Log
| Responder-Log
| Responder-Log }}
{{var | Falsche Remote-Gateway-Adresse
| Falsche Remote-Gateway-Adresse
| Incorrect remote gateway address }}
{{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. <br>Der Initiator bekommt die Meldung NO_PROPOSAL_CHOSEN.
| If the initiator attempts to establish a connection from a gateway address other than the one configured on the responder side, the responder cannot classify this connection. This is reported accordingly in the LiveLog. <br>The initiator gets the message NO_PROPOSAL_CHOSEN. }}
{{var | Falsche ID Initiator
| Falsche ID Initiator
| Incorrect 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. <br>Der Initiator erhält die Fehlermeldung AUTHENTICATION_FAILED.
| If the initiator logs in with an identifier (ID) other than the one stored in the responder's configuration, the responder cannot determine a PSK configuration for this connection attempt and reports this accordingly in the LiveLog. <br>The initiator receives the error message AUTHENTICATION_FAILED. }}
{{var | Falsche ID Responder
| Falsche ID Responder
| Incorrect 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.
| If the responder reports with a different ID than in the initiator's configuration, then this is reported accordingly in the initiator's log. }}
{{var | Falscher PSK
| Falscher PSK
|  Incorrect 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.
| In contrast to older software versions, there is no clearly readable hint in the log for mismatched PSKs when using IKEv1. Indirectly, the indication of "malformed" packets points to this error. }}
{{var | Falscher RSA-Key Initiator
| Falscher RSA-Key Initiator
| Incorrect 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. <br>Der Initiator erhält die Fehlermeldung „AUTHENTICATION_FAILED“.
| If the initiator of the connection uses a different RSA key than the one set in the responder configuration, authentication cannot take place. <br>The initiator receives the error message "AUTHENTICATION_FAILED". }}
{{var | Falscher RSA-Key Responder
| Falscher RSA-Key Responder
| Incorrect 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.
| If the responder uses a different RSA key than the one specified in the initiator's configuration, the authentication fails again on the initiator's side. The responder that has already established an IKE_SA is instructed to delete it again. }}
{{var | Phase 2
| 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.
| If phase 2 is also configured correctly, the successful establishment of a CHILD_SA is documented in the livelog of both sides. }}
{{var | Falsche Subnetzkonfiguration
| Falsche Subnetzkonfiguration
| Incorrect subnet configuration }}
{{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.
| If the configured subnets (the so-called traffic selectors) do not match in phase 2 of the initiator and responder, no tunnel can be set up on the previously established IKE_SA, i.e., no CHILD_SA is established. This information can be found in the responder's livelog. }}
{{var | IKEv2 Troubleshooting
| 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.
 
| The establishment of the connection with IKEv2 has been drastically simplified compared to IKEv1. It is now no longer divided into phase 1 (authentication) and phase 2 (tunnel establishment); instead, one message pair is used to exchange first the proposals and DH keys and then the authentication and the traffic selectors (subnets). This makes the connection setup easier and less susceptible to interference. }}
{{var | IKEv2 Troubleshooting--Bild
| ipsec_troubleshooting10.png
| ipsec_troubleshooting10.png }}
{{var | IKEv2 Troubleshooting--cap
| IKEv2 Verbindungsaufbau
| IKEv2 connection setup }}
{{var | Verbindungsaufbau
| Verbindungsaufbau
| Connection setup }}
{{var | IKEv1--Verbindung kommt zustande
| Verbindung kommt zustande
| Connection is established }}
{{var | IKEv2--Verbindung kommt zustande--desc
| Einen erfolgreichen Verbindungsaufbau erkennt man an einer Meldung im Livelog, die die erfolgreiche Etablierung einer CHILD_SA dokumentiert.
| A successful connection can be recognized by a message in the livelog, which documents the successful establishment of a CHILD_SA. }}
{{var | IKEv2: Falsche Remote-Gateway-Adresse
| Falsche Remote-Gateway-Adresse
| Incorrect remote gateway address  }}
{{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. <br>Der Initiator erhält die Fehlermeldung „NO_PROPOSAL_CHOSEN“.
|  If the gateway address of the initiator and the remote gateway address specified in the responder configuration do not match, the connection attempt cannot be assigned. This is reported in the responder's log. <br>The initiator receives the error message "NO_PROPOSAL_CHOSEN".}}
{{var | IKEv2: Falsche ID Initiator
| Falsche ID Initiator
| Incorrect 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. <br>Der Initiator bekommt die Fehlermeldung AUTHENTICATION_FAILED.
| If the configured remote ID does not match the ID reported by the initiator, the connection attempt cannot be assigned here either and is documented in the responder log. <br>The initiator gets the error message AUTHENTICATION_FAILED. }}
{{var | IKEv2 Falsche ID Responder
| Falsche ID Responder
| Incorrect 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.
| Vice versa, a responder ID other than the one configured at the initiator is reported accordingly in the initiator's log. }}
{{var | IKEv2: Falscher PSK
| Falscher PSK
| Incorrect PSK }}
{{var | IKEv2: Falscher PSK--desc
| Stimmt der PSK nicht überein, meldet der Responder, dass der MAC (Message Authentication Code) nicht übereinstimmt. <br>Der Initiator bekommt die Fehlermeldung „AUTHENTICATION_FAILED“
| If the PSK does not match, the responder reports that the MAC (Message Authentication Code) does not match. <br>The initiator gets the error message  „AUTHENTICATION_FAILED“ }}
{{var | IKEv2: Falsche Subnetzkonfiguration
| Falsche Subnetzkonfiguration
| Incorrect subnet configuration }}
{{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.
| If the configured subnets (the so-called traffic selectors) of initiator and responder do not match in the second step, no tunnel can be set up on the previously established IKE_SA, i.e., no CHILD_SA is established. This information can be found in the responder's livelog. }}
{{var | Verwendung von swanctl
| Verwendung von ''swanctl''
| Use of ''swanctl'' }}


</div>{{DISPLAYTITLE:{{#var:display}}}}{{TOC2}}{{Select_lang}}
</div>{{DISPLAYTITLE:{{#var:display}}}}{{TOC2}}{{Select_lang}}

Aktuelle Version vom 22. Juli 2022, 19:11 Uhr





notempty
Dieser Artikel bezieht sich auf eine nicht mehr aktuelle Version!

notempty
Der Artikel für die neueste Version steht hier

notempty
Zu diesem Artikel gibt es bereits eine neuere Version, die sich allerdings auf eine Reseller-Preview bezieht























































De.png
En.png
Fr.png








IPSec Troubleshooting
Letzte Anpassung: 12.2
Neu:
  • Verwendung von swanctl
notempty
Dieser Artikel bezieht sich auf eine Resellerpreview

11.7 11.6.12

Vorbereitung - Log-Level erhöhen

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:
    extc value set application "ipsec" variable "DBG_LVL_IKE" value [ "2" ]
    Oder in den Erweiterten Einstellungen: → Extras →Erweiterte EistellungenReiter extc-Variablen Suche nach DBG_LVL_IKE Wert ändern auf »2
    Anschließend muss derIPSec-Dienst neu gstartet werden. Das Unterbricht sämtliche IPSec-Verbindungen!

  • SSH-Verbindung als root (nur bis Version 12.1.8):
    ipsec stroke loglevel ike 2
    Mit diesem Befehl ist die Einstellung nach einem Neustart wieder auf ihrem Ursprungswert!

  • SSH-Verbindung als root (ab Version 12.2):
    spcli extc value set application ipsec variable DBG_LVL_IKE value 2
    spcli appmgmt config
    swanctl --reload-settings


IKEv1 Troubleshooting

Ipsec troubleshooting01.png

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.



Phase 1

Der normale Verbindungsaufbau

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.
Dienst Nachricht
IPSec(charon) 10[IKE] IKE_SA Standort_1_2[1] established between 198.51.100.75[198.51.100.75]...198.51.100.1[198.51.100.1]


Falsches Proposal

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“.
Initiator-Log
Dienst Nachricht
IPSec(charon) 10[IKE] received NO_PROPOSAL_CHOSEN notify error
Responder-Log
Dienst Nachricht
IPSec(charon) 05[CFG] selecting proposal:
IPSec(charon) 05[CFG] no acceptable ENCRYPTION_ALGORITHM found
IPSec(charon) 05[CFG] selecting proposal:
IPSec(charon) 05[CFG] received proposals: IKE:BLOWFISH_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
IPSec(charon) 05[CFG] configured proposals:IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/HMAC_MD5_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_512/256/AES_XCBC_96/AES_CMAC_96/PRF_AES128_CMAC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP_512/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP_ECP_512_BP,IKE:AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP__521/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP/ECP_512_BP
IPSec(charon) 10[IKE] received proposals inacceptable



Falsche Remote-Gateway-Adresse

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.
Responder-Log
Dienst Nachricht
IPSec(charon) 11[CFG] looking for an ike config for 198.51.100.75...195.51.100.1
IPSec(charon) 11[IKE] no IKE config found for 198.51.100.75...195.51.100.1, sending NO_PROPOSAL_CHOSEN



Falsche ID Initiator

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.
Initiator-Log
Dienst Nachricht
IPSec(charon) 09[IKE] received AUTHENTICATION_FAILED error notify
Responder-Log
Dienst Nachricht
IPSec(charon) 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
IPSec(charon) 07[IKE] no peer config found



Falsche ID Responder

Meldet sich der Responder mit einer anderen ID als in der Konfiguration des Initiators, dann wird dies im Log des Initiators entsprechend gemeldet.
Initiator-Log
Dienst Nachricht
IPSec(charon) 05[IKE] IDir 'blubb' does not match to '198.51.100.75'


Falscher PSK

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.
Initiator-Log
Dienst Nachricht
IPSec(charon) 15[IKE] message parsing failed
IPSec(charon) 15[IKE] ignore malformed INFORMATIONAL request
IPSec(charon) 15[IKE] INFORMATIONAL_V1 request with message ID 1054289493 processing failed
Responder-Log
Dienst Nachricht
IPSec(charon) 14[IKE] message parsing failed
IPSec(charon) 14[IKE] ID_PROT request with message ID 0 processing failed


Falscher RSA-Key Initiator

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“.
Initiator-Log
Dienst Nachricht
IPSec(charon) 15[IKE] authentication of 'Filiale' (myself) succesful
IPSec(charon) 16[IKE] received AUTHENTICATION_FAILED error notify
Responder-Log
Dienst Nachricht
IPSec(charon) 14[CFG] looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
IPSec(charon) 14[CFG] candidate "Standort1_4", match: 1/20/28 (me/other/ike)
IPSec(charon) 14[CFG] selected peer config "Standort1_4"
IPSec(charon) 14[CFG] using trusted certificate "Filiale"
IPSec(charon) 14[IKE] ignature validation failed, looking for another key
IPSec(charon) 14[IKE] no trusted RSA public key found for 'Filiale'


Falscher RSA-Key Responder

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.
Initiator-Log
Dienst Nachricht
IPSec(charon) 16[CFG] authentication of 'Filiale' (myself) succesful
IPSec(charon) 16[IKE] using trusted certificate "Zentrale"
IPSec(charon) 16[IKE] signature validation failed, looking for another key
IPSec(charon) 15[IKE] no trusted RSA public key found for 'Zentrale'
Responder-Log
Dienst Nachricht
IPSec(charon) 10[CFG] looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
IPSec(charon) 10[CFG] candidate "Standort1_4", match: 1/20/28 (me/other/ike)
IPSec(charon) 10[CFG] selected peer config "Standort1_4"
IPSec(charon) 10[CFG] using trusted certificate "Filiale"
IPSec(charon) 10[IKE] authentication of 'Filiale' with RSA succesful
IPSec(charon) 10[IKE] authentication of 'Zentrale' (myself) succesful
IPSec(charon) 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
IPSec(charon) 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
IPSec(charon) 10[IKE] scheduling reauthentication in 2593s
IPSec(charon) 10[IKE] maximum IKE_SA lifetime 3133s
IPSec(charon) 13[IKE] received DELETE for IKE_SA Standort_4[1]


Phase 2

Der normale Verbindungsaufbau

Ist auch die Phase 2 korrekt konfiguriert, wird der erfolgreiche Aufbau einer CHILD_SA im Livelog beider Seiten dokumentiert.
Initiator-Log & Responder-Log
Dienst Nachricht
IPSec(charon) 05[IKE] CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and TS 10.1.10.0/24 === 10.0.0.0/24
IPSec(charon) 05[IKE] CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and TS 10.1.10.0/24 === 10.0.0.0/24

Falsche Subnetzkonfiguration

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.
Initiator-Log
Dienst Nachricht
IPSec(charon) 13[CFH] proposing traffic selectors for us:
IPSec(charon) 13[CFG] 10.1.0.0/24
IPSec(charon) 13[CFG] proposing traffic selectors for other:
IPSec(charon) 13[CFG] 11.0.0.0/24
IPSec(charon) 05[IKE] received INVALID_ID_INFORMATION error notify
Responder-Log
Dienst Nachricht
IPSec(charon) 11[CFG] looking for a child config for 11.0.0.0/24 === 10.1.0.0/24
IPSec(charon) 11[CFG] proposing traffic selectors for us:
IPSec(charon) 11[CFG] 10.0.0.0/24
IPSec(charon) 11[CFG] proposing traffic selectors for other:
IPSec(charon) 11[CFG] 10.1.0.0/24
IPSec(charon) 11[IKE] no matching CHILD_SA config found


IKEv2 Troubleshooting

IKEv2 Verbindungsaufbau

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.

Verbindungsaufbau

Verbindung kommt zustande

Initiator-Log & Responder-Log
Dienst Nachricht
IPSec(charon) 11[CFG] selected proposal_ ESP_AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
IPSec(charon) 11[CFG] selecting traffic selectors for us:
IPSec(charon) 11[CFG] config: 10.1.0.0/24, received: 10.1.0.0/24 => match: 10.1.0.0/24
IPSec(charon) 11[CFG] selecting traffic selectors for ther:
IPSec(charon) 11[CFG] config: 10.0.0.0/24, received: 10.0.0.0/24 0 => match: 10.0.0.0/24
IPSec(charon) 11[IKE] CHILD_SA Zentrale_3{2} established with SPIs c24bb346_i c8e52c94_o and T S 10.1.0.0/24 === 10.0.0.0/24
IPSec(charon) 11[IKE] CHILD_SA Zentrale_3{2} established with SPIs c24bb346_i c8e52c94_o and T S 10.1.0.0/24 === 10.0.0.0/24


Falsche Remote-Gateway-Adresse

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“.
Responder-Log
Dienst Nachricht
IPSec(charon) 11[CFG] looking for an ike config fo 198.51.100.75...198.51.100.1
IPSec(charon) 11[IKE] no IKE config for 198.51.100.75...198.51.100.1, sending NO_PROPOSAL_CHOSEN


Falsche ID Initiator

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.
Initiator-Log
Dienst Nachricht
IPSec(charon) 09[IKE] received AUTHENTICATION_FAILED error notify
Responder-Log
Dienst Nachricht
IPSec(charon) 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
IPSec(charon) 07[IKE] no peer config found


Falsche ID Responder

Umgekehrt wird eine andere als die beim Initiator konfigurierte Responder-ID entsprechend im Log des Initiators gemeldet.
Initiator-Log
Dienst Nachricht
IPSec(charon) 05[IKE] IDir 'blubb' does not match to '198.51.100.75'


Falscher PSK

Initiator-Log
Dienst Nachricht
IPSec(charon) 13[IKE] received AUTHENTICATION_FAILED notify error
Responder-Log
Dienst Nachricht
IPSec(charon) 10[IKE] tried 2 shared keys for '198.51.100.75' - '198.51.100.1', but MAC mismatched


Falsche Subnetzkonfiguration

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.
Initiator-Log
Dienst Nachricht
IPSec(charon) 10[IKE] received T S_UNACCEPTABLE notify, no CHILD_SA built
IPSec(charon) 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Responder-Log
Dienst Nachricht
IPSec(charon) 05[CFG] looking for a child config for 10.0.0.0/24 === 11.1.0.0/24
IPSec(charon) 05[CFG] proposing traffic selectors for us:
IPSec(charon) 05[CFG] 10.0.0.0/24
IPSec(charon) 05[CFG] proposing traffic selectors for other:
IPSec(charon) 05[CFG] 10.1.0.0/24
IPSec(charon) 10[IKE] traffic selectors 10.0.0.0/24 === 11.1.0.0/24 inacceptable
IPSec(charon) 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Abgerufen von „https://wiki.securepoint.de/index.php?title=UTM/VPN/IPSec-Troubleshooting_v12.2&oldid=82688“