14
PfSense: nach 27-stündigem Ausfall der Deutschen Telekom streiken IPSec + OpenVPN
Einen Gruß aus der Eifel,
nachdem wir wieder mal von einer großflächigen Störung der Telekom-Anschlüsse (Ausfall eines DSLAM mit mehreren Tausend Teilnehmern) heimgesucht wurden, deren Behebung ursprünglich in 5 Stunden, dann in 19 und anschließend erst nach 27 Stunden behoben wurde, funktionieren an meiner pfSense die bis gestern laufenden OpenVPN (für den VPN aufbau zu meinem VPN-Provider) sowie IPSec-Dienste (zu meinem entfernten Wohnort) nicht mehr.
Ich habe die Firewalls zunächst nicht neugestartet, sondern an an beiden die IPSec und OpenVPN neu gestartet. Es half nicht. Danach habe ich beiden pfSenses neu gestartet, aber der Fehler ist immer noch da.
Habt Ihr eine Idee? Liegt der Fehler evtl. in der Telekom, da diese einen kompletten DSLAM ausgetauscht hat und dieser erst vor einer Stunden gegangen online gegangen ist?
Update 1
Den Fehler im IPSec habe ich gefunden. Der Dynamic DNS-Dienst der pfSense am Hauptort hat die neue IP nicht übertragen. Es stand dort ein rotes Kreuz. Ich mußte den Dienst deaktivieren, aktivieren und erst dann wurde die neue IP übermittelt. Dazu drängt sich die Frage auf, weshalb das Aus- und Einschalten notwendig war, denn sollte ich unterwegs sein, komme ich nicht remote nicht auf meine pfSense, wenn die Telekom wieder mal so ein faules Hühnerei legt, der Anshcluß längere Zeit gestört ist, dann online geht und der DynDNS-Client nicht hochfährt...
Das zweite, noch offene Problem ist das OpenVPN. Hierzu merke ich an, daß an beiden pfSensen exakt die gleiche Einstellung zum exakt gleichen VPN-Provider mit der gleichen IP besteht. Die eine pfSense geht, die andere (am Anschluß der Deutschen Telekom nicht).
Update 2
Den Fehler im OpenVPN habe ich ebenfalls gefunden. Ich habe dazu in pfSense > System > Cert. Manager unter Certificate data das Zertifikat neu installiert (Paste a certificate in X.509 PEM format) und danach ging der Dienst wieder.
An dieser Stelle erinnere ich mich, daß ich exakt das gleiche Problem hatte, als am Standort "zu Hause" der Dienstausgefallen ist (Internet wird über Funkantenne bereitgestellt). Danach ging der OpenVPN wie auch hier und heute nicht. Ich wußte mir damals nicht anders zu helfen, als den ganzen VPN-Client neu aufzusetzen.
Und gerade habe ich das hier entdeckt:
https://forum.netgate.com/topic/97166/solved-vpn-client-failing-to-valid ...
https://redmine.pfsense.org/issues/2800
Wo User ein ähnliches Problem beschreiben. Kann es am Ende ein Problem der pfSense sein?
nachdem wir wieder mal von einer großflächigen Störung der Telekom-Anschlüsse (Ausfall eines DSLAM mit mehreren Tausend Teilnehmern) heimgesucht wurden, deren Behebung ursprünglich in 5 Stunden, dann in 19 und anschließend erst nach 27 Stunden behoben wurde, funktionieren an meiner pfSense die bis gestern laufenden OpenVPN (für den VPN aufbau zu meinem VPN-Provider) sowie IPSec-Dienste (zu meinem entfernten Wohnort) nicht mehr.
Ich habe die Firewalls zunächst nicht neugestartet, sondern an an beiden die IPSec und OpenVPN neu gestartet. Es half nicht. Danach habe ich beiden pfSenses neu gestartet, aber der Fehler ist immer noch da.
Habt Ihr eine Idee? Liegt der Fehler evtl. in der Telekom, da diese einen kompletten DSLAM ausgetauscht hat und dieser erst vor einer Stunden gegangen online gegangen ist?
Update 1
Den Fehler im IPSec habe ich gefunden. Der Dynamic DNS-Dienst der pfSense am Hauptort hat die neue IP nicht übertragen. Es stand dort ein rotes Kreuz. Ich mußte den Dienst deaktivieren, aktivieren und erst dann wurde die neue IP übermittelt. Dazu drängt sich die Frage auf, weshalb das Aus- und Einschalten notwendig war, denn sollte ich unterwegs sein, komme ich nicht remote nicht auf meine pfSense, wenn die Telekom wieder mal so ein faules Hühnerei legt, der Anshcluß längere Zeit gestört ist, dann online geht und der DynDNS-Client nicht hochfährt...
Das zweite, noch offene Problem ist das OpenVPN. Hierzu merke ich an, daß an beiden pfSensen exakt die gleiche Einstellung zum exakt gleichen VPN-Provider mit der gleichen IP besteht. Die eine pfSense geht, die andere (am Anschluß der Deutschen Telekom nicht).
Update 2
Den Fehler im OpenVPN habe ich ebenfalls gefunden. Ich habe dazu in pfSense > System > Cert. Manager unter Certificate data das Zertifikat neu installiert (Paste a certificate in X.509 PEM format) und danach ging der Dienst wieder.
An dieser Stelle erinnere ich mich, daß ich exakt das gleiche Problem hatte, als am Standort "zu Hause" der Dienstausgefallen ist (Internet wird über Funkantenne bereitgestellt). Danach ging der OpenVPN wie auch hier und heute nicht. Ich wußte mir damals nicht anders zu helfen, als den ganzen VPN-Client neu aufzusetzen.
Und gerade habe ich das hier entdeckt:
https://forum.netgate.com/topic/97166/solved-vpn-client-failing-to-valid ...
https://redmine.pfsense.org/issues/2800
Wo User ein ähnliches Problem beschreiben. Kann es am Ende ein Problem der pfSense sein?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1765212409
Url: https://administrator.de/forum/pfsense-nach-27-stuendigem-ausfall-der-deutschen-telekom-streiken-ipsec-openvpn-1765212409.html
Ausgedruckt am: 02.04.2025 um 04:04 Uhr
14 Kommentare
Neuester Kommentar
Moin,
zumindest für den ersten Teil ein Hinweis, wenn du Wert auf Stabilität legst, dann kannst du nicht mit den dyn. DNS oder ähnlichen Services arbeiten. Du brauchst dann eine feste IP.
Kostet Geld aber dafür hast du dann dieses Problem nicht mehr.
Viele Grüße
zumindest für den ersten Teil ein Hinweis, wenn du Wert auf Stabilität legst, dann kannst du nicht mit den dyn. DNS oder ähnlichen Services arbeiten. Du brauchst dann eine feste IP.
Kostet Geld aber dafür hast du dann dieses Problem nicht mehr.
Viele Grüße
1
@sabines
Das ist korrekt. Dennoch, DynDNS ist ein von vielen genutzter Service und es scheint mir hier ein Zusammenhang mit dem längeren Leitungsausfall der Telekom und der pfSense vorzuliegen.
Denn wie geschrieben, nachdem ich im DynDNS der pfSense disable/enable gemacht habe, hat er sofort funktioniert. Nicht jedoch bei dem zuvor gemachten Neustart der pfSense.
Aus administratorischer Sicht ist es mir wert, dies zu vertiefen. Vielleicht ist es ein Bug in der pfSense. Daß es an der Internetverbindung liegt, kann ich mir nicht vorstellen. Aber der Ausfall hat zumindest dazu geführt, daß sich der DynDNS festgefressen hat, was auch nicht durch Neustart behoben werden konnte. Und ich hatte dies bereits 2x an unterscheidlichen Standorten mit unterschiedlichen Internetanbietern und immer nach einem Internetausfall.
Das ist korrekt. Dennoch, DynDNS ist ein von vielen genutzter Service und es scheint mir hier ein Zusammenhang mit dem längeren Leitungsausfall der Telekom und der pfSense vorzuliegen.
Denn wie geschrieben, nachdem ich im DynDNS der pfSense disable/enable gemacht habe, hat er sofort funktioniert. Nicht jedoch bei dem zuvor gemachten Neustart der pfSense.
Aus administratorischer Sicht ist es mir wert, dies zu vertiefen. Vielleicht ist es ein Bug in der pfSense. Daß es an der Internetverbindung liegt, kann ich mir nicht vorstellen. Aber der Ausfall hat zumindest dazu geführt, daß sich der DynDNS festgefressen hat, was auch nicht durch Neustart behoben werden konnte. Und ich hatte dies bereits 2x an unterscheidlichen Standorten mit unterschiedlichen Internetanbietern und immer nach einem Internetausfall.
Auch wenn diese Dienste von vielen genutzt werden, heißt es noch lange nicht, dass sie für jeden Zweck geeignet sind. Wirklich niemand wird so etwas für den professionellen Einsatz planen. Wenn man mit gelegentlichen Neustarts aller Systeme oder auch tiefer greifenden Fehlerbehebungen leben kann, dann passt das natürlich. In allen anderen Fällen kann und wird man sich auf solche Systeme besser nicht verlassen.
Aus Administratorensicht wird man sowas also nicht einsetzen.
Im privaten oder semiprofessionellen Umfeld vielleicht schon.
Aus Administratorensicht wird man sowas also nicht einsetzen.
Im privaten oder semiprofessionellen Umfeld vielleicht schon.
Hi,
wenn ich mich recht erinnere, versucht die pfSense, den Interface-Status zu erkennen, und aktualisiert sonst sehr selten (alle x Tage?). Ersteres funktioniert am WAN-Modem oftmals nicht. Ein eigener Cron-Job mit angemessener Frequenz ist für DynDNS auf der pfSense daher Pflicht.
Das geschilderte OpenVPN-Problem sagt mir nichts. Aber ich meine, das Default-Setting bei Inactivity (Causes OpenVPN to exit after n seconds of inactivity on the TUN/TAP device) ist ungleich 0, was schon mal eine Fehlerquelle ist.
Grüße
Richard
wenn ich mich recht erinnere, versucht die pfSense, den Interface-Status zu erkennen, und aktualisiert sonst sehr selten (alle x Tage?). Ersteres funktioniert am WAN-Modem oftmals nicht. Ein eigener Cron-Job mit angemessener Frequenz ist für DynDNS auf der pfSense daher Pflicht.
Das geschilderte OpenVPN-Problem sagt mir nichts. Aber ich meine, das Default-Setting bei Inactivity (Causes OpenVPN to exit after n seconds of inactivity on the TUN/TAP device) ist ungleich 0, was schon mal eine Fehlerquelle ist.
Grüße
Richard
@c.r.s.
Schreibst Du, daß die als Default eingetragene "0" (OpenVPN > Ping settings > Inactivity) richtig oder falsch ist? Wenn falsch, welchen Wert sollte ich eintragen?
Betreffend DynDNS hast Du Recht. Allerdings erklärt dies nicht, weshalb der Dienst selbst nach Neustart der pfSense die Vergabe der neuen IP nicht erkannt und übermittelt hat. Ich habe als Backup-Lösung einen Linux-Rechner, auf den ich über ein LTE-Modem remote zugreife. Darüber kann ich dann diverse WLAN-Steckdosen steuern, u.a. die der pfSense. Wenn nun selbst nach einem Neustart der DynDNS nicht funktioniert, habe ich ein Problem, das ich nicht erkannt habe. Nämlich, daß ich nicht in mein Firmennetzwerk komme. Ich müßte dann von meinem Linux-Rechner, der "nur" die Steckdosen steuert, eine Verbindung ins Firmennetz schaffen und habe damit einen neue potentielle Gefahrenquelle.
Falls jemand eine Idee hat, wie dies elegant zu lösen wäre, bin ich für Anregungen dankbar. Ich habe noch ein As im Ärmel; mein Nachbar, der bei Bedarf auf die GUI der pfSense gehen könnte, dem ich dann per Handy Anweisungen erteile. Aber auch das hat ein Risiko, daß ein Dritter mein Passwort kennt
Schreibst Du, daß die als Default eingetragene "0" (OpenVPN > Ping settings > Inactivity) richtig oder falsch ist? Wenn falsch, welchen Wert sollte ich eintragen?
Betreffend DynDNS hast Du Recht. Allerdings erklärt dies nicht, weshalb der Dienst selbst nach Neustart der pfSense die Vergabe der neuen IP nicht erkannt und übermittelt hat. Ich habe als Backup-Lösung einen Linux-Rechner, auf den ich über ein LTE-Modem remote zugreife. Darüber kann ich dann diverse WLAN-Steckdosen steuern, u.a. die der pfSense. Wenn nun selbst nach einem Neustart der DynDNS nicht funktioniert, habe ich ein Problem, das ich nicht erkannt habe. Nämlich, daß ich nicht in mein Firmennetzwerk komme. Ich müßte dann von meinem Linux-Rechner, der "nur" die Steckdosen steuert, eine Verbindung ins Firmennetz schaffen und habe damit einen neue potentielle Gefahrenquelle.
Falls jemand eine Idee hat, wie dies elegant zu lösen wäre, bin ich für Anregungen dankbar. Ich habe noch ein As im Ärmel; mein Nachbar, der bei Bedarf auf die GUI der pfSense gehen könnte, dem ich dann per Handy Anweisungen erteile. Aber auch das hat ein Risiko, daß ein Dritter mein Passwort kennt
0 ist richtig, um den Dienst am Leben zu erhalten, auch wenn er nicht kontaktiert wird. Default ist tatsächlich 300, warum auch immer.
DynDNS-Probleme hatte ich vornehmlich nach der Zwangstrennung, deshalb passt da dein Fall da auch nicht ganz. Ohne jetzt in den Code zu schauen, nur anhand der auflaufenden Log-Meldungen (No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry) würde ich sagen, dass auch mit modifiziertem Cron-Job rc.dyndns.update nur den Prüfdienst abfragt und dann davon den Aufruf des DynDNS-Dienstes abhängig macht. Andererseits war mein Fehlerbild immer, dass die alte IP in Rot dargestellt wird, also die pfSense irgendwann schon wusste, dass es die falsche ist, und sie trotzdem nicht aktualisiert hatte.
Seltsam, aber zumindest hatte ich nur mit dem Cron-Job (und einer eigenen Prüfseite für die relativ hochfrequenten Aufrufe) immer Erfolg, sowohl hinter NAT als auch am Modem.
Du könntest per Cron auch direkt ein eigenes Curl-Skript aufrufen, um es noch simpler zu machen.
DynDNS-Probleme hatte ich vornehmlich nach der Zwangstrennung, deshalb passt da dein Fall da auch nicht ganz. Ohne jetzt in den Code zu schauen, nur anhand der auflaufenden Log-Meldungen (No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry) würde ich sagen, dass auch mit modifiziertem Cron-Job rc.dyndns.update nur den Prüfdienst abfragt und dann davon den Aufruf des DynDNS-Dienstes abhängig macht. Andererseits war mein Fehlerbild immer, dass die alte IP in Rot dargestellt wird, also die pfSense irgendwann schon wusste, dass es die falsche ist, und sie trotzdem nicht aktualisiert hatte.
Seltsam, aber zumindest hatte ich nur mit dem Cron-Job (und einer eigenen Prüfseite für die relativ hochfrequenten Aufrufe) immer Erfolg, sowohl hinter NAT als auch am Modem.
Du könntest per Cron auch direkt ein eigenes Curl-Skript aufrufen, um es noch simpler zu machen.
1
@c.r.s.
Das kommt schon meinem Fehlerbild sehr nahe. Und da es an zwei Standorten passierte, ist es kein Zufall.
Hast Du die Möglichkeit, mir die Info zu dem Cronjob hier zu posten? Es ist das erste Mal, das ich einen Job einrichten würde, also Greenhorn diesbezüglich Oder falls es trivial ist, würde ich mich gerne step-by-step einarbeiten und wäre für einen Link, wo es für einen schon einigermaßen in die Jahre gekommenen IT-ler verständlich erklärt ist.
Danke!
Das kommt schon meinem Fehlerbild sehr nahe. Und da es an zwei Standorten passierte, ist es kein Zufall.
Hast Du die Möglichkeit, mir die Info zu dem Cronjob hier zu posten? Es ist das erste Mal, das ich einen Job einrichten würde, also Greenhorn diesbezüglich
Oder falls es trivial ist, würde ich mich gerne step-by-step einarbeiten und wäre für einen Link, wo es für einen schon einigermaßen in die Jahre gekommenen IT-ler verständlich erklärt ist.Danke!
Siehe hier die Konfigurationsdatei: https://forum.netgate.com/topic/99543/stops-routing-all-traffic-for-15mi ...
Wenn Du das Cron-Paket installierst, ist das unter Dienste > Cron einfach editierbar und leicht verständlich beschriftet. Ich setze den Job auf jede Minute (also */1 * * * *), falls nötig.
Das ist schon sehr häufig (mit der standardmäßigen bzw. einer fremden IP-Prüfseite würde ich das nicht machen), aber eine Verbindung mit beidseitig dynamischer IP und gleichzeitiger Zwangstrennung ist damit kaum drei Minuten down.
1
1 1 * * * root /usr/bin/nice -n20 /etc/rc.dyndns.updateWenn Du das Cron-Paket installierst, ist das unter Dienste > Cron einfach editierbar und leicht verständlich beschriftet. Ich setze den Job auf jede Minute (also */1 * * * *), falls nötig.
Das ist schon sehr häufig (mit der standardmäßigen bzw. einer fremden IP-Prüfseite würde ich das nicht machen), aber eine Verbindung mit beidseitig dynamischer IP und gleichzeitiger Zwangstrennung ist damit kaum drei Minuten down.
@c.r.s.
Besten Dank! Ich werde berichten, sobald ich es installiert habe.
Update:
Ich habe eben unter Services > Cron gesehen, daß der Dienst bereits eingestellt und aktiv war. Es war auf 1x Stunde gesetzt und ich habe es auf 1x Minute geändert. Ist das so in Ordnung?
Besten Dank! Ich werde berichten, sobald ich es installiert habe.
Update:
Ich habe eben unter Services > Cron gesehen, daß der Dienst bereits eingestellt und aktiv war. Es war auf 1x Stunde gesetzt und ich habe es auf 1x Minute geändert. Ist das so in Ordnung?
Noch eine Frage zum Schluß:
Ist es möglich, daß der auf 1x Stunde eingestellte Cron-Job für den DynDNS auch nach einem Neustart erst 1 Stunden nach dem letzten Job startet? Was ich damit meine, daß das Internet 27 Stunden ausgefallen war. Angenommen, der letzte Job startete um 19:00 Uhr. Um 19:30 kehrte das Internet zurück, aber der DynDNS hatte noch die alte IP (die vor dem Ausfall war). Um 19:45 habe ich die pfSense neu gestartet und dennoch hat der DynDNS upgedatet. Das würde bedeuten, daß die pfSense beim Neustart den DynDNS nicht zwingend startet, sondern wartet erst, bis das die eingestellte Zeit abläuft. Wenn dem nicht so ist, bedeutet es, daß es ein Bug ist und dann würde ich das pfSense-Forum fragen.
Ist es möglich, daß der auf 1x Stunde eingestellte Cron-Job für den DynDNS auch nach einem Neustart erst 1 Stunden nach dem letzten Job startet? Was ich damit meine, daß das Internet 27 Stunden ausgefallen war. Angenommen, der letzte Job startete um 19:00 Uhr. Um 19:30 kehrte das Internet zurück, aber der DynDNS hatte noch die alte IP (die vor dem Ausfall war). Um 19:45 habe ich die pfSense neu gestartet und dennoch hat der DynDNS upgedatet. Das würde bedeuten, daß die pfSense beim Neustart den DynDNS nicht zwingend startet, sondern wartet erst, bis das die eingestellte Zeit abläuft. Wenn dem nicht so ist, bedeutet es, daß es ein Bug ist und dann würde ich das pfSense-Forum fragen.
Die Frage kannst du dir doch selbst beantworten ! Der Cronjob richtet sich doch nur nach der Uhr. Wann und wie oft du rebootest oder Stromausfall war oder was auch immer ist ihm dabei egal.
Wenn um 22:30 Uhr der Cronjob lief um 22:35 der Reload war dann startet der nächste Cronjob ganz normal um 23:30 Uhr. Einfachste Logik....
Wenn du auch willst das das DynDNS Skript nach einm Neustart ausgeführt wird musst du das im Startup auch angeben.
Wenn um 22:30 Uhr der Cronjob lief um 22:35 der Reload war dann startet der nächste Cronjob ganz normal um 23:30 Uhr. Einfachste Logik....
Wenn du auch willst das das DynDNS Skript nach einm Neustart ausgeführt wird musst du das im Startup auch angeben.
@aqui
Aaah. Aaaaaah!!! Wie Recht Du hast. Ist ja völlig logisch)) Die Uhr, die wird ja beim Neustart nicht zurückgesetzt ))
Weißt Du die stelle, wo man die Jobs bei einem Neustart auch neu startet oder gibt es dafür im Fenster Command einen extra Befehl?
Danke und schönes Wochenende (bin mal wieder nach langer Zeit bei meiner Family...).
Aaah. Aaaaaah!!! Wie Recht Du hast. Ist ja völlig logisch
)) Die Uhr, die wird ja beim Neustart nicht zurückgesetzt ))Weißt Du die stelle, wo man die Jobs bei einem Neustart auch neu startet oder gibt es dafür im Fenster Command einen extra Befehl?
Danke und schönes Wochenende (bin mal wieder nach langer Zeit bei meiner Family...).
Its all on the web !
https://docs.netgate.com/pfsense/en/latest/development/boot-commands.htm ...
Und Finger weg von der IT wenn Familytime angesagt ist !!!
https://docs.netgate.com/pfsense/en/latest/development/boot-commands.htm ...
Und Finger weg von der IT wenn Familytime angesagt ist !!!
1
