Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    FB verliert Kontakt jeden Tag um 12 und um 0Uhr

    Scheduled Pinned Locked Moved Deutsch
    23 Posts 6 Posters 1.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      Klaus2314
      last edited by Klaus2314

      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!

      f584f579-884d-4bb4-aab9-7a9b1327b92e-image.png

      So sieht das jeden Tag aus. Immer exakt um die selbe Zeit. Und dauert immer 53-55 Sekunden an.

      fireodoF 1 Reply Last reply Reply Quote 0
      • fireodoF
        fireodo @Klaus2314
        last edited by fireodo

        @Klaus2314

        Hi,

        installier das Paket "cron" und schau was um diese Uhrzeit abläuft - dann findest auch eventuell den/die Verursacher.

        Grüßle,
        fireodo

        Kettop Mi4300YL CPU: i5-4300Y @ 1.60GHz RAM: 8GB Ethernet Ports: 4
        SSD: SanDisk pSSD-S2 16GB (ZFS) WiFi: WLE200NX
        pfsense 2.8.0 CE
        Packages: Apcupsd, Cron, Iftop, Iperf, LCDproc, Nmap, pfBlockerNG, RRD_Summary, Shellcmd, Snort, Speedtest, System_Patches.

        K 1 Reply Last reply Reply Quote 0
        • RicoR
          Rico LAYER 8 Rebel Alliance
          last edited by

          Was sagt das Log der Fritzbox?
          Welches Fritzbox Modell?
          Wie genau erfolgt die Einwahl?

          -Rico

          K 1 Reply Last reply Reply Quote 0
          • K
            Klaus2314 @fireodo
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • K
              Klaus2314 @Rico
              last edited by

              @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.

              1 Reply Last reply Reply Quote 0
              • JeGrJ
                JeGr LAYER 8 Moderator
                last edited by JeGr

                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

                Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 0
                • K
                  Klaus2314
                  last edited by Klaus2314

                  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.

                  fc0b39ec-eeee-49a1-a167-84b0abe0c73b-image.png

                  fireodoF 1 Reply Last reply Reply Quote 0
                  • fireodoF
                    fireodo @Klaus2314
                    last edited by

                    @Klaus2314

                    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.

                    Kettop Mi4300YL CPU: i5-4300Y @ 1.60GHz RAM: 8GB Ethernet Ports: 4
                    SSD: SanDisk pSSD-S2 16GB (ZFS) WiFi: WLE200NX
                    pfsense 2.8.0 CE
                    Packages: Apcupsd, Cron, Iftop, Iperf, LCDproc, Nmap, pfBlockerNG, RRD_Summary, Shellcmd, Snort, Speedtest, System_Patches.

                    1 Reply Last reply Reply Quote 0
                    • V
                      viragomann
                      last edited by

                      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.

                      K 1 Reply Last reply Reply Quote 0
                      • K
                        Klaus2314
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • K
                          Klaus2314 @viragomann
                          last edited by

                          @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.

                          V 1 Reply Last reply Reply Quote 0
                          • V
                            viragomann @Klaus2314
                            last edited by

                            @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

                            K 1 Reply Last reply Reply Quote 0
                            • K
                              Klaus2314 @viragomann
                              last edited by

                              @viragomann Nein das ist ohne Haken.

                              1 Reply Last reply Reply Quote 0
                              • K
                                Klaus2314
                                last edited by Klaus2314

                                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?
                                726219bd-8052-40dc-93b0-2479a479f39a-image.png

                                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.

                                Bob.DigB 1 Reply Last reply Reply Quote 0
                                • Bob.DigB
                                  Bob.Dig LAYER 8 @Klaus2314
                                  last edited by

                                  @Klaus2314 Vielleicht mal Live Rule Swap on Update probieren. Hab dein Problem nicht, bei mir läuft es aber auch nicht auf WAN.

                                  1 Reply Last reply Reply Quote 0
                                  • V
                                    viragomann
                                    last edited by

                                    Hatte einige Zeit lang auch Suricata laufen und kenne das Problem auch nicht. Allerdings ebenfall am internen Interface.

                                    1 Reply Last reply Reply Quote 0
                                    • K
                                      Klaus2314
                                      last edited by

                                      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?

                                      V 1 Reply Last reply Reply Quote 0
                                      • V
                                        viragomann @Klaus2314
                                        last edited by

                                        @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.

                                        1 Reply Last reply Reply Quote 0
                                        • JeGrJ
                                          JeGr LAYER 8 Moderator
                                          last edited by

                                          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

                                          Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                                          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                                          1 Reply Last reply Reply Quote 0
                                          • K
                                            Klaus2314
                                            last edited by

                                            Seit der Umstellung keine Ausfälle mehr.

                                            Danke!

                                            fireodoF 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.