FB verliert Kontakt jeden Tag um 12 und um 0Uhr
-
Hallo,
mir ist in meinem gateway log aufgefallen, dass jeden Tag auf die Sekunde um 12:09 und um 00:09Uhr der pinger den Kontakt zur Fritzbox (Versatel Glasfaser) für 1 Minute verliert und alle angeschlossenen Maschinen incl. VPN-Verbindungen rausgeschmissen werden. Ist das ein "feature" der FB oder liegt's an pfsense? Oder liegt's am provider?
Danke!
So sieht das jeden Tag aus. Immer exakt um die selbe Zeit. Und dauert immer 53-55 Sekunden an.
-
Hi,
installier das Paket "cron" und schau was um diese Uhrzeit abläuft - dann findest auch eventuell den/die Verursacher.
Grüßle,
fireodo -
Was sagt das Log der Fritzbox?
Welches Fritzbox Modell?
Wie genau erfolgt die Einwahl?-Rico
-
@fireodo Danke für den Tip. Zur vollen Stunde aktualisiert sich pfblocker, was aber nicht den dropout immer um 12 und 0Uhr erklärt. Ich guck mir mal cron an. Hab pfblocker mal auf viertel nach geändert.
-
@Rico
Eine 5490 an einer fibre. Im log ist kein Abbruch verzeichnet. Muss also was auf der pfsense-seite sein, schätze ich. Danke für den Tip wie man es eingrenzt. -
Hallo Klaus,
das ist aber kein Kontaktverlust. Wäre das Gateway weg, würde da sowas stehen:
Nov 13 14:01:27 dpinger 18276 WAN4_Test2 9.9.9.10: Clear latency 26782us stddev 7329us loss 8% Nov 13 14:00:12 dpinger 18276 WAN4_Test2 9.9.9.10: Alarm latency 24810us stddev 5745us loss 41%Das ist mein dummes Fritzbox bedingtes Gateway Flapping alle paar Minten. Da geht der Loss auf bis zu 80-90% hoch und fällt dann wieder ab. Einfach so. Alle 2-3min. Keine Ahnung warum - ich hab bei AVM aufgegeben nachzufragen.
Dein Eintrag ist eigentlich ein "Neustart" von dpinger, da wird dann die komplette Kommandozeile ausgegeben. Wenn da also alle 12h der dpinger neugestartet wird, muss entweder ein Interface Event gelaufen sein, dass das WAN neu initialisiert hat (könnte sein, wenn wirklich die FB vornedran neustartet und damit "das Kabel" zur pfSense weg war). Was genau das dann aber ist - schwierig.
Du könntest mal das "Cron" Package installieren und dann in der Cron Table schauen, ob da bei dir was um 9 nach voller Stunde läuft. Das einzige was ich auf krummen Uhrzeiten habe ist x:01 diverse interne Jobs und 03:16 der Acme Job. Ansonsten läuft eigentlich alles zu geraden Uhrzeiten.
Ansonsten wäre natürlich interessant was im normalen Syslog um 00:09 (oder kurz davor und danach) steht - oder um 12:09 - um zu sehen, ob da irgendwas ausgelöst wurde.
@Klaus2314 said in FB verliert Kontakt jeden Tag um 12 und um 0Uhr:
Eine 5490 an einer fibre. Im log ist kein Abbruch verzeichnet. Muss also was auf der pfsense-seite sein, schätze ich. Danke für den Tip wie man es eingrenzt.Aaah... das muss aber nicht sein. Leider sind die aktuellen/neuere Fritzboxen kein wahnsinniges Feuerwerk der Ingenieurskunst mehr ;) Könnte also durchaus sein, dass die da ab und an mal ihren Link verliert. Aber wenn in ihrem eigenen Syslog nichts zu finden ist, liegt der Verdacht natürlich nahe, dass es was anderes auf pfSense Seite ist, was die Log Einträge erzeugt, aber was/wer der Grund ist, ist da noch unklar.
cheers
\jens -
OK, also das einzige was ich hier sehe ist das Surricata update was um 8 nach läuft. Das komische ist, dass ich das im moment nur im analysemodus fahren also komplett ohne blocking. Oder führt das update dazu dass alle Verbindungen für 1 Minute gekappt werden?
Ich habe irgendwann umgestellt von ping auf die FB ein ping auf 1.1.1.1 um checken ob wirklich der Verbindung nach Außen gekappt wird. Seit dem ist es immer zu den festen Zeiten. Davor als dpinger noch auf die FB ging, gab es ständig Unterbrechungen (Internet nicht erreichbar) und zu vollkommen zufälligen Zeiten.
-
Snort schaltet beim Updaten die Schnittstelle vom promiscous modus off und wieder on - das sollte ohne Unterbrechung erfolgen - ich weiß nicht ob das bei Suricata genauso/ähnlich ist.
-
Findet sich in System-Log der pfSense nichts? Interface-Aktivitäten/-Ausfälle werden da eingetragen.
@Klaus2314 said in FB verliert Kontakt jeden Tag um 12 und um 0Uhr:
Ich habe irgendwann umgestellt von ping auf die FB ein ping auf 1.1.1.1 u
Dann kann das Problem auch außerhalb deines Machtbereichs liegen. Vielleicht mal einen anderen Server nehmen.
-
Um nicht zu viele Sachen gleichzeitig zu ändern, hab ich jetzt erst mal Suricata update auf 21 nach gestellt. Mal sehen ob der Fehler "mitwandert". Ich versuch das mal step-by-step einzukreisen, sonst weiss ich am Ende nicht, was es genau war.
Danke Euch erstmal.Klaus.
-
@viragomann Ich hatte den ping ja vorher default-mäßig auf der FB . Da gab es komischerweise ständig gateway error 64 (oder 65, weiss nicht mehr) und random abbrüche. Die Fehler gingen weg seit ich 1.1.1.1 anpinge (also kein gateway error mehr aber eben die aussetzer). Können aber unabhängige Probleme sein glaube ich.
-
@Klaus2314
Du schreibst oben, dass die Verbindungen weg sind, wenn das Problem auftritt. Hast du etwa hier den Haken gesetzt:
System > Advanced > Miscellaneous > State Killing on Gateway Failure -
@viragomann Nein das ist ohne Haken.
-
OK, also es scheint eindeutig an Suricata zu liegen. Ich hatte den updater auf 21 nach gestellt und der verbindingsverlust war jetzt exakt um 00:22. Vorher update auf 00:08 und Abbruch um 00:09.
Eigenartig. Was tun? Schätze mal update auf "unchristliche Zeit" setzen und auf alle 24 statt 12 Stunden stellen?
Oder ich ändere eine dieser Settings?
Ich habe Suricata mal auf 1 mal am Tag um 3:21 gesetzt. Zumindest schmeisst es dann Tagsüber nicht immer alle VPN clients raus.
-
@Klaus2314 Vielleicht mal Live Rule Swap on Update probieren. Hab dein Problem nicht, bei mir läuft es aber auch nicht auf WAN.
-
Hatte einige Zeit lang auch Suricata laufen und kenne das Problem auch nicht. Allerdings ebenfall am internen Interface.
-
OK, Ich beobachte es mal ein paar Tage. Das Ding ist: Suricata läuft im Moment ausschließlich noch im Analysemodus also Blocking ist komplett aus und seine updates muss es ja über das WAN laden, egal ob nun da läuft oder nicht. Oder sehe ich das falsch?
-
@Klaus2314 said in FB verliert Kontakt jeden Tag um 12 und um 0Uhr:
also Blocking ist komplett aus und seine updates muss es ja über das WAN laden
Die Updates zu laden wird wohl auch nicht die Ursache des Problems sein. Aber unabhängig, ob das Blocking deaktiviert ist, müssen die neuen Regeln anschließend am konfigurierten Interface angewandt werden, du möchtest ja die Logs sehen. Dazu wird vermutlich Suricata neu gestartet, und das wahrscheinlich im Promiscuous Mode. Vielleicht hilft es auch diesen zu deaktivieren.
Als ich mich seinerzeit mit Suricata beschäftigt habe, wurde der Betrieb am WAN gar nicht empfohlen, ist vermutlich noch immer nicht anders. Deswegen habe ich es am DMZ Interface betrieben.
-
Richtig, IDS generell arbeiten ja VOR dem Filter bzw. im Kernel vor / mit dem Netzwerktreiber, damit sie das Paket abfangen können, bevor es am Interface "wirklich ankommt" (und an den Paketfilter wandern würde).
Dann ist es bei einem Neuladen und Reinit des Interfaces wegen Promisc Mode durchaus denkbar, dass es dann da ein kurzes Ruckeln am Interface gibt. Das muss überhaupt kein GW down sein - wie oben beschrieben sehe ich da eh keinen, sondern eher ein "reinit/neuladen" und durchstarten des Interfaces und der Dienste. Das führt dann eben zu kurzem Verbindungsabriß wenn VPN und Co neu durchgestartet werden.cheers
-
Seit der Umstellung keine Ausfälle mehr.
Danke!
