Wechseln zu:Navigation, Suche
Wiki

UTM/VPN/IPSec-Troubleshooting v11.7: Unterschied zwischen den Versionen

Aus Securepoint Wiki
Keine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
 
(7 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[kategorie:VPN]]
{{Archivhinweis|UTM/VPN/IPSec-Troubleshooting}}
==IPSec Log Meldungen==
{{DISPLAYTITLE:IPSec Troubleshooting}}
 
== Informationen ==
'''Meldung:'''
Letze Anpassung zur Version: '''11.7'''  
Es ist keine Meldung im Log des IPSec-Servers zu sehen.
 
Ursache:
:Der Dienst ist nicht gestartet.
:Das Paket erreicht die FW nicht.
:Das Paket wird von der FW verworfen.
 
Lösung:
:- Unter "Applikationen -> Dienste Status" prüfen, ob der Dienst "SERVICE_IPSEC" läuft.
:- Im "Portfilter" eine Regel anlegen, die den Zugriff auf das  Eingangs-Interface erlaubt.
 
<br>
'''Meldung:'''
IPSEC Server; "Name der Verbindung" #1: initiating Main Mode
 
Info:
:Dieser Log-Eintrag bedeutet, dass der IPSec Dienst versucht, eine Verbindung aufzubauen. Ist im Log kein weiterer Log-Eintrag des IPSec Dienstes zu sehen, kann davon ausgegangen werden, dass die Gegenstelle die Pakete verwirft oder die Pakete die Gegenstelle nicht erreichen.
 
<br>
'''Meldung:'''
Name der Verbindung"[1] 87.139.55.127 #6: responding to Main Mode from unknown peer IP-INITIATOR
 
Info:
:Der IPSec Dienst hat ein Phase1 Paket  von einer Gegenstelle erhalten, zu der noch keine IPSec Verbindung besteht.
 
<br>
'''Meldung:'''
packet from INITIATOR-IP:500: initial Main Mode message received on Receptor-IP:500
but no connection has been authorized with policy=PSK
 
Fehler:
:Überprüfen Sie die Gateway IP-Adressen und die Gateway IDs, diese unterscheiden sich in der Konfiguration.
 
<div align="right">[[#top|<font size=1>zum Anfang</font>]]</div>
 
<br>
'''Meldung:'''
IPSEC Server; "Name der Verbindung" #1: NAT-Traversal:Result using RFC 3947: peer is NATed
 
Info:
:Diese Meldung bedeutet, dass die Gegenstelle sich hinter einem NAT Gerät befindet.
 
<br>
'''Meldung:'''
IPSEC Server;"Name der Verbindung" #1: NAT-Traversal: Result using RFC 3947: i am NATed
 
Info:
:Der IPSec Dienst hat festgestellt, dass sich die Firewall selbst hinter einem NAT Gerät befindet.
 
<br>
'''Meldung:'''
IPSEC Server;packet from IP-Gegenstelle:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
 
Ursache:
:Die Einstellungen unter Phase1 stimmen nicht überein.
 
Lösung:
: Bitte gleichen Sie die Einstellungen in Phase1 beider FWs ab.
 
<br>
'''Meldung:'''
IPSEC Server;"Name der Verbindung" #1: ISAKMP SA established
 
Info:
:Die Aushandlung der Phase1 wurde erfolgreich abgeschlossen.
 
<div align="right">[[#top|<font size=1>zum Anfang</font>]]</div>
 
<br>
<br>
'''Meldung:'''
Bemerkung:
IPSEC Server;"Name der Verbindung" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
* Update von Strongswan 4.6.4 auf 5.3.5
 
* Aus Pluto wird Charon (IKEv1)
Info:
* Geänderte Logmeldungen
:Dieser Log-Eintrag bedeutet, dass der IPSec Dienst die Phase2 initiiert.  
Vorherige Versionen: [[UTM/VPN/IPSec-Troubleshooting_v11.6 | 11.6.12]]


<br>
==IKEv1 Troubleshooting==
'''Meldung:'''
IPSEC Server;"Name der Verbindung" #2: sent QI2, IPsec SA established
{ESP=>0x30b6fe24 <0xc2e2aabb NATOA=0.0.0.0}


Info:
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.
:Die Phase2 der Verbindug wurde erfolgreich aufgebaut. Damit wurde der IPSec Tunnel erfolgreich aufgebaut.  
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.


<br>
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.
'''Meldung:''
[[Image:ipsec_troubleshooting01.png|900px |center]]
IPSEC Server; "Name der Verbindung" #1: ignoring informational payload, type INVALID_ID_INFORMATION


Ursache:
===Phase 1: Der normale Verbindungsaufbau===
:Die Einstellungen unter Phase2 stimmen nicht überein.  
[[Image:ipsec_troubleshooting02.png|900px |center]]
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.
====Logmeldung====
<pre>IKE_SA Standort_1_2[1] established between 198.51.100.75[198.51.100.75]...198.51.100.1[198.51.100.1]</pre>


Lösung:
===Phase 1: Falsches Proposal===
: Die Einstellungen in Phase2 stimmen nicht mit denen der Gegenstelle überein.  
[[Image:ipsec_troubleshooting03.png|900px |center]]
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“.
====Logmeldung Initiator====
<pre>received NO_PROPOSAL_CHOSEN notify error</pre>
====Logmeldungen Responder====
<pre>selecting proposal:</pre>
<pre>no acceptable ENCRYPTION_ALGORITHM found</pre>
<pre>received proposals: IKE:BLOWFISH_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192</pre>
<pre>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</pre>
<pre>received proposals inacceptable</pre>


<br>
===Phase 1: Falsche Remote-Gateway-Adresse===
'''Meldung:'''
[[Image:ipsec_troubleshooting04.png|900px |center]]
"Name der Verbindung"[2] 87.139.55.127:4500 #1: cannot respond to IPsec SA request because no connection
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.
is known for 192.168.70.0/24===92.77.218.89:4500...87.139.55.127:4500[192.168.4.5]===192.168.5.0/24
===Phase 1: Falsche ID Initiator===
[[Image:ipsec_troubleshooting05.png|900px |center]]
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.
====Logmeldung Initiator====
<pre>received AUTHENTICATION_FAILED error notify</pre>
====Logmeldung Responder====
<pre>looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]</pre>
<pre>no peer config found</pre>
===Phase 1: Falsche ID Responder===
[[Image:ipsec_troubleshooting06.png|900px |center]]
Meldet sich der Responder mit einer anderen ID als in der Konfiguration des Initiators, dann wird dies im Log des Initiators entsprechend gemeldet.
====Logmeldung Initiator====
<pre>IDir 'blubb' does not match to '198.51.100.75'</pre>


Ursache:
===Phase 1: Falscher PSK===
:Die Einstellungen, Subnetze betreffend, sind nicht korrekt.
[[Image:ipsec_troubleshooting07.png|900px |center]]
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.
====Logmeldung Initiator====
<pre>message parsing failed</pre>
<pre>ignore malformed INFORMATIONAL request</pre>
<pre>INFORMATIONAL_V1 request with message ID 1054289493 processing failed</pre>
====Logmeldung Responder====
<pre>message parsing failed</pre>
<pre>ID_PROT request with message ID 0 processing failed</pre>
===Phase 1: Falscher RSA-Key Initiator===
[[Image:ipsec_troubleshooting17.png|900px |center]]
Verwendet der Initiator der Verbindung einen anderen RSA-Key wie in der Konfiguration des Responders eingestellt, kann keine Authentifizierung erfolgen. Der Initiator erhält die Fehlermeldung „AUTHENTICATION_FAILED“.
====Logmeldung Initiator====
<pre>authentication of 'Filiale' (myself) succesful</pre>
<pre>received AUTHENTICATION_FAILED error notify</pre>
====Logmeldung Responder====
<pre>looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]</pre>
<pre>candidate "Standort1_4", match: 1/20/28 (me/other/ike)</pre>
<pre>selected peer config "Standort1_4"</pre>
<pre>using trusted certificate "Filiale"</pre>
<pre>signature validation failed, looking for another key</pre>
<pre>no trusted RSA public key found for 'Filiale'</pre>


Lösung:
===Phase 1: Falscher RSA-Key Responder===
: Bitte überprüfen, ob auf beiden FWs die Subnetze übereinstimmen.
[[Image:ipsec_troubleshooting18.png|900px |center]]
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.
====Logmeldung Initiator====
<pre>authentication of 'Filiale' (myself) succesful</pre>
<pre>using trusted certificate "Zentrale"</pre>
<pre>signature validation failed, looking for another key</pre>
<pre>no trusted RSA public key found for 'Zentrale'</pre>
====Logmeldung Responder====
<pre>looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]</pre>
<pre>candidate "Standort1_4", match: 1/20/28 (me/other/ike)</pre>
<pre>selected peer config "Standort1_4"</pre>
<pre>using trusted certificate "Filiale"</pre>
<pre>authentication of 'Filiale' with RSA succesful</pre>
<pre>authentication of 'Zentrale' (myself) succesful</pre>
<pre>IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]</pre>
<pre>scheduling reauthentication in 2593s</pre>
<pre>maximum IKE_SA lifetime 3133s</pre>
<pre>received DELETE for IKE_SA Standort_4[1]</pre>


<div align="right">[[#top|<font size=1>zum Anfang</font>]]</div>
===Phase 2: Der normale Verbindungsaufbau===
[[Image:ipsec_troubleshooting08.png|900px |center]]
Ist auch die Phase 2 korrekt konfiguriert, wird der erfolgreiche Aufbau einer CHILD_SA im Livelog beider Seiten dokumentiert.
====Logmeldung====
<pre>CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and T S 10.1.0.0/24 === 10.0.0.0/24</pre>
===Phase 2: Falsche Subnetzkonfiguration===
[[Image:ipsec_troubleshooting09.png|900px |center]]
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.
====Logmeldung Initiator====
<pre>proposing traffic selectors for us:</pre>
<pre>10.1.0.0/24</pre>
<pre>proposing traffic selectors for other:</pre>
<pre>11.0.0.0/24</pre>
<pre>received INVALID_ID_INFORMATION error notify</pre>
====Logmeldung Responder====
<pre>looking for a child config for 11.0.0.0/24 === 10.1.0.0/24</pre>
<pre>proposing traffic selectors for us:</pre>
<pre>10.0.0.0/24</pre>
<pre>proposing traffic selectors for other:</pre>
<pre>10.1.0.0/24</pre>
<pre>no matching CHILD_SA config found</pre>


'''Meldung:'''
==IKEv2 Troubleshooting==
<pre>
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.
no default route - cannot cope with %defaultroute!!!
[[Image:ipsec_troubleshooting10.png|900px |center]]
</pre>
===IKEv2: Verbindung kommt zustande===
Ursache:
[[Image:ipsec_troubleshooting11.png|900px |center]]
:Die default-Route kann vom IPSec-Dienst nicht bestimmt werden.
Einen erfolgreichen Verbindungsaufbau erkennt man an einer Meldung im Livelog, die die erfolgreiche Etablierung einer CHILD_SA dokumentiert.
: ''Beachten Sie'': Das Bestimmen der default-Route ist im Multipath-Betrieb nicht möglich.
====Logmeldung====
<pre>selected proposal_ ESP_AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ</pre>
<pre>selecting traffic selectors for us:</pre>
<pre>config: 10.1.0.0/24, received: 10.1.0.0/24 => match: 10.1.0.0/24</pre>
<pre>selecting traffic selectors for ther:</pre>
<pre>config: 10.0.0.0/24, received: 10.0.0.0/24 0> match: 10.0.0.0/24</pre>
<pre>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</pre>


Lösung:
===IKEv2: Falsche Remote-Gateway-Adresse===
: Setzen Sie in der Phase1 alle IPSec-Verbindungen
[[Image:ipsec_troubleshooting12.png|900px |center]]
: ''Lokales Gateway'' - auf das externe Interface/externe IP
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“.
: ''Route over'' - tragen Sie die IP Ihres Routers/wählen Sie das pppx-Interface aus
====Logmeldung Responder====
: ''Local Gateway ID'' - setzen Sie auf das externe Interface/externe IP
<pre>looking for an ike config fo 198.51.100.75...198.51.100.1</pre>
<pre>no IKE config for 198.51.100.75...198.51.100.1, sending NO_PROPOSAL_CHOSEN</pre>
===IKEv2: Falsche ID Initiator===
[[Image:ipsec_troubleshooting13.png|900px |center]]
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 im Responder-Log dokumentiert. Der Initiator bekommt die Fehlermeldung AUTHENTICATION_FAILED.
====Logmeldung Initiator====
<pre>received AUTHENTICATION_FAILED error notify</pre>
====Logmeldung Responder====
<pre>looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]</pre>
<pre>no peer config found</pre>
===IKEv2 Falsche ID Responder===
[[Image:ipsec_troubleshooting14.png|900px |center]]
Umgekehrt wird eine andere als die beim Initiator konfigurierte Responder-ID entsprechend im Log des Initiators gemeldet.
====Logmeldung Initiator====
<pre>IDir 'blubb' does not match to '198.51.100.75'</pre>
===IKEv2: Falscher PSK===
[[Image:ipsec_troubleshooting15.png|900px |center]]
Stimmt der PSK nicht überein, meldet der Responder, dass der MAC (Message Authentication Code) nicht übereinstimmt. Der Initiator bekommt die Fehlermeldung „AUTHENTICATION_FAILED“
====Logmeldung Initiator====
<pre>received AUTHENTICATION_FAILED notify error</pre>
====Logmeldung Responder====
<pre>tried 2 shared keys for '198.51.100.75' - '198.51.100.1', but MAC mismatched</pre>
===IKEv2: Falsche Subnetzkonfiguration===
[[Image:ipsec_troubleshooting16.png|900px |center]]
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.
====Logmeldung Initiator====
<pre>received T S_UNACCEPTABLE notify, no CHILD_SA built</pre>
<pre>failed to establish CHILD_SA, keeping IKE_SA</pre>
====Logmeldung Responder====
<pre>looking for a child config for 10.0.0.0/24 === 11.1.0.0/24</pre>
<pre>proposing traffic selectors for us: </pre>
<pre>10.0.0.0/24</pre>
<pre>proposing traffic selectors for other:</pre>
<pre>10.1.0.0/24</pre>
<pre>traffic selectors 10.0.0.0/24 === 11.1.0.0/24 inacceptable</pre>
<pre>failed to establish CHILD_SA, keeping IKE_SA</pre>

Aktuelle Version vom 30. September 2021, 11:36 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


Informationen

Letze Anpassung zur Version: 11.7
Bemerkung:

  • Update von Strongswan 4.6.4 auf 5.3.5
  • Aus Pluto wird Charon (IKEv1)
  • Geänderte Logmeldungen

Vorherige Versionen: 11.6.12

IKEv1 Troubleshooting

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.

Ipsec troubleshooting01.png

Phase 1: Der normale Verbindungsaufbau

Ipsec troubleshooting02.png

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.

Logmeldung

IKE_SA Standort_1_2[1] established between 198.51.100.75[198.51.100.75]...198.51.100.1[198.51.100.1]

Phase 1: Falsches Proposal

Ipsec troubleshooting03.png

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“.

Logmeldung Initiator

received NO_PROPOSAL_CHOSEN notify error

Logmeldungen Responder

selecting proposal:
no acceptable ENCRYPTION_ALGORITHM found
received proposals: IKE:BLOWFISH_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
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
received proposals inacceptable

Phase 1: Falsche Remote-Gateway-Adresse

Ipsec troubleshooting04.png

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.

Phase 1: Falsche ID Initiator

Ipsec troubleshooting05.png

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.

Logmeldung Initiator

received AUTHENTICATION_FAILED error notify

Logmeldung Responder

looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
no peer config found

Phase 1: Falsche ID Responder

Ipsec troubleshooting06.png

Meldet sich der Responder mit einer anderen ID als in der Konfiguration des Initiators, dann wird dies im Log des Initiators entsprechend gemeldet.

Logmeldung Initiator

IDir 'blubb' does not match to '198.51.100.75'

Phase 1: Falscher PSK

Ipsec troubleshooting07.png

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.

Logmeldung Initiator

message parsing failed
ignore malformed INFORMATIONAL request
INFORMATIONAL_V1 request with message ID 1054289493 processing failed

Logmeldung Responder

message parsing failed
ID_PROT request with message ID 0 processing failed

Phase 1: Falscher RSA-Key Initiator

Ipsec troubleshooting17.png

Verwendet der Initiator der Verbindung einen anderen RSA-Key wie in der Konfiguration des Responders eingestellt, kann keine Authentifizierung erfolgen. Der Initiator erhält die Fehlermeldung „AUTHENTICATION_FAILED“.

Logmeldung Initiator

authentication of 'Filiale' (myself) succesful
received AUTHENTICATION_FAILED error notify

Logmeldung Responder

looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
candidate "Standort1_4", match: 1/20/28 (me/other/ike)
selected peer config "Standort1_4"
using trusted certificate "Filiale"
signature validation failed, looking for another key
no trusted RSA public key found for 'Filiale'

Phase 1: Falscher RSA-Key Responder

Ipsec troubleshooting18.png

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.

Logmeldung Initiator

authentication of 'Filiale' (myself) succesful
using trusted certificate "Zentrale"
signature validation failed, looking for another key
no trusted RSA public key found for 'Zentrale'

Logmeldung Responder

looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
candidate "Standort1_4", match: 1/20/28 (me/other/ike)
selected peer config "Standort1_4"
using trusted certificate "Filiale"
authentication of 'Filiale' with RSA succesful
authentication of 'Zentrale' (myself) succesful
IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
scheduling reauthentication in 2593s
maximum IKE_SA lifetime 3133s
received DELETE for IKE_SA Standort_4[1]

Phase 2: Der normale Verbindungsaufbau

Ipsec troubleshooting08.png

Ist auch die Phase 2 korrekt konfiguriert, wird der erfolgreiche Aufbau einer CHILD_SA im Livelog beider Seiten dokumentiert.

Logmeldung

CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and T S 10.1.0.0/24 === 10.0.0.0/24

Phase 2: Falsche Subnetzkonfiguration

Ipsec troubleshooting09.png

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.

Logmeldung Initiator

proposing traffic selectors for us:
10.1.0.0/24
proposing traffic selectors for other:
11.0.0.0/24
received INVALID_ID_INFORMATION error notify

Logmeldung Responder

looking for a child config for 11.0.0.0/24 === 10.1.0.0/24
proposing traffic selectors for us:
10.0.0.0/24
proposing traffic selectors for other:
10.1.0.0/24
no matching CHILD_SA config found

IKEv2 Troubleshooting

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.

Ipsec troubleshooting10.png

IKEv2: Verbindung kommt zustande

Ipsec troubleshooting11.png

Einen erfolgreichen Verbindungsaufbau erkennt man an einer Meldung im Livelog, die die erfolgreiche Etablierung einer CHILD_SA dokumentiert.

Logmeldung

selected proposal_ ESP_AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
selecting traffic selectors for us:
config: 10.1.0.0/24, received: 10.1.0.0/24 => match: 10.1.0.0/24
selecting traffic selectors for ther:
config: 10.0.0.0/24, received: 10.0.0.0/24 0> match: 10.0.0.0/24
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

IKEv2: Falsche Remote-Gateway-Adresse

Ipsec troubleshooting12.png

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“.

Logmeldung Responder

looking for an ike config fo 198.51.100.75...198.51.100.1
no IKE config for 198.51.100.75...198.51.100.1, sending NO_PROPOSAL_CHOSEN

IKEv2: Falsche ID Initiator

Ipsec troubleshooting13.png

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 im Responder-Log dokumentiert. Der Initiator bekommt die Fehlermeldung AUTHENTICATION_FAILED.

Logmeldung Initiator

received AUTHENTICATION_FAILED error notify

Logmeldung Responder

looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
no peer config found

IKEv2 Falsche ID Responder

Ipsec troubleshooting14.png

Umgekehrt wird eine andere als die beim Initiator konfigurierte Responder-ID entsprechend im Log des Initiators gemeldet.

Logmeldung Initiator

IDir 'blubb' does not match to '198.51.100.75'

IKEv2: Falscher PSK

Ipsec troubleshooting15.png

Stimmt der PSK nicht überein, meldet der Responder, dass der MAC (Message Authentication Code) nicht übereinstimmt. Der Initiator bekommt die Fehlermeldung „AUTHENTICATION_FAILED“

Logmeldung Initiator

received AUTHENTICATION_FAILED notify error

Logmeldung Responder

tried 2 shared keys for '198.51.100.75' - '198.51.100.1', but MAC mismatched

IKEv2: Falsche Subnetzkonfiguration

Ipsec troubleshooting16.png

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.

Logmeldung Initiator

received T S_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA

Logmeldung Responder

looking for a child config for 10.0.0.0/24 === 11.1.0.0/24
proposing traffic selectors for us: 
10.0.0.0/24
proposing traffic selectors for other:
10.1.0.0/24
traffic selectors 10.0.0.0/24 === 11.1.0.0/24 inacceptable
failed to establish CHILD_SA, keeping IKE_SA
Abgerufen von „https://wiki.securepoint.de/index.php?title=UTM/VPN/IPSec-Troubleshooting_v11.7&oldid=80365“