5
Seltsames Problem mit pfSense OpenVPN
Hallo zusammen,
ich wende mich an euch, da ich mit meinem Latein am Ende bin und keinen weiteren "Pack an" mehr habe.
Wir setzen seit vielen Jahren die pfSense ein. Nie Probleme damit gehabt. Vor einigen Jahren haben wir unsere Außenstandorte (Kitas, Büros in anderen Stadtteilen, etc.) mit pfSensen ausgestattet und sie alle per OpenVPN zu uns inden Hauptstandort verbunden, dass sie gemeinsame Ressourcen, die hier gehostet werden, verwenden können. Insgesamt reden wir hier von 68 VPN-Verbindungen, die problemlos funktionieren.
Seit einigen Monaten beobachten wir kurze Aussetzer bei den VPN-Verbindungen. Ein Dauerping auf verschiedene Standorte zeigt ein zeitgleiches kurzes Stocken (ca. 5 Sek.) und dann geht es weiter. Innerhalb der 5 Sek. werden in den Außenstandorten Telefonverbindungen, RDP-Verbindungen, usw. unterbrochen. Ein Kollege fand heraus, dass die FWs in den Außenstandorten quasi "stehen". Nichts pingbar, keine Verbindungen aufbaubar, nichts. Wie eingefroren. Bei der FW im Hauptstandort ist indes nichts zu spüren.
Durch Zufall haben wir herausgefunden, dass das Problem immer am 01. eines jeden Monats passiert. Am 01.08. war es das gleiche Spiel. Am 02. gab es keine Probleme mehr. Heute ist wieder der 01. und wir haben aktuell wieder den Spaß. Weiter fanden wir raus, dass die Störung alle 50 Sek. für ca. 5 Sekunden eintritt. Kappen wir die Verbindung und lassen sie neu aufbauen, dann ist die nächsten 15 Minuten Ruhe. Danach geht der Spaß wieder los und 50-Sek-Takt. Das alles ist genau so reproduzierbar. Aber eben nur immer am 01. des Monats.
Wir haben eine IPSec-Verbindung zu einem Partnerunterhmehmen. Damit gibt es keine Probleme. Alles läuft super. Wir haben auch gerade ca. 7 OpenVPN-Verbindungen für HomeOffice Benutzer für RDP-Sitzungen offen. Auch dort keine Probleme. Nur die Site-2-Site-Verbindungen sind betroffen.
Alle pfSensen sind quasi Standard. Da ist nichts gefrickelt, sondern "out of the box" und grundlegende Einstellungen, dann FW-Regeln für die Schnittstellen angelegt, OpenVPN-Verbindungen angelegt und fertig. Keine Specials wo man denken könnte, dass man sich irgendwann etwas verbastelt haben könnte.
So, jetzt kann es los gehen. Ideen? Anregungen?
Bitte keine Vorschläge wie "setz doch X, Y, Z ein statt OpenVPN". Das ist gerade nicht sonderlich hilfreich. Wir können nicht "mal eben" fast 70 Standorte umstellen.
Grüße und Danke im Voraus.
ich wende mich an euch, da ich mit meinem Latein am Ende bin und keinen weiteren "Pack an" mehr habe.
Wir setzen seit vielen Jahren die pfSense ein. Nie Probleme damit gehabt. Vor einigen Jahren haben wir unsere Außenstandorte (Kitas, Büros in anderen Stadtteilen, etc.) mit pfSensen ausgestattet und sie alle per OpenVPN zu uns inden Hauptstandort verbunden, dass sie gemeinsame Ressourcen, die hier gehostet werden, verwenden können. Insgesamt reden wir hier von 68 VPN-Verbindungen, die problemlos funktionieren.
Seit einigen Monaten beobachten wir kurze Aussetzer bei den VPN-Verbindungen. Ein Dauerping auf verschiedene Standorte zeigt ein zeitgleiches kurzes Stocken (ca. 5 Sek.) und dann geht es weiter. Innerhalb der 5 Sek. werden in den Außenstandorten Telefonverbindungen, RDP-Verbindungen, usw. unterbrochen. Ein Kollege fand heraus, dass die FWs in den Außenstandorten quasi "stehen". Nichts pingbar, keine Verbindungen aufbaubar, nichts. Wie eingefroren. Bei der FW im Hauptstandort ist indes nichts zu spüren.
Durch Zufall haben wir herausgefunden, dass das Problem immer am 01. eines jeden Monats passiert. Am 01.08. war es das gleiche Spiel. Am 02. gab es keine Probleme mehr. Heute ist wieder der 01. und wir haben aktuell wieder den Spaß. Weiter fanden wir raus, dass die Störung alle 50 Sek. für ca. 5 Sekunden eintritt. Kappen wir die Verbindung und lassen sie neu aufbauen, dann ist die nächsten 15 Minuten Ruhe. Danach geht der Spaß wieder los und 50-Sek-Takt. Das alles ist genau so reproduzierbar. Aber eben nur immer am 01. des Monats.
Wir haben eine IPSec-Verbindung zu einem Partnerunterhmehmen. Damit gibt es keine Probleme. Alles läuft super. Wir haben auch gerade ca. 7 OpenVPN-Verbindungen für HomeOffice Benutzer für RDP-Sitzungen offen. Auch dort keine Probleme. Nur die Site-2-Site-Verbindungen sind betroffen.
Alle pfSensen sind quasi Standard. Da ist nichts gefrickelt, sondern "out of the box" und grundlegende Einstellungen, dann FW-Regeln für die Schnittstellen angelegt, OpenVPN-Verbindungen angelegt und fertig. Keine Specials wo man denken könnte, dass man sich irgendwann etwas verbastelt haben könnte.
So, jetzt kann es los gehen. Ideen? Anregungen?
Bitte keine Vorschläge wie "setz doch X, Y, Z ein statt OpenVPN". Das ist gerade nicht sonderlich hilfreich. Wir können nicht "mal eben" fast 70 Standorte umstellen.
Grüße und Danke im Voraus.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 53599384778
Url: https://administrator.de/contentid/53599384778
Ausgedruckt am: 21.11.2024 um 16:11 Uhr
5 Kommentare
Neuester Kommentar
Das bekanntlich schwache und sehr schlecht skalierende OpenVPN für so ein Setup mit der Anzahl von Peers zu verwenden ist schon ein Fehler an sich. Mit TCP Enkapsulierung ist das noch deutlich schlimmer. Zu der welche du benutzt und den MTU/MSS Settings machst du ja leider keinerlei hilfreiche Angaben. 
Ein Bild dazu sagt mehr als 1000 Worte:
Diese Auswirkungen spürst du jetzt. (Das ist lesenswert zu der Thematik)
Das hättest du deutlich skalierbarer und besser mit einem durchgängigen IPsec Design lösen können. Allein auch schon um diesen eigentlich völlig unnötigen Wildwuchs mit 2 ganz unterschiedlichen VPN Protokollen und Verfahren zu vermeiden. Warum ist das nicht passiert?
Dann auch noch völlig unnötigerweise remote RDP Nutzer ebenfalls mit OpenVPN und Frickelei mit externer Client Software zu wählen spricht nicht gerade für ein strategisches Denken und Vorgehen bei der VPN Planung.
Mit der IKEv2 Option der pfSense oder auch ihrer L2TP Option die auf IPsec basieren wäre das deutlich einfacher, skalierbarer und zudem auch sicherer mit allen so oder so überall vorhandenen Onboard VPN Clients umsetzbar gewesen.
Mit anderen Worten, auch wenn du diese nicht hören willst: Du solltest dir dringenst Gedanken um eine sinnvolle Restrukturierung deines VPN Setups machen und nur noch ein durchgängiges und vor allem skalierbares VPN Protokoll verwenden statt das was du da jetzt hast.
Du/ihr habt aber schon einen groben Kardinalsfehler bei einer skalierenden VPN Planung gemacht und aufs völlig falsche Pferd gesetzt. Die remote User Planung spricht ja ebenfalls Bände. Was erwartest du also sollte man da dann noch hinfrickeln können?
Mit einem Kaltblutpferd macht man bekanntlich keine Pferderennen. Das klappt auch nicht wenn man ihm täglich Kraftfutter reinstopft.
Ein Bild dazu sagt mehr als 1000 Worte:
Das hättest du deutlich skalierbarer und besser mit einem durchgängigen IPsec Design lösen können. Allein auch schon um diesen eigentlich völlig unnötigen Wildwuchs mit 2 ganz unterschiedlichen VPN Protokollen und Verfahren zu vermeiden. Warum ist das nicht passiert?
Dann auch noch völlig unnötigerweise remote RDP Nutzer ebenfalls mit OpenVPN und Frickelei mit externer Client Software zu wählen spricht nicht gerade für ein strategisches Denken und Vorgehen bei der VPN Planung.
Mit der IKEv2 Option der pfSense oder auch ihrer L2TP Option die auf IPsec basieren wäre das deutlich einfacher, skalierbarer und zudem auch sicherer mit allen so oder so überall vorhandenen Onboard VPN Clients umsetzbar gewesen.
Mit anderen Worten, auch wenn du diese nicht hören willst: Du solltest dir dringenst Gedanken um eine sinnvolle Restrukturierung deines VPN Setups machen und nur noch ein durchgängiges und vor allem skalierbares VPN Protokoll verwenden statt das was du da jetzt hast.
Wir können nicht "mal eben" fast 70 Standorte umstellen.
Das verlangt ja auch keiner und jeder Netzadmin weiss das das auch immer sukzessive Standort für Standort ganz langsam und ohne Aufwand während des Betriebes zu realisieren ist, ohne diesen zu stören.Du/ihr habt aber schon einen groben Kardinalsfehler bei einer skalierenden VPN Planung gemacht und aufs völlig falsche Pferd gesetzt. Die remote User Planung spricht ja ebenfalls Bände. Was erwartest du also sollte man da dann noch hinfrickeln können?
Mit einem Kaltblutpferd macht man bekanntlich keine Pferderennen. Das klappt auch nicht wenn man ihm täglich Kraftfutter reinstopft.
Moin,
ihr könntet natürlich das System wechseln und IPsec ist auch schneller.
Aber ich würde erstmal schauen was da genau in die Knie geht. Sind FWs an den Standorten dann gänzlich weg? Also auch local nicht erreichbar? Vielleicht Hast du ein monitoring und kannst aus dem Standort heraus das GW pingen.
Habt ihr denn keep-alive korrekt für jeden Tunnel konfiguriert? Sonst ist das Verhalten ja einleuchtend.
Gruß
Spirit
ihr könntet natürlich das System wechseln und IPsec ist auch schneller.
Aber ich würde erstmal schauen was da genau in die Knie geht. Sind FWs an den Standorten dann gänzlich weg? Also auch local nicht erreichbar? Vielleicht Hast du ein monitoring und kannst aus dem Standort heraus das GW pingen.
Habt ihr denn keep-alive korrekt für jeden Tunnel konfiguriert? Sonst ist das Verhalten ja einleuchtend.
Gruß
Spirit
Mal ganz ehrlich, dass erste was ich gemacht hätte:
Testhalber mal 5 Standorte mit Wireguard S2S eingebunden um zu sehen, ob es da auch auftritt. Einfach mal aus der Box aussteigen 😉
Testhalber mal 5 Standorte mit Wireguard S2S eingebunden um zu sehen, ob es da auch auftritt. Einfach mal aus der Box aussteigen 😉
Wireshark Trace am 1. des Monats mitschreiben lassen, das Debug-Level der Dienste auf der Sense und den betroffenen Außenstellen hoch schrauben und die Daten analysieren...
Bekommt euer Haus-Hamster der den Strom für die pfSense liefert am Monatsersten vielleicht kein Futter?
.
Dann Plan für eine VPN-Migration erarbeiten und nach und nach die Außenstellen schrittweise Nachts auf eine der o.g. besseren Alternativen umstellen, bei einer homogenen pfSense Umgebung ja kein Hexenwerk.
Gruß sid.
Bekommt euer Haus-Hamster der den Strom für die pfSense liefert am Monatsersten vielleicht kein Futter?
.Dann Plan für eine VPN-Migration erarbeiten und nach und nach die Außenstellen schrittweise Nachts auf eine der o.g. besseren Alternativen umstellen, bei einer homogenen pfSense Umgebung ja kein Hexenwerk.
Gruß sid.
1
Hallo und danke für die Antworten.
Die Ursache wurde gefunden und es ist ein echtes Ding. ^^
Die pfSensen der Außenstandorte sind virtualisiert und laufen auf einem KVM-Host. Der Kollege dachte sich, dass es eine gute Idee ist, dass an jedem 1. ein Snapshot erzeugt wird. Wäre auch, wenn da nicht ein Fehler dabei gewesen wäre. Er hat mittels Cronjob die nötige Virsh-Zeile ausgeführt und dabei diese Zeile so begonnen: * * 1 * *
Jetzt ist auch klar wieso:
- das Problem an jedem 1. des Monats auftrat,
- ungefähr 5 Sekunden dauerte,
- Im Intervall von ungefähr 50 Sekunden auftrat und
- die pfSensen "einfroren".
Ich habe ihm jetzt eine Tasse bestellt:
https://www.fototassen.de/out/pictures/generated/product/1/540_340_75/99 ...
Die Ursache wurde gefunden und es ist ein echtes Ding. ^^
Die pfSensen der Außenstandorte sind virtualisiert und laufen auf einem KVM-Host. Der Kollege dachte sich, dass es eine gute Idee ist, dass an jedem 1. ein Snapshot erzeugt wird. Wäre auch, wenn da nicht ein Fehler dabei gewesen wäre. Er hat mittels Cronjob die nötige Virsh-Zeile ausgeführt und dabei diese Zeile so begonnen: * * 1 * *
Jetzt ist auch klar wieso:
- das Problem an jedem 1. des Monats auftrat,
- ungefähr 5 Sekunden dauerte,
- Im Intervall von ungefähr 50 Sekunden auftrat und
- die pfSensen "einfroren".
Ich habe ihm jetzt eine Tasse bestellt:
https://www.fototassen.de/out/pictures/generated/product/1/540_340_75/99 ...
1
