VPN - IPsec instabil

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
diego-amando
Beiträge: 2
Registriert: Mi 02.11.2022, 15:18

VPN - IPsec instabil

Beitrag von diego-amando »

Hallo Community,

seit ca. 6-8 Wochen haben wir massive Probleme mit instabilen IPsec (ikev1 und ikev2) Verbindungen. In unserer Zentrale nutzen wir eine RC400, welche wiederum ca. 230 VPN Verbindungen zu unsere Filialen (BlackDwarf G2, G3, G5) eingerichtet hat. Zusätzlich laufen gleichzeitig über den Tag noch ca. 20 Roadwarrior Verbindungen. Bis vor ca. 6-8 Wochen lief alles stabil, mal hier oder da 2 abgerochene Tunnel in der Woche. Aber seit einiger Zeit haben wir massive Probleme und ständige Abbrüche der Verbindungen. Status der Verbindung ist lt. UTM "up", obwohl die Verbindung tatsächlich "down" ist - Ping schlägt fehl.

Ich konnte bisher noch kein Muster über diese fehlerhaften Verbindungen ausfindig machen. Bei so vielen Filialen haben wir auch unterschiedliche Firewall Versionen. v11.8.16.1, v11.8.17, v12.2.5.1. 
95% IKEv1, 3% IKEv2, 2% aber auch per SSL-S2S Verbindungen. 
Unsere Zentrale UTM lief bisher auf v11.8.16.1, seit kurzen aber hochgestuft auf v12.2.5.1. Doch egal in welcher Kombination, die VPN Verbindungen sind einfach nicht stabil und müssen teilweise bis zu 4mal am Tag neu aufgebaut werden. Einzig stabil läuft SSL-S2S oder eine UTM fresh out-of-the-box in v12.2.5.1 konfiguriert. Dann aber auch in selber Konfig, wie es auch bisher in der IKEv1 läuft. "Out-of-the-box" > stabil. Laufende UTM in v11.8.x macht Probleme, nach Update auf v12.2.5.1 aber auch keine Besserung. Wir nutzen die IKEv1 Verbindungen seit Jahren ohne Probleme. Doch plötzlich vergeht kein Tag mehr an dem nicht die Verbindungen neu initiiert werden müssen. 
Mitunter ist es auch so, dass es einen CPU-Overload in den Filialen gibt. Hier ist es teilweise so, dass fast alle 10 Sekunden eine "CHILD_SA" initiiert wird. Das kann doch nicht normal sein?

Unsere Konfig:

Zentrale: Startverhalten "incomming", ike_lifetime 1h rekeying "3" (aber auch "unbegrenzt" mit Problemen), local_gateway %any, Authentifizierung mit PSK (falls v12 & IKEv2 dann no_mobike multi_traffic_selector)
Filiale: Startverhalten "outgoing", ike_lifetime 1h, rekeying "3" (aber auch "unbegrenzt" mit Problemen), Neustart nach Abbruchm local_gateway %any, Authentifizierung mit PSK, (falls v12 & IKEv2 dann no_mobike multi_traffic_selector)

Wir nutzten auch in der Zentrale bereits "outgoing" als Startverhalten, aber auch da gab es die Probleme. 

Ich hab keine Idee mehr woran es liegen könnte. Die letzten Lösungen wären die UTMs neu aufzusetzen oder alle Standorte per SSL-S2S VPN einzubinden. Aber diesen enormen Aufwand möchte ich gern als letzten Ausweg auf mich nehmen. 

Wir arbeiten mit sehr vielen Pflegeheimen und Pflegediensten zusammen, die per RDP auf Terminalserver unserer Zentrale zugreifen. Die ständigen Unterbrechungen, die trotz Einstellung nicht automatisch starten sind für diese Einrichtungen natürlich der Super-GAU.

Ich konnte schon eine Einstellungen mit dem Support bei einzelnen Verbindungen anpassen, aber leider gab es auch da bisher nicht die Lösung, die die VPN wieder stabil arbeiten lässt.

Vllt. habt ihr eine Idee oder einen Ansatz oder gar selbst den ein oder anderen gleichen Fehler, der behoben werden konnte.

Ich bin für jeden Lösungsansatz oder Idee dankbar.

VG
-Diego

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Ich habe exakt die gleichen Problem. Die Workarounds, die vom Support angeboten werden, sind nicht das, was man sich wünschen würde. Das seltsame ist, dass diese Störungen auch zwischen Securepoint UTM auftreten, also keine Drittherstellerprodukte. Besonders ärgerlich ist das in größeren Umgebungen (RC300, RC400).

Gruß

Franz

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Bitte ein Ticket bei uns im Support aufmachen. Wir haben bereits ein paar Loesungsansaetze.
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

diego-amando
Beiträge: 2
Registriert: Mi 02.11.2022, 15:18

Beitrag von diego-amando »

Ich habe mich auf Mario's Bitte hin ans Support-Team gewannt und eine Rückmeldung erhalten, evtl. hilft sie auch anderen.

Wenn ich es korrekt verstanden habe liegt die Problematik in der UTM im Sprung von v11.8.x auf v12.x. Im Bereich IPsec gab es Anpassungen in der Verarbeitung des VPN-Protokolls, die dazu führen können, dass die UTM zuviele SA Anfragen stellt und dadurch die CPU voll läuft. Als möglichen Lösungsansatz wurde mir die Umstellung auf ikev2 genannt. Dies kann per CLI durchgeführt werden.

cli > ipsec set id x(id der IPsec Verbindung) ike_version ikev2

Anschließend wäre es wichtig die ike_lifetime sowie ike_rekeying(nicht per Web-GUI möglich) anzupassen. Dies wiederum per zusätzlichen CLI Befehlen

cli > ipsec set id x ike_lifetime 3 ike_rekeying 2
cli > ipsec set id x ike_lifetime 0

Dies muss natürlich auf beiden UTM Seiten erfolgen, sofern auf beiden Seiten UTM's im Einsatz sind. Die Einstellung für "ike_rekeying" gibt es nach meiner Prüfung aber erst ab v12.x.
In einem zukünftigen Update soll diese Einstellung dann "default" sein.

Ob es mir die Lösung bringt werde ich nun testen und nochmal berichten.

VG
-Diego

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Das Problem mit der hohen CPU-Auslastung tritt nach meinem Eindruck nur oder vorzugsweise bei IKEv2 auf. Bei IKEv1 habe ich das noch nicht beobachtet. Beobachtet habe ich das Problem beim Initiator (Outgoing), aber villeicht war der Responder (Incoming) so leistungsstark, dass ikm der amoklaufende Initiator nichts anhaben konnte. :)
Die von dir genannte Änderung teste ich seit ca. 2 Wochen.

Die Sache mit der hohen CPU-Last ist jedoch nicht das ganze Problem. Schlimmer sind die Tunnel, die als aufgebaut behandelt werden, aber dennoch keinen Netzwerkverkehr übermitteln. Das Problem tritt m. E. besonder oft auf, wenn es zu Störungen auf der WAN-Seite gekommen war (Firmwareupdate im DSLAM etc.).

Igendwie bekommt die UTM nicht mit, wenn die Verbindung tot ist, außer die Gegendtellte teilt das explizit mit, wie z. B. bei einem Geräteeustart. Dann kann es jedoch passieren, dass die Outgoing-Seite nicht mehr versucht, den Tunnel neu aufzubauen, denn die Incoming-Seite hatte sich ja korrekt verabschiedet. In der Praxis heißt das, die Zentrale (Incoming)wird neu gestartet, anschließend bauen die Filialen die Verbindung ab und verbleiben in dem Zustand, bis man sie manuell zum Tunnelaufbau auffordert oder neu startet. Auch dafür gibt es einen "Workaraund" aber schön ist der auch nicht unbedingt.

Man merkt sicher, ich bin inzwischen von der IPSec-Implementierung bei Securepoint etwas angenervt. Momentan arbeiten die Drittherstellerprodukte in den Filialen stabiler als die Securepoint Geräte mit der UTM in der Zentrale zusamen. Das ist traurig und ärgerlich.

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Zusaetzlich zu den oben genannten Einstellungen kann es helfen, beide Seiten auf "Route" zu stellen. Neustart nach Abbruch aus. Dies klappt aber nur, wenn sich beide Seiten auch direkt erreichen koennen.

Sobald Beide Seiten auf Route gestellt sind muss ein weiteres Flag fuer den IPSEC-Tunnel hinzugefuegt werden: "MULTI_TRAFFIC_SELECTOR GENERATE_TRAFFIC"

Vorher die Konfiguration herunter laden und sichern!

Es muessen alle notwendigen Flags auf einmal gesetzt werden. Also unbedingt vor dem Setzen des Flag schauen, welche Flags bereits gesetzt wurden und diese dann mitgeben.

Beispiel: ipsec set id "1" flags [ ROUTE DPD MULTI_TRAFFIC_SELECTOR GENERATE_TRAFFIC ]
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Mario hat geschrieben: Zusaetzlich zu den oben genannten Einstellungen kann es helfen, beide Seiten auf "Route" zu stellen. Neustart nach Abbruch aus. Dies klappt aber nur, wenn sich beide Seiten auch direkt erreichen koennen.
Danke für den Hinweis, das hönnte in den Fällen helfen, wo die Tunnel nach einem Neustart nicht hochkommen! Warum muss "Neustart nach Abbruch" deaktiviert werden?

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Weil es sich sonst hoch schaukeln kann mit den SAs. Ist auch nicht notwendig, da bei "Route" der Tunnel automatisch aufgebaut wird, wenn Traffic durch gesendet werden soll. Was mit dem Flag "Generate_Traffic" dann auch passiert
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

zierhut-networks
Beiträge: 7
Registriert: Di 29.11.2016, 21:41

Beitrag von zierhut-networks »

diego-amando hat geschrieben: Ich habe mich auf Mario's Bitte hin ans Support-Team gewannt und eine Rückmeldung erhalten, evtl. hilft sie auch anderen.

cli > ipsec set id x(id der IPsec Verbindung) ike_version ikev2

Anschließend wäre es wichtig die ike_lifetime sowie ike_rekeying(nicht per Web-GUI möglich) anzupassen. Dies wiederum per zusätzlichen CLI Befehlen

cli > ipsec set id x ike_lifetime 3 ike_rekeying 2
cli > ipsec set id x ike_lifetime 0
Hier ist doch ein Fehler, oder?
Das müsste in der ersten Zeile "ike_rekeytime" heißen und der zweite Aufruf setzt die Lifetime dann wieder auf 0 (statt davor auf 3)?

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

ipsec set id x ike_lifetime=3
ipsec set id x ike_rekeytime=2
ipsec set id x ike_lifetime=0

Das ist, was ich dazu gefunden habe.
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Gibt es inzwischen was Neues in der Sache?
Heute musste ich wieder bei zwei Filialen die IPSec-Dienste neu starten, weil der Traffic nur in einer Richtung durchging.
Nach Neustart des IPSec-Dientes in der Filiale funktionierten die Tunnel wieder.

Es kann doch nicht sein, dass man zwischen Securepoint-Geräten keine stabilen IPSec-Verbindungen hinbekommt?

Für einen Kunden habe ich sogar schon einen Zweizeiler in C# geschrieben, der auf Knopfdruck den IPSec-Dienst der UTM neu startet, damit der Kunde sich selbst helfen kann, wenn der Fehler außerhalb unserer Supportzeiten auftritt. Ich wollte vermeiden, dem gesamten Personal ein Admin-Login für die UTM einrichten zu müssen.

Der Vorschlag vom Support, auf SSL-VPN auszuweichen, ist m. E. auch nur eine Krücke, weil OpenVPN m. W. immer noch nur einen CPU-Kern nutzt.
Damit wäre so etwas nur für die alten Black Dwarf bis G3 interessant, denn die haben nur einen Core.

Fallback von IPSec auf SSL-VPN funktioniert leider auch nicht, weil die priorisierte IPSec-Verbindung als aufgebaut behandelt wird, obwohl gar kein Traffic über sie möglich ist. Solange die IPSec-Verbindung von der UTM als aufgebaut betrachtet wird, greift Fallback nicht

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Die von mir genannten Einstellungen sind das, was wir zukuenftig als Best Practice/ Standardeinstellungen kommunizieren werden.

Das Wichtigste ist dabei "Route", moeglichst auf beiden Seiten und das Setzen des Flag "GENERATE_TRAFFIC" fuer den entsprechenden Tunnel.

Optimal waere es, wenn sich beide Seiten erreichen koennen.


Was OpenVPN angeht: Die Performance bei den kleinen G5 Geraeten macht es egal, was fuer eine Art VPN Sie nutzen. Die Performance ist in etwa gleich. Ab dem Black Dwarf G5 Pro zumindest. (Der Black Dwarf G5 hat noch eine etwas aeltere CPU) Unterschiede gibt es maximal beim Bidirektionalen Datenverkehr, da ist IPSEC gleichmaeßiger in beide Richtungen verteilt waehrend bei OpenVPN eine der beiden Seiten "Dominiert". Die erreichten Datenraten waren jedoch trotzdem mindestens auf dem Niveau von IPSEC, teilweise sogar besser als bei IPSEC.

Wenn man mehr logische CPUs nutzen moechte, kann man auch mehrere OpenVPN Server erstellen. So kann die CPU Leistung aufgeteilt werden.
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Dann funktionieren diese Best Practice/ Standardeinstellungen leider nicht.
Die Geräte haben öffentliche IPv4 auf den WAN-Interfaces und die Einstellung (habe es gerade nochmal kontrolliert) wie oben angegeben.
Das hatte ich aber auch schon vor Wochen mit dem Support geprüft...

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Dann noch mal das Ticket aufmachen. Die Frage ist nun halt, ist das ein regulaerer Disconnect, oder ist es ein Fehler.
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Leider handelt es sich um Produktivsysteme, weswegen ich bei einem Ausfall keine Zeit für ausführliche Tests habe. Oft melden sich die Kunden morgens um 7 oder 8 Uhr, wenn der Securepoint Support noch nicht erreichbar ist.

Aber ich meine im Fehlerfall gesehen zu haben, dass beispielsweise der Ping von der Zentrale zur Filiale beantwortet wird, aber in umgekehrter Richtung nicht.
Außerdem habe ich beobachtet, dass in Phase 2  zwei SAs mit nahezu identischem Ablaufdatum aufgebaut werden, obwohl eigentlich nur eine SA in Phase 2 nötig wäre. Jede der beiden SAs zeigt dann lediglich Traffic in einer Richtung (die Tunnel funktionieren in dem Zustand noch).

Warum greift beispielsweise der DPD-Mechanismus eigentlich nicht, wenn aus welchem Grund auch immer kein Traffic mehr über den Tunnel möglich ist (und sei es auch nur, dass nur eine Richtung tot ist)?

Ich kann das Ticket nochmal eröffnen. Einer Ihrer Kollege hatte auch schon angeboten, dass wir den Tunnel testweise von Policy- auf Route-Based-VPN umstellen könnten. Zwar würde es mich aus technischer Sicht sehr interessieren, sowas zunächst in einer Testumgebung auszuprobieren, aber momentan fehlt mir einfach die Zeit, um das dann auch ausgiebig testen zu können – leider betreue ich nicht nur Firewalls. Wobei ich fürchte, dass das nichts an der Problematik ändern wird, dass anscheinend tote Verbindungen nicht detektiert oder nicht so behandelt werden, dass am Ende funktionsfähige Tunnel erhalten bleiben.


Gruß und schönen Abend

Franz

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Heute Morgen hatte ich bei einem Kunden wieder den Fall, dass der Tunnel in einer Richtung tot war.
Hier hatte ich kurz Zeit, mir die SAs anzuschauen: Der Tunnel war in der Filiale mit der falschen ausgehenden IP aufgebaut worden. An dem Standort sind 3 Internetzugänge für unterschiedliche Zwecke eingerichtet. Einer von ihnen soll exklusiv für IPSec verwendet werden. In Phase 1 war als "Local Gateway" die zugehörige IP eingetragen. Ich habe dort jetzt das entsprechende WAN-Interface statt der festen IP eingetragen und werde weiter beobachten, ob es erneut dazu kommt, dass der Tunnel die falsche ausgehende IP verwendet. Die fasche ausgehende IP wäre jedenfalls eine mögliche Erklärung dafür, warum Traffic nur in einer Richtung durch geht (falsche Zone...).

Wie kann ich zuverlässig verhindern, dass der Tunnel über das falsche Interface (den falschen Internetzugang) aufgebaut wird, so dass der IPSec-Tunnel in dem Fall als abgebaut behandelt wird und ein Fallback auf SSL-VPN stattfinden könnte?

Gruß

Franz

Benutzeravatar
Mario
Securepoint
Beiträge: 935
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Das geht ueber eine entsprechende Route.
Mit freundlichen Grüßen

Mario Rhein
Support
Tel. 04131/2401-0
Fax 04131/2401-50

Securepoint GmbH
Blecker Landstr. 28
D-21337 Lüneburg
https://www.securepoint.de

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Das allgemeine Routing wollte ich nicht gerne umstellen, aber ich hab jetzt für die übrigen WAN-Zugänge ebenfalls IPSec-Zonen und Firewallregeln eingerichtet. Bisher funktioniert es.

Schade ist nur, dass man sich den Weg für Fallback auf SSL-VPN verstellt, wenn man das Startverhalten bei IPSec in Phase1 auf "Route" stellt.

Franz
Beiträge: 387
Registriert: Sa 02.04.2011, 17:52
Wohnort: Westerwald
Kontaktdaten:

Beitrag von Franz »

Kurze Rückmeldung: Seitdem ich in Phase 1 als "Local Gateway" statt der öffentlichen IP das zugehörige WAN-Interface eingetragen habe, ist es bei den betroffenen VPN bisher nicht mehr dazu gekommen, dass die SA für die falsche IP erzeugt oder über das falsche Interface aufgebaut wurde.

Die von Mario empfohlenen Anpassungen (ike_lifetime, ike_rekeytime, Startverhalte ROUTE und GENARATE_TRAFFIC) hatte ich bereits durchgeführt.

Antworten