Wechseln zu:Navigation, Suche
Wiki

IPSec Troubleshooting

Aus Securepoint Wiki

Weiterleitung nach:

Preview1260





































































De.png
En.png
Fr.png








IPSec Troubleshooting
Letzte Anpassung zur Version: 12.6.0
Neu:
  • Aktualisierung zum Redesign des Webinterfaces
  • Das Log-Level lässt sich direkt im Admininterface einstellen
notempty
Dieser Artikel bezieht sich auf eine Resellerpreview

12.2.3 12.2 11.7 11.6.12

Aufruf: UTM-IP:Port oder UTM-URL:Port
Port wie unter Netzwerk / Servereinstellungen / Webserver konfiguriert
Default-Port: 11115
z.B.: https://utm.ttt-point.de:11115
Default: https://192.168.175.1:11115 VPN IPSec  Bereich Log Schaltfläche
IPSec Log


Vorbereitung - Log-Level erhöhen

Log

Als Voraussetzung für das erfolgreiche Troubleshooting muss das Log-Level zunächst erhöht werden.

notempty
Beim Ändern des Loglevels wird der IPSec-Dienst neu gestartet. Dabei werden alle IPSec-Verbindungen einmal unterbrochen.
Log-Level: Rudimentär (empfohlen) Default IPSec UTMbenutzer@firewall.name.fqdnVPN IPSec Log Speichern und neustarten UTM v12.6 IPSec Log.png
Log
Abschnitt Log mit
Allgemein
 und ausgeklappten
[–] Erweiterten Einstellungen
Ausführlich Geeignet für ein ausführliches Troubleshooting
Sehr Ausführlich Kann für spezielle Fehlersuchen erforderlich sein
  • Diese Einstellung erzeugt übermäßig viele Meldungen, so dass das Log binnen kürzester Zeit sein Limit erreichen wird und in Folge dessen Meldungen schneller gelöscht werden müssen. Wichtige Meldungen (anderer Dienste) können dadurch übersehen werden. Es wird empfohlen, diese Einstellung nicht oder nur für kurze Zeit zu verwenden.
    • Benutzerdefiniert Alle Werte lassen sich im Abschnitt
    [–] Erweiterte Einstellungen
     in 5 unterschiedlichen Stufen protokollieren
    Speichern der geänderten Einstellungen mit
    Speichern und neu starten
  • Damit wird der IPSec-Dienst neu gestartet und alle IPSec-Verbindungen einmal kurz unterbrochen.
    • Alternative Möglichkeit, das Log-Level zu ändern:

    CLI-Befehl

    Extras CLI extc value set application "ipsec" variable "DBG_LVL_IKE" value [ "2" ]
  • Anschließend muss der IPSec-Dienst neu gestartet werden. Das unterbricht sämtliche IPSec-Verbindungen!

    appmgmt restart application ipsec

    • Alternative Möglichkeit, das Log-Level zu ändern:

    extc-Variable setzen

    In den Erweiterten Einstellungen:
    Einblendbar über Strg + Alt + A

    Extras Erweiterte Einstellungen  Bereich extc-Variablen Suche nach Variable DBG_LVL_IKE und Wert ändern auf »2
  • Anschließend muss der IPSec-Dienst neu gestartet werden. Das unterbricht sämtliche IPSec-Verbindungen!

    Menü Anwendungen Anwendungsstatus Anwendung IPSec Schaltfläche

    • Alternative Möglichkeit, das Log-Level zu ändern:

    SSH

    per SSH zur Laufzeit als root
  • Hierbei muss der IPSec-Dienst nicht neu gestartet werden.
    • * (nur bis Version 12.1.8):
    ipsec stroke loglevel ike 2
    Mit diesem Befehl ist die Einstellung nach einem Neustart wieder auf ihrem Ursprungswert!

    * (ab Version 12.2):
    spcli extc value set application ipsec variable DBG_LVL_IKE value 2
    spcli appmgmt config
    swanctl --reload-settings



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

    		Ipsec troubleshooting01.png

    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 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 10[IKE] received NO_PROPOSAL_CHOSEN notify error
    Responder-Log
    Dienst Nachricht
    IPSec 05[CFG] selecting proposal:
    IPSec 05[CFG] no acceptable ENCRYPTION_ALGORITHM found
    IPSec 05[CFG] selecting proposal:
    IPSec 05[CFG] received proposals: IKE: BLOWFISH_CBC_256 / HMAC_SHA2_512_256 / PRF_HMAC_SHA2_512 / MODP_8192
    IPSec 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 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 11[CFG] looking for an ike config for 198.51.100.75...195.51.100.1
    IPSec 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 09[IKE] received AUTHENTICATION_FAILED error notify
    Responder-Log
    Dienst Nachricht
    IPSec 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
    IPSec 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 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 15[IKE] message parsing failed
    IPSec 15[IKE] ignore malformed INFORMATIONAL request
    IPSec 15[IKE] INFORMATIONAL_V1 request with message ID 1054289493 processing failed
    Responder-Log
    Dienst Nachricht
    IPSec 14[IKE] message parsing failed
    IPSec 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 15[IKE] authentication of 'Filiale' (myself) succesful
    IPSec 16[IKE] received AUTHENTICATION_FAILED error notify
    Responder-Log
    Dienst Nachricht
    IPSec 14[CFG] looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
    IPSec 14[CFG] candidate "Standort1_4", match: 1/20/28 (me/other/ike)
    IPSec 14[CFG] selected peer config "Standort1_4"
    IPSec 14[CFG] using trusted certificate "Filiale"
    IPSec 14[IKE] ignature validation failed, looking for another key
    IPSec 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 16[CFG] authentication of 'Filiale' (myself) succesful
    IPSec 16[IKE] using trusted certificate "Zentrale"
    IPSec 16[IKE] signature validation failed, looking for another key
    IPSec 15[IKE] no trusted RSA public key found for 'Zentrale'
    Responder-Log
    Dienst Nachricht
    IPSec 10[CFG] looking for RSA signature peer configs matching 198.51.100.75...198.51.100.1[Filiale]
    IPSec 10[CFG] candidate "Standort1_4", match: 1/20/28 (me/other/ike)
    IPSec 10[CFG] selected peer config "Standort1_4"
    IPSec 10[CFG] using trusted certificate "Filiale"
    IPSec 10[IKE] authentication of 'Filiale' with RSA succesful
    IPSec 10[IKE] authentication of 'Zentrale' (myself) succesful
    IPSec 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
    IPSec 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]...198.51.100.1[Filiale]
    IPSec 10[IKE] scheduling reauthentication in 2593s
    IPSec 10[IKE] maximum IKE_SA lifetime 3133s
    IPSec 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 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 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 13[CFH] proposing traffic selectors for us:
    IPSec 13[CFG] 10.1.0.0/24
    IPSec 13[CFG] proposing traffic selectors for other:
    IPSec 13[CFG] 11.0.0.0/24
    IPSec 05[IKE] received INVALID_ID_INFORMATION error notify
    Responder-Log
    Dienst Nachricht
    IPSec 11[CFG] looking for a child config for 11.0.0.0/24 === 10.1.0.0/24
    IPSec 11[CFG] proposing traffic selectors for us:
    IPSec 11[CFG] 10.0.0.0/24
    IPSec 11[CFG] proposing traffic selectors for other:
    IPSec 11[CFG] 10.1.0.0/24
    IPSec 11[IKE] 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 Verbindungsaufbau

    Verbindungsaufbau

    Verbindung kommt zustande
    Initiator-Log & Responder-Log
    Dienst Nachricht
    IPSec 11[CFG] selected proposal_ ESP_AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
    IPSec 11[CFG] selecting traffic selectors for us:
    IPSec 11[CFG] config: 10.1.0.0/24, received: 10.1.0.0/24 => match: 10.1.0.0/24
    IPSec 11[CFG] selecting traffic selectors for ther:
    IPSec 11[CFG] config: 10.0.0.0/24, received: 10.0.0.0/24 0 => match: 10.0.0.0/24
    IPSec 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 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 11[CFG] looking for an ike config fo 198.51.100.75...198.51.100.1
    IPSec 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 09[IKE] received AUTHENTICATION_FAILED error notify
    Responder-Log
    Dienst Nachricht
    IPSec 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75...198.51.100.1[blubb]
    IPSec 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 05[IKE] IDir 'blubb' does not match to '198.51.100.75'
    Falscher PSK
    Initiator-Log
    Dienst Nachricht
    IPSec 13[IKE] received AUTHENTICATION_FAILED notify error
    Responder-Log
    Dienst Nachricht
    IPSec 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 10[IKE] received T S_UNACCEPTABLE notify, no CHILD_SA built
    IPSec 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
    Responder-Log
    Dienst Nachricht
    IPSec 05[CFG] looking for a child config for 10.0.0.0/24 === 11.1.0.0/24
    IPSec 05[CFG] proposing traffic selectors for us:
    IPSec 05[CFG] 10.0.0.0/24
    IPSec 05[CFG] proposing traffic selectors for other:
    IPSec 05[CFG] 10.1.0.0/24
    IPSec 10[IKE] traffic selectors 10.0.0.0/24 === 11.1.0.0/24 inacceptable
    IPSec 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
    Abgerufen von „https://wiki.securepoint.de/index.php?title=UTM/VPN/IPSec-Troubleshooting&oldid=88304“