IPSec Troubleshooting
Letzte Anpassung: 12.2
Neu:
- Verwendung von swanctl
Vorbereitung - Log-Level erhöhen
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 „Aggressive Mode“ oder dem „Main Mode“. Der aggressive 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 aggressive 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.
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“. | |
| ' | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 10[IKE] received NO_PROPOSAL_CHOSEN notify error |
| ' | |
| 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. | |
| ' | |
| 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. | |
| ' | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 09[IKE] received AUTHENTICATION_FAILED error notify |
| ' | |
| 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. | |
| ' | |
| 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. | |
| ' | |
| 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 |
| ' | |
| 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“. | |
| ' | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 15[IKE] authentication of 'Filiale' (myself) succesful |
| IPSec(charon) | 16[IKE] received AUTHENTICATION_FAILED error notify |
| ' | |
| 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. | |
| ' | |
| 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' |
| ' | |
| 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] |
Der normale Verbindungsaufbau
| Ist auch die Phase 2 korrekt konfiguriert, wird der erfolgreiche Aufbau einer CHILD_SA im Livelog beider Seiten dokumentiert. | |
| & | |
| 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. | |
| ' | |
| 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 |
| ' | |
| 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 |
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
| & | |
| 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“. | |
| ' | |
| 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. | |
| ' | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 09[IKE] received AUTHENTICATION_FAILED error notify |
| ' | |
| 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. | |
| ' | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 05[IKE] IDir 'blubb' does not match to '198.51.100.75' |
Falscher PSK
| ' | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 13[IKE] received AUTHENTICATION_FAILED notify error |
| ' | |
| 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. | |
| ' | |
| 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 |
| ' | |
| 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 |