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

    GELÖST: Master sendet keine XML RPC sync Daten an die Backup Firewall

    Scheduled Pinned Locked Moved Deutsch
    6 Posts 3 Posters 1.3k 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.
    • M
      michlschmid
      last edited by

      Hallo,

      ich habe seit dem Wechsel auf Version 2.3.1 das Problem, dass sich mein Cluster nicht mehr mittes XML RPC auf den Backupnode synchronisiert.
      Dazu habe ich einen Beitrag unter:

      • https://forum.pfsense.org/index.php?topic=113276.0
        auf Englisch geschrieben und einen Bug eröffnet, unter:
      • https://redmine.pfsense.org/issues/6478

      Das Problem ist dass ich in den Logs keinen Fehler gezeigt bekomme und dass der Master lt. TCPDump keinen XML Traffic auf den Backup schickt.
      PFSync funktioniert aber einwandfrei.

      Die IP Adressen der Ziele (Backup) sind ebenfalls jeweils die gleichen.

      Bin eher mehr als weniger ratlos wie ich bei der Fehlerbehebung weitermachen soll…

      Danke für jeden Tipp!

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

        Die IP Adressen der Ziele (Backup) sind ebenfalls jeweils die gleichen.

        Der XMLRPC Abgleich läuft über den Admin Account. Hat der sich geändert (Passwort)? Ansonsten nochmal in den HA Einstellungen explizit eintragen und testen, ob im Log der XMLRPC Sync zu sehen ist.

        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
        • M
          michlschmid
          last edited by

          Hallo JeGr,

          danke für deine Antwort!

          • habe die Userdaten schon mehrmals (neu-)eingegeben auf beiden Geräten. -> Keine Änderung
          • Ports sind auf beiden FWs die gleichen (:443).
          • Habe auch probiert absichtlich einen falschen User bzw. Passwort einzugeben:
            -> Kein Fehler im Log oder in der GUI
            -> Kein Traffic vom Master
          1 Reply Last reply Reply Quote 0
          • V
            viragomann
            last edited by

            Hast du bereits beide pfSense Boxen upgegradet?

            Du verwendest demnach für den Sync ein eigenes Interface, das du "PFSync" nennst.
            Überprüfe die Interface-Einstellungen, IP und Maske und dass beide IPs tatsächlich in das angegebene Netz fallen und die Maske auf beiden Hosts gleich ist.

            1 Reply Last reply Reply Quote 0
            • M
              michlschmid
              last edited by

              Hallo viragomann,

              Danke für Deine Hilfe!

              • ja, bei FWs sind auf dem selben Release 2.3.1p1. -> OK
              • Interface settings, IP, Subnet passt. Habe auch die Sektionen im Config Dump / Backup geprüft, nicht dass es irgendwo nicht übernommen wird. -> OK

              Ich habe den Bug jedoch gefunden:
              Zum übermitteln meiner Suricata Logs verwende ich einen nightliy build von Elastic's FileBeat für FreeBSD.
              Dieser wird mittels "shellcmd" automatisch gestartet.
              Siehe dazu auch: https://blog.reboost.net/suricata-on-pfsense-to-elk-stack/

              Sobald dieser beim Booten gestartet wird funktioniert der Sync NICHT.
              Wird der Prozess gekillt geht der Sync wieder.
              Startet man den Prozess mittels SSH unter dem Benutzer Account / root funktioniert es ohne Probleme.

              Warum sich beide in die Quere kommen weiß ich (noch) nicht, da ein anderes Interface, andere IPs und ein anderer Port (:5044) verwendet wird.

              Hat jemand eine Idee wie man das weiter debuggen kann? Evtl. blockiert der FileBeat Dateien, welche der Sync Process braucht?

              Aktuell sucht er nach den Logdateien in:
              /var/log/suricata/*/eve.json
              um alle Suricata Instanzen zu überwachen.

              1 Reply Last reply Reply Quote 0
              • M
                michlschmid
                last edited by

                Nach folgendem Feedback von CMB aus dem Bugtracker:

                what you did prevented the system from completing bootup, and while the system is booting, it doesn't (and shouldn't) config sync.

                habe ich versucht mein Setup Bootfest zu bekommen.

                Dabei habe ich festgestellt, dass der Start nur mittels einem kleinen "Hilfs-Skript" möglich ist, welches den FileBeat als Prozess in den Hintergrund verschiebt. Ansonsten bleibt das Programm offen und "blockiert" den Bootprozess.
                Der simple Inhalt des Skripts lautet:

                
                /etc/filebeat/filebeat-freebsd-amd64 &
                
                

                Das Skript muss noch mittels```
                chmod +x

                
                Anschliessend wird es mittels Symlink in das Startupverzeichnis verbunden:
                

                ln -s /etc/filebeat/filebeat.sh /usr/local/etc/rc.d/filebeat.sh

                
                ACHTUNG:
                Vor dem Reboot muss der evtl. noch vorhandene "shellcmd" Eintrag gelöscht werden.
                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.