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



  • 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:

    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!


  • Rebel Alliance Moderator

    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.



  • 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


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



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



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

Log in to reply