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

    Pfsync down nach zufälliger Zeit

    Deutsch
    2
    8
    905
    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.
    • D
      DarkMasta
      last edited by

      Hallo Zusammen
      Ich habe zwei pfsense 2.2.4 im Einsatz, diese wurden neu aufgesetzt und nicht über ein Upgrade auf diese Version gebracht.
      Auf jeder pfsense sind 2 LACP Laggs eingerichtet, 1 Lagg (4 Ports für VLANs und 2 Ports für pfsync). Der LACP Lagg für pfsync geht nicht über einen Switch sondern wurde direkt über 2 nicht crossover Kabel an der anderen pfsense angeschlossen.
      Die Hardware auf diesen 2 pfsense ist identisch.

      Leider geht nach einer zufälliger Zeit der pfsync down, ob Nacht oder Tag spielt keine Rolle.
      Ein Neustart der Pfsense oder des Interface behebt das Problem und der Sync funktioniert wieder, leider müssen die getätigten Änderungen auf der Master pfsense auf der Slave pfsense nachgebaut werden oder nochmals gespeichert werden.

      Oct 6 08:16:57	check_reload_status: Reloading filter
Oct 6 08:16:57	php-fpm[5100]: /rc.filter_synchronize: New alert found: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:16:57	php-fpm[5100]: /rc.filter_synchronize: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:16:57	php-fpm[5100]: /rc.filter_synchronize: XML_RPC_Client: Connection to RPC server 192.168.4.2:443 failed. Host is down 103
Oct 6 08:16:57	php-fpm[5100]: /rc.filter_synchronize: New alert found: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:16:57	php-fpm[5100]: /rc.filter_synchronize: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:16:57	php-fpm[5100]: /rc.filter_synchronize: XML_RPC_Client: Connection to RPC server 192.168.4.2:443 failed. Host is down 103
Oct 6 08:16:56	check_reload_status: Syncing firewall
Oct 6 08:15:58	check_reload_status: Reloading filter
Oct 6 08:15:54	php-fpm[6740]: /rc.filter_synchronize: New alert found: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:15:54	php-fpm[6740]: /rc.filter_synchronize: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:15:54	php-fpm[6740]: /rc.filter_synchronize: XML_RPC_Client: Connection to RPC server 192.168.4.2:443 failed. Host is down 103
Oct 6 08:15:54	php-fpm[6740]: /rc.filter_synchronize: New alert found: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:15:54	php-fpm[6740]: /rc.filter_synchronize: A communications error occurred while attempting XMLRPC sync with username admin https://192.168.4.2:443.
Oct 6 08:15:54	php-fpm[6740]: /rc.filter_synchronize: XML_RPC_Client: Connection to RPC server 192.168.4.2:443 failed. Host is down 103
Oct 6 08:15:53	check_reload_status: Syncing firewall
Oct 6 08:11:51	php-fpm[6740]: /rc.linkup: Hotplug event detected for PFSYNC(opt10) but ignoring since interface is configured with static IP (192.168.4.1 )
Oct 6 08:11:50	check_reload_status: Linkup starting lagg1
Oct 6 08:11:50	check_reload_status: Linkup starting igb2
Oct 6 08:11:50	kernel: lagg1: link state changed to DOWN
Oct 6 08:11:50	kernel: igb2: link state changed to DOWN
Oct 6 08:11:30	kernel: igb6: link state changed to DOWN
Oct 6 08:11:30	check_reload_status: Linkup starting igb6
Oct 6 08:09:36	php-fpm[1844]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:09:32	check_reload_status: Reloading filter
Oct 6 08:09:32	php-fpm[1844]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:09:32	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:09:31	php-fpm[1844]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:09:30	check_reload_status: Syncing firewall
Oct 6 08:08:39	php-fpm[63392]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:08:36	check_reload_status: Reloading filter
Oct 6 08:08:35	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:08:35	php-fpm[63392]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:08:34	php-fpm[63392]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:08:33	check_reload_status: Syncing firewall
Oct 6 08:08:20	php-fpm[59183]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:08:16	check_reload_status: Reloading filter
Oct 6 08:08:15	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:08:15	php-fpm[59183]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:08:15	php-fpm[59183]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:08:14	check_reload_status: Syncing firewall
Oct 6 08:05:25	php-fpm[18335]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:05:21	php-fpm[18335]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:05:21	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:05:20	check_reload_status: Reloading filter
Oct 6 08:05:20	php-fpm[18335]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:05:19	check_reload_status: Syncing firewall
Oct 6 08:03:26	php-fpm[12350]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:03:23	check_reload_status: Reloading filter
Oct 6 08:03:22	php-fpm[12350]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:03:22	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:03:21	php-fpm[12350]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:03:20	check_reload_status: Syncing firewall
Oct 6 08:03:07	php-fpm[79579]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:03:02	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:03:02	php-fpm[79579]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:03:02	php-fpm[79579]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:03:01	check_reload_status: Syncing firewall
Oct 6 08:02:24	php-fpm[70584]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:02:19	check_reload_status: Reloading filter
Oct 6 08:02:19	php-fpm[70584]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:02:19	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:02:19	php-fpm[70584]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:02:18	check_reload_status: Syncing firewall
Oct 6 08:01:50	php-fpm[5423]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:01:46	check_reload_status: Reloading filter
Oct 6 08:01:45	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:01:45	php-fpm[5423]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:01:45	php-fpm[5423]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 08:01:44	check_reload_status: Syncing firewall
Oct 6 08:00:17	php-fpm[5423]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 6 08:00:13	check_reload_status: Reloading filter
Oct 6 08:00:12	php-fpm[5423]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 6 08:00:12	kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:00:12	php-fpm[5423]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 6 07:19:34	syslogd: kernel boot file is /boot/kernel/kernel

      Habt ihr eine Idee an was das liegen könnte? Ist ein LACP Lagg für pfsync das Problem?
      Was mich erstaut ist das der Lagg für Stunden funktionieren kann und dann nach Feierabend down geht.
      Die Umgebung wird noch nicht produktiv gebraucht.

      Vielen Dank für eure Hilfe

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

        Hallo!

        @DarkMasta:

        Auf jeder pfsense sind 2 LACP Laggs eingerichtet, 1 Lagg (4 Ports für VLANs und 2 Ports für pfsync). Der LACP Lagg für pfsync geht nicht über einen Switch sondern wurde direkt über 2 nicht crossover Kabel an der anderen pfsense angeschlossen.

        Ein LAGG für den Sync? Was möchtest du den da alles drüber bekommen?

        Was genau der Auslöser ist kann ich auch nicht sagen, aber ich würde mal den Aufbau grundsätzlich in Ordnung bringen. Dein ARP Dienst beschwert sich ständig, dass zwei IPs der pfSense anderweitig verwendet wird:

        Oct 6 08:09:32  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:08:35  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:08:15  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:05:21  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:03:22  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:03:02  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:02:19  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!
Oct 6 08:01:45  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.174 on bge0!
Oct 6 08:00:12  kernel: arp: f0:1f:af:d5:42:e5 is using my IP address 212.60.61.162 on bge0!

        Nach jedem ARP Update wird auch synchronisiert. Vielleicht ist das zuviel.

        Wem gehört f0:1f:af:d5:42:e5? Ist das die 2. pfSense? Auf dieser MAC wird die IP ja auch ständig gewechselt. Sollen die 2 Boxen im CARP Modus laufen?

        1 Reply Last reply Reply Quote 0
        • D
          DarkMasta
          last edited by

          Hallo
          Über diesen Sync-Lagg wird auch nur der Sync selbst laufen, wenn die Netzwerkkarte ausfällt, hätte ich noch einen funktionierenden sync mit der 2. Netzwerkkarte.

          Liegt daran das ich auf dem WAN Interfaces ein paar virtuelle IPs hinterlegt habe.
          Bedeutet meine Master pfsense beklagt sich über die Slave pfsense, da es keine CARP IPs sind (werden nicht über pfsync synchronisiert).
          Werde sonst mal die virtuellen IPs auf der Slave entfernen und es nochmals beobachten ob wirklich dies der Ausfall ist.

          Vielen Dank

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

            So wichtig wäre mir der Sync nicht, dass ich dafür 2 Interfaces opfere bzw. die Komplexität von LAGG in Kauf nehme.

            Aber warum lässt du die beiden nicht gleich im CARP Modus laufen, wenn sie ohnehin ständig parallel laufen und auch synchronisiert werden.

            Grüße

            1 Reply Last reply Reply Quote 0
            • D
              DarkMasta
              last edited by

              Hallo Zusammen

              Habe auf der Slave pfsense alle Virtuellen IP gelöscht, leider ohne Erfolg.
              Das Problem besteht weiterhin.

              Oct 7 08:41:42 php-fpm[86648]: /rc.linkup: Hotplug event detected for PFSYNC(opt10) but ignoring since interface is configured with static IP (192.168.4.1 )
Oct 7 08:41:41	check_reload_status: Linkup starting lagg1
Oct 7 08:41:41	kernel: lagg1: link state changed to DOWN
Oct 7 08:41:41	kernel: igb2: link state changed to DOWN
Oct 7 08:41:41	check_reload_status: Linkup starting igb2
Oct 7 08:03:05	php-fpm[6049]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 7 08:03:03	check_reload_status: Reloading filter
Oct 7 08:03:03	php-fpm[83613]: /system.php: NTPD is starting up.
Oct 7 08:03:00	php-fpm[6049]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 7 08:03:00	php-fpm[6049]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 7 08:00:04	syslogd: kernel boot file is /boot/kernel/kernel

              Hab zusammen 12 Interfaces daher genug :)
              Ich nehme mal an man könnte die pfsense dazubringen Mail zu verschicken wenn der pfsync down geht oder?! :)

              Aber warum lässt du die beiden nicht gleich im CARP Modus laufen, wenn sie ohnehin ständig parallel laufen und auch synchronisiert werden.

              Du meinst die Wan Schnittstelle auf CARP stellen um keine virtuellen IPs sondern CARP IPs zu hinterlegen, welche wiederum durch den pfsync synchronisiert werden mit der Slave pfsense?
              Bräuchte ich nicht 3 öffentliche IPs von meinem ISP und nicht nur 1?

              Sollte bei einem LACP Lagg nicht der ganze Traffic über beide Kabel laufen?
              Wenn ich Kabel A vom pfsync entferne läuft der Sync weiter über Kabel B, wenn ich jedoch Kabel B entferne ist der Sync sofort down und erholt sich erst nach dem ich das Interface neustarte.
              Es sieht so aus als würde der Traffic nur über ein bestimmtes Kabel laufen und wenn das Down geht switcht er nicht automatisch auf anderes Kabel sondern erst wenn das pfSync Interface neugestartet wird.

              Hat noch jemand eine Idee?

              Vielen Dank

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

                @DarkMasta:

                Das Problem besteht weiterhin.

                Oct 7 08:41:42 php-fpm[86648]: /rc.linkup: Hotplug event detected for PFSYNC(opt10) but ignoring since interface is configured with static IP (192.168.4.1 )
Oct 7 08:41:41	check_reload_status: Linkup starting lagg1
Oct 7 08:41:41	kernel: lagg1: link state changed to DOWN
Oct 7 08:41:41	kernel: igb2: link state changed to DOWN
Oct 7 08:41:41	check_reload_status: Linkup starting igb2
Oct 7 08:03:05	php-fpm[6049]: /rc.filter_synchronize: Filter sync successfully completed with https://192.168.4.2:443.
Oct 7 08:03:03	check_reload_status: Reloading filter
Oct 7 08:03:03	php-fpm[83613]: /system.php: NTPD is starting up.
Oct 7 08:03:00	php-fpm[6049]: /rc.filter_synchronize: XMLRPC sync successfully completed with https://192.168.4.2:443.
Oct 7 08:03:00	php-fpm[6049]: /rc.filter_synchronize: Beginning XMLRPC sync to https://192.168.4.2:443.
Oct 7 08:00:04	syslogd: kernel boot file is /boot/kernel/kernel

                Ich sehe in dem Log aber nun keine Anzeichen eines Problems, weswegen das Interface down geht.
                Und es kommt auch nicht wieder hoch, trotz "Linkup starting lagg1"?
                Hab mit LAGG auf der pfSense keine Erfahrung.

                Mit den Schnittstellen selbst hast du keine Probleme wie MBUF? Hast du die Anpassungen durchgeführt?
                https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Intel_igb.284.29_and_em.284.29_Cards

                @DarkMasta:

                Ich nehme mal an man könnte die pfsense dazubringen Mail zu verschicken wenn der pfsync down geht oder?! :)

                Wenn du in System: Advanced: Notifications den SMTP Server konfigurierst, macht die pfSense das.

                @DarkMasta:

                Du meinst die Wan Schnittstelle auf CARP stellen um keine virtuellen IPs sondern CARP IPs zu hinterlegen, welche wiederum durch den pfsync synchronisiert werden mit der Slave pfsense?
                Bräuchte ich nicht 3 öffentliche IPs von meinem ISP und nicht nur 1?

                Seit Version 2.2 nicht mehr zwingend. Siehe:
                https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#CARP
                https://doc.pfsense.org/index.php/High_Availability#Common_Requirements

                Habe damit aber auch nicht selbst die Erfahrung. Ich leiste mir noch die 2 Extra-IPs pro Subetz, dummer Weise hab ich auf  einer 3 kleine Netze  >:(
                Es gibt mit der CARP-VIP im anderen Subnetz aber ein paar Einschränkungen. Hier ist was davon beschrieben:
                https://forum.pfsense.org/index.php?topic=87546.0

                @DarkMasta:

                Sollte bei einem LACP Lagg nicht der ganze Traffic über beide Kabel laufen?
                Wenn ich Kabel A vom pfsync entferne läuft der Sync weiter über Kabel B, wenn ich jedoch Kabel B entferne ist der Sync sofort down und erholt sich erst nach dem ich das Interface neustarte.

                Ich kenne LACP nur zwischen zwei aktuellen Linux-Boxen und einem Netgear Switch. Ich habe mir da mal den Traffic auf den einzelnen Schnittstellen angesehen. Es hat so ausgesehen als ob bis zu einer gewissen Bandbreite alles über die erste läuft und erst darüber hinaus auch über die zweite. Was passiert, wenn ich ein Kabel abziehe, hab ich aber da nicht getestet. Könnte ich noch versuchen. Sollte eigentlich alles weiterlaufen.

                Grüße

                1 Reply Last reply Reply Quote 0
                • D
                  DarkMasta
                  last edited by

                  Hab zwar noch nichts verändert doch heute Morgen lief der pfsync noch.
                  Ich habe auch die Kabel wieder einzel ausgesteckt und der Sync lief dank dem Lagg einwandfrei weiter.
                  Werde in den nächsten Wochen dies noch ein wenig beobachten bevor ich produktiv gehe.

                  Es gibt mit der CARP-VIP im anderen Subnetz aber ein paar Einschränkungen. Hier ist was davon beschrieben:
                  https://forum.pfsense.org/index.php?topic=87546.0

                  Ich habe den Thread gelesen aber habe nicht herausgefunden was für Einschränkungen du meinst.

                  Wenn ich das richtig verstehe muss ich auf der WAN-Schnittstelle eine IP hinterlegen die im selben Subnetz ist wie die öffentliche IP selbst und danach eine CARP IP hinterlegen und per NAT Outbound allen Traffic über diese CARP-IP steuern?!

                  Master pfsense WAN IP: 172.16.0.1 /28
                  Slave pfsense WAN IP: 172.16.0.2  /28
                  CARP WAN IP: 210.45.200.1 /28

                  Die WAN IP spielt keine Rolle solang /28  das selbe ist? Gateway etwas spezielles beachten?

                  Vielen Dank

                  Gruss DarkMasta

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

                    Eine Einschränkung ist bspw., dass die Backup-Box so nicht mehr von außen erreichbar ist, hat ja auch keine IP. Es gibt aber noch weitere, aber, so weit ich mich erinnere, verkraftbare Einschränkungen.

                    Wie gesagt, ich kann dich bezüglich CARP IP außerhalb des Interfaces Subnetzes leider nicht mit Erfahrung unterstützen.

                    Aber dass die Subnetzte der CARP IP und der Interface IP dieselbe Größe haben müssen, kann ich mir auch nicht vorstellen. Ergibt ja keinen Sinn.
                    Ich denke, die beiden Interfaces, die du zusammenschaltest, müssen natürlich in einem gemeinsamen Subnetz sein, in dem eben beide Platz haben (min. /31) und ein Datenaustausch zwischen den beiden muss möglich sein, bspw. über Switch.
                    Die CARP IP darf dann irgendwas ganz anderes sein, anderes Subnetz und auch andere Größe.
                    Die WAN Interfaces der beiden Boxen bekommen die neue IP im privaten Bereich und die bisherige WAN-IP wird dann die CARP-VIP.

                    Im Outbound NAT musst du auf manuell umstellen und die Regeln einfach anpassen. Per Default erstellt pfSense die Outbound NAT Regel automatisch auf die Interface-IP, und die ist ja nun eine andere. Daher musst du sie anpassen und bei Translation deine öffentliche IP eintragen.
                    Das WAN Gateway bleibt unverändert.

                    Natürlich musst du die Umstellungen auf CARP auch für deine internen IPs machen. Hier sollte aber die Interface IP im selben Subnetz sein, ansonsten in gleicher Weise. Also die bisherige Interface IP wird die CARP-VIP, denn die verwenden ja vermutlich die Hosts als Gateway, die Interfaces bekommen eine andere IP.

                    Grüße

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post