Kurz gesagt: Baut sich ein IPsec-Tunnel zwischen deiner Securepoint UTM und der Gegenstelle nicht auf, erhöhst du zuerst das Log-Level und liest dann die Logs beider Seiten. Die Meldungen zeigen, ob Verschlüsselungsparameter, Gateway-Adresse, ID, Pre-Shared Key oder Subnetze nicht zusammenpassen. Achtung: Das Ändern des Log-Levels startet den IPsec-Dienst neu und unterbricht alle IPsec-Verbindungen kurz.
Stand: 04.11.2026
Wie erhöhst du das Log-Level für IPsec?
Ohne ausführliches Log ist die Fehlersuche beim IPsec-VPN kaum möglich. Securepoint nennt das erhöhte Log-Level deshalb als Voraussetzung. Die Wiki-Seite ist zuletzt zur Version 12.6.0 (01.2024) angepasst worden.
- Öffne im Admin-Interface der UTM das Menü VPN > IPSec.
- Klicke im Bereich Log auf die Schaltfläche IPSec Log.
- Stelle das Log-Level von Rudimentär (empfohlen), dem Standard, auf Ausführlich. Diese Stufe ist laut Securepoint für ein ausführliches Troubleshooting geeignet.
- Klicke auf Speichern und neu starten. Der IPsec-Dienst startet neu, alle IPsec-Verbindungen werden einmal kurz unterbrochen.
Die Stufe Sehr Ausführlich erzeugt so viele Meldungen, dass das Log schnell sein Limit erreicht und wichtige Meldungen anderer Dienste untergehen. Securepoint empfiehlt, sie nicht oder nur kurz zu verwenden. Unter Benutzerdefiniert lassen sich alle Werte in den erweiterten Einstellungen in fünf Stufen protokollieren.
Ab Version 12.2 geht es auch per SSH als root, ohne den Dienst neu zu starten: spcli extc value set application ipsec variable DBG_LVL_IKE value 2, danach spcli appmgmt config und swanctl –reload-settings. Stelle das Log-Level nach der Fehlersuche wieder zurück.
Du kommst nicht weiter? Wir übernehmen das für dich, meist per Fernwartung. Ruf an: 0541 507 988 08, schreib uns oder buch ein Erstgespräch.
Wo findest du die aussagekräftigen Meldungen?
Die Meldungen erscheinen im Livelog der UTM mit dem Dienst IPSec. Securepoint unterscheidet dabei zwischen Initiator, also der Seite, die den Tunnel aufbaut, und Responder. In mehreren Fehlerfällen bekommt der Initiator nur eine allgemeine Meldung, während der Responder den eigentlichen Grund protokolliert. Lies deshalb immer beide Logs.
Beim älteren IKEv1 läuft der Aufbau in zwei Phasen: In Phase 1 authentifizieren sich die Gateways gegenseitig, in Phase 2 entsteht der Tunnel. Securepoint NextGen UTM nutzt dabei ausschließlich den Main Mode, der neben dem Pre-Shared Key (PSK) eine ID verlangt. Bei IKEv2 ist der Aufbau laut Securepoint stark vereinfacht und weniger störanfällig.
Welche Fehlermeldung bedeutet was?
Ist Phase 1 erfolgreich, meldet das Livelog beider Seiten eine Zeile mit IKE_SA … established between …. Fehlt sie, hilft diese Übersicht aus dem Wiki:
| Ursache | Meldung beim Initiator | Meldung beim Responder |
|---|---|---|
| Verschlüsselungsparameter (Proposal) passen nicht | received NO_PROPOSAL_CHOSEN notify error | no acceptable ENCRYPTION_ALGORITHM found, received proposals inacceptable |
| Falsche Remote-Gateway-Adresse | NO_PROPOSAL_CHOSEN | no IKE config found for …, sending NO_PROPOSAL_CHOSEN |
| Falsche ID des Initiators | received AUTHENTICATION_FAILED error notify | no peer config found |
| Falsche ID des Responders | IDir ‚…‘ does not match to ‚…‘ | im Wiki keine eigene Meldung genannt |
| Falscher PSK bei IKEv1 | message parsing failed, ignore malformed INFORMATIONAL request | message parsing failed, ID_PROT request with message ID 0 processing failed |
| Falscher PSK bei IKEv2 | received AUTHENTICATION_FAILED notify error | tried … shared keys for …, but MAC mismatched |
| Falscher RSA-Schlüssel des Initiators | AUTHENTICATION_FAILED | no trusted RSA public key found for ‚…‘ |
Zwei Stolperstellen: NO_PROPOSAL_CHOSEN beim Initiator kann sowohl ein falsches Proposal als auch eine falsche Gateway-Adresse bedeuten. Erst das Responder-Log zeigt, was zutrifft. Und ein falscher PSK zeigt sich bei IKEv1 nicht als klare Meldung, sondern nur indirekt über „deformierte“ Pakete (malformed, message parsing failed).
Phase 1 steht, aber kein Tunnel: Subnetze prüfen
Steht die IKE_SA, aber es entsteht keine CHILD_SA, prüfst du die Subnetze, im Wiki Traffic-Selektoren genannt. Stimmen sie bei Initiator und Responder nicht überein, kann laut Securepoint kein Tunnel aufgesetzt werden. Ein korrekter Tunnel zeigt in beiden Logs CHILD_SA … established mit den beiden Netzen.
- IKEv1: Der Initiator meldet received INVALID_ID_INFORMATION error notify, der Responder no matching CHILD_SA config found.
- IKEv2: Der Initiator meldet received TS_UNACCEPTABLE notify, no CHILD_SA built und failed to establish CHILD_SA, keeping IKE_SA, der Responder traffic selectors … inacceptable.
Prüfe dann, ob das lokale Netz der einen Seite exakt dem entfernten Netz der anderen Seite entspricht, einschließlich Subnetzmaske.
In welcher Reihenfolge gehst du vor?
- Log-Level auf beiden Seiten erhöhen, wenn möglich außerhalb der Arbeitszeit.
- Den Verbindungsaufbau neu anstoßen und Initiator- und Responder-Log nebeneinanderlegen.
- Fehlt IKE_SA … established: Proposal, Gateway-Adresse, IDs und Schlüssel anhand der Tabelle prüfen.
- Fehlt CHILD_SA … established: Subnetze auf beiden Seiten abgleichen.
- Log-Level wieder auf Rudimentär zurückstellen.
So unterstützen wir dich
Wir verbinden Standorte per IPsec und kümmern uns um die Securepoint-Firewalls unserer Kunden in Osnabrück und Umgebung, weiter entfernt per Fernwartung. Als Securepoint Partner lesen wir die Logs beider Seiten, auch wenn die Gegenstelle von einem anderen Anbieter betreut wird. Mehr dazu auf unserer Seite zur Firewall-Betreuung in Osnabrück.
Häufige Fragen
Warum brechen alle Tunnel ab, wenn ich das Log-Level ändere?
Beim Speichern startet der IPsec-Dienst neu. Dabei werden alle IPsec-Verbindungen einmal kurz unterbrochen. Die SSH-Variante ab Version 12.2 kommt ohne Neustart aus.
Was bedeutet NO_PROPOSAL_CHOSEN?
Die Gegenstelle konnte deinen Verbindungsversuch nicht annehmen. Ursache ist laut Wiki entweder ein unpassendes Proposal oder eine falsche Remote-Gateway-Adresse.
Was bedeutet AUTHENTICATION_FAILED?
Die Authentifizierung ist gescheitert. Typische Ursachen laut Wiki sind eine falsche ID, ein falscher PSK bei IKEv2 oder ein falscher RSA-Schlüssel.
Nutzt Securepoint den Aggressive Mode?
Nein. Securepoint NextGen UTM setzt bei IKEv1 ausschließlich den Main Mode ein, weil der Aggressive Mode den PSK nur über einen einfachen Hash absichert.
Quellen
- IPSec Troubleshooting (Securepoint Wiki, Stand zur Version 12.6.0, abgerufen am 04.11.2026)
