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

    Alert "XMLRPC method captive_portal_sync" in 2.5

    HA/CARP/VIPs
    4
    22
    1.7k
    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.
    • L
      Luca De Andreis
      last edited by

      Hi all,
      I've two pfsense in HA mode in production, a copy live in an isolated "box" on the same version: 2.4.5p1.
      I've just test to upgrade to very last 2.5 version and I see an alert:

      /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync

      The 2.5 version works fine, but when I set the master as slave and rollback to master I see this alert.
      On 2.4.5p1 works fine, the same identical firewalls are perfect.

      On 2.5 captive_portal works, if a change the master I can see the change on slave, only during the switch master->slave->master I see this alert, or... reboot the master, correctly the slave become master, after the real master become that and... I can see the alert...

      Any idea ?

      Thanks
      Luca

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Post the system logs from both the primary and secondary nodes from around the time that error happens. I can't reproduce it here. I can reboot the primary node or put it into/out of maintenance mode, disable/enable CARP, etc. All works fine, and it does have captive portal enabled.

        Also need a lot more information about your setup and environment, like what features you have configured and so on.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        L 1 Reply Last reply Reply Quote 0
        • L
          Luca De Andreis @jimp
          last edited by

          @jimp

          Thanks a lot for the reply!
          This is a test environment, I cloned the two VMs in HA of the production environment, running in KVM in version 2.4.5p1, without any problem, absolutely perfect.
          NICs are in virtio.
          After upgrade to 2.5: 2.5.0.a.20210104.0250
          When master become slave (Enter Persistent CARP Maintenance Mode) all work correctly: these are the logs:

          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 kernel carp: 1@vtnet2: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 2@vtnet3: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 10@vtnet11: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 6@vtnet7: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 9@vtnet10: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 5@vtnet6: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 16@vtnet14: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 15@vtnet13: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 7@vtnet8: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 17@vtnet9: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 14@vtnet5: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 13@vtnet1: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 3@vtnet4: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 kernel carp: 12@vtnet0: MASTER -> BACKUP (more frequent advertisement received)
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:47 check_reload_status 371 Carp backup event
          Jan 6 16:38:48 php-fpm 6741 /rc.carpbackup: HA cluster member "(10.19.16.1@vtnet14): (VIDEOCONFERENZA)" has resumed CARP state "BACKUP" for vhid 16
          Jan 6 16:38:49 php-fpm 6741 /rc.carpbackup: HA cluster member "(94.83.xxx.155@vtnet0): (WAN)" has resumed CARP state "BACKUP" for vhid 12
          Jan 6 16:38:49 php-fpm 6741 /rc.carpbackup: HA cluster member "(94.83.xxx.152@vtnet0): (WAN)" has resumed CARP state "BACKUP" for vhid 12
          Jan 6 16:38:49 php-fpm 6741 /rc.carpbackup: HA cluster member "(94.83.xxx.143@vtnet0): (WAN)" has resumed CARP state "BACKUP" for vhid 12

          All CARP VIPS are in backup status, the test client works correctly.

          When I disable Maintenance Mode, all CARP VIPS become master, the test client works correctly, by I see an alert...

          an 6 16:43:19 check_reload_status 371 Carp master event
          Jan 6 16:43:19 kernel carp: 3@vtnet4: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:19 kernel carp: 1@vtnet2: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:19 kernel carp: 5@vtnet6: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:19 kernel carp: 6@vtnet7: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:19 kernel carp: 2@vtnet3: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:19 kernel arp: 10.19.8.1 moved from 00:00:5e:00:01:05 to 9a💿6f:3a:50:44 on vtnet6
          Jan 6 16:43:19 check_reload_status 371 Carp master event
          Jan 6 16:43:19 check_reload_status 371 Carp master event
          Jan 6 16:43:19 check_reload_status 371 Carp master event
          Jan 6 16:43:19 check_reload_status 371 Carp master event
          Jan 6 16:43:20 php-fpm 6741 /rc.carpmaster: HA cluster member "(10.19.5.130@vtnet2): (MPLS_ROUTER_DR)" has resumed CARP state "MASTER" for vhid 1
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 kernel carp: 9@vtnet10: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 7@vtnet8: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 15@vtnet13: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 16@vtnet14: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 10@vtnet11: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 17@vtnet9: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 14@vtnet5: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 12@vtnet0: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel carp: 13@vtnet1: BACKUP -> MASTER (preempting a slower master)
          Jan 6 16:43:20 kernel arp: 10.19.15.1 moved from 00:00:5e:00:01:0f to 2e:d7:27:88:79:36 on vtnet13
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 check_reload_status 371 Carp master event
          Jan 6 16:43:20 php-fpm 6741 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
          Jan 6 16:43:22 php-fpm 70065 /rc.carpmaster: HA cluster member "(10.19.15.1@vtnet13): (LABORATORI_INTERNET)" has resumed CARP state "MASTER" for vhid 15
          Jan 6 16:43:22 php-fpm 70065 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
          Jan 6 16:43:30 php-fpm 6741 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:30 php-fpm 6741 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:31 php-fpm 6741 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
          Jan 6 16:43:32 php-fpm 70065 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:32 php-fpm 70065 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:32 php-fpm 70065 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
          Jan 6 16:43:41 php-fpm 6741 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:41 php-fpm 6741 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:42 php-fpm 70065 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
          Jan 6 16:43:42 php-fpm 70065 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:

          When I rollback to 2.4.5p1 the same test environment (absolutely identical) works fine.
          Available for any test

          Very thanks

          Luca

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            To avoid confusing the nodes themselves and the CARP state, please call the firewalls "Primary" and "Secondary" and the CARP state "Master" and "Backup".

            It looks like the logs you posted are only from the primary node. What is in the logs on the secondary node?

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            L 1 Reply Last reply Reply Quote 0
            • L
              Luca De Andreis @jimp
              last edited by

              @jimp
              Yes, you are right !!!

              Please note that this is a completely isolated test environment, with the VMs imported directly from the production environment.
              Only the default gateway is reachable and the WAN connectivity is operational, some secondary gateways are not (correctly) reachable.
              This is not a problem for PfSense 2.4.5p1.

              Primary in state Master going to state Backup:

              **** Primary LOG ****
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 kernel carp: 7@vtnet8: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 17@vtnet9: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 15@vtnet13: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 12@vtnet0: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 14@vtnet5: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 9@vtnet10: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 13@vtnet1: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 10@vtnet11: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 kernel carp: 16@vtnet14: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:16 check_reload_status 371 Carp backup event
              Jan 6 18:15:17 kernel carp: 2@vtnet3: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:17 kernel carp: 1@vtnet2: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:17 kernel carp: 5@vtnet6: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:17 kernel carp: 6@vtnet7: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:17 kernel carp: 3@vtnet4: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:15:17 check_reload_status 371 Carp backup event
              Jan 6 18:15:17 check_reload_status 371 Carp backup event
              Jan 6 18:15:17 check_reload_status 371 Carp backup event
              Jan 6 18:15:17 check_reload_status 371 Carp backup event
              Jan 6 18:15:17 check_reload_status 371 Carp backup event
              Jan 6 18:15:18 php-fpm 38791 /rc.carpbackup: HA cluster member "(10.19.10.1@vtnet7): (LABORATORI)" has resumed CARP state "BACKUP" for vhid 6 Jan 6 18:51:06 check_reload_status 371 Carp backup event
              Jan 6 18:51:06 kernel carp: 3@vtnet4: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:06 kernel carp: 5@vtnet6: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:06 kernel carp: 2@vtnet3: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:06 kernel carp: 6@vtnet7: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:06 kernel carp: 1@vtnet2: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:06 check_reload_status 371 Carp backup event
              Jan 6 18:51:06 check_reload_status 371 Carp backup event
              Jan 6 18:51:06 check_reload_status 371 Carp backup event
              Jan 6 18:51:06 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 kernel carp: 17@vtnet9: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 12@vtnet0: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 13@vtnet1: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 9@vtnet10: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 16@vtnet14: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 15@vtnet13: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 10@vtnet11: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 7@vtnet8: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 kernel carp: 14@vtnet5: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:07 check_reload_status 371 Carp backup event
              Jan 6 18:51:08 php-fpm 81762 /rc.carpbackup: HA cluster member "(10.19.7.1@vtnet11): (SANDBOX)" has resumed CARP state "BACKUP" for vhid 10

              **** Secondary LOG ****
              Jan 6 18:51:04 check_reload_status 371 Reloading filter
              Jan 6 18:51:06 kernel carp: 1@vtnet2: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:06 kernel carp: 6@vtnet7: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:06 kernel carp: 3@vtnet4: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:06 kernel carp: 2@vtnet3: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:06 kernel carp: 5@vtnet6: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:06 check_reload_status 371 Carp master event
              Jan 6 18:51:06 check_reload_status 371 Carp master event
              Jan 6 18:51:06 check_reload_status 371 Carp master event
              Jan 6 18:51:06 check_reload_status 371 Carp master event
              Jan 6 18:51:06 check_reload_status 371 Carp master event
              Jan 6 18:51:06 rc.gateway_alarm 57356 >>> Gateway alarm: GW_BROCADE_INTERC_VRRP (Addr:10.19.250.10 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:51:06 check_reload_status 371 updating dyndns GW_BROCADE_INTERC_VRRP
              Jan 6 18:51:06 check_reload_status 371 Restarting ipsec tunnels
              Jan 6 18:51:06 check_reload_status 371 Restarting OpenVPN tunnels/interfaces
              Jan 6 18:51:06 check_reload_status 371 Reloading filter
              Jan 6 18:51:06 rc.gateway_alarm 57246 >>> Gateway alarm: GW_LAN (Addr:10.0.0.254 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:51:06 check_reload_status 371 updating dyndns GW_LAN
              Jan 6 18:51:06 check_reload_status 371 Restarting ipsec tunnels
              Jan 6 18:51:07 check_reload_status 371 Restarting OpenVPN tunnels/interfaces
              Jan 6 18:51:07 rc.gateway_alarm 61731 >>> Gateway alarm: GW_VPN (Addr:10.19.5.150 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:51:07 rc.gateway_alarm 66143 >>> Gateway alarm: GW_MPLS (Addr:10.19.5.129 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:51:07 rc.gateway_alarm 68732 >>> Gateway alarm: GW_SG (Addr:10.19.6.240 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 kernel carp: 12@vtnet0: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 17@vtnet9: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 13@vtnet1: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 9@vtnet10: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 14@vtnet5: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 15@vtnet13: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 16@vtnet14: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 7@vtnet8: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 kernel carp: 10@vtnet11: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 check_reload_status 371 Carp master event
              Jan 6 18:51:07 php-fpm 51724 /rc.carpmaster: HA cluster member "(10.19.250.1@vtnet4): (BROCADE_INTERCONNECTION)" has resumed CARP state "MASTER" for vhid 3
              Jan 6 18:51:09 minicron 71925 (/etc/rc.prunecaptiveportal) terminated by signal 15 (Terminated)

              Primary in state Backup going to state Master:

              **** Primary LOG ****
              Jan 6 18:57:56 check_reload_status 371 Syncing firewall
              Jan 6 18:57:57 php-fpm 81762 /rc.filter_synchronize: Beginning XMLRPC sync data to https://10.19.99.2:8443/xmlrpc.php.
              Jan 6 18:57:57 php-fpm 81762 /rc.filter_synchronize: XMLRPC reload data success with https://10.19.99.2:8443/xmlrpc.php (pfsense.host_firmware_version).
              Jan 6 18:57:57 php-fpm 81762 /rc.filter_synchronize: XMLRPC versioncheck: 21.2 -- 21.2
              Jan 6 18:57:57 php-fpm 81762 /rc.filter_synchronize: Beginning XMLRPC sync data to https://10.19.99.2:8443/xmlrpc.php.
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 kernel carp: 17@vtnet9: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 13@vtnet1: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 9@vtnet10: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 14@vtnet5: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 12@vtnet0: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 10@vtnet11: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 16@vtnet14: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 15@vtnet13: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel carp: 7@vtnet8: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:01 kernel arp: 10.19.18.1 moved from 00:00:5e:00:01:11 to f6:aa:e3:22:40:96 on vtnet9
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:01 check_reload_status 371 Carp master event
              Jan 6 18:58:02 check_reload_status 371 Carp master event
              Jan 6 18:58:02 kernel carp: 1@vtnet2: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:02 kernel carp: 5@vtnet6: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:02 kernel carp: 2@vtnet3: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:02 kernel carp: 3@vtnet4: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:02 kernel carp: 6@vtnet7: BACKUP -> MASTER (preempting a slower master)
              Jan 6 18:58:02 check_reload_status 371 Carp master event
              Jan 6 18:58:02 check_reload_status 371 Carp master event
              Jan 6 18:58:02 check_reload_status 371 Carp master event
              Jan 6 18:58:02 check_reload_status 371 Carp master event
              Jan 6 18:58:03 php-fpm 5363 /rc.carpmaster: HA cluster member "(10.19.16.1@vtnet14): (VIDEOCONFERENZA)" has resumed CARP state "MASTER" for vhid 16
              Jan 6 18:58:03 php-fpm 5363 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
              Jan 6 18:58:04 php-fpm 81762 /rc.filter_synchronize: XMLRPC reload data success with https://10.19.99.2:8443/xmlrpc.php (pfsense.restore_config_section).
              Jan 6 18:58:04 php-fpm 81762 /rc.carpmaster: HA cluster member "(10.19.15.1@vtnet13): (LABORATORI_INTERNET)" has resumed CARP state "MASTER" for vhid 15
              Jan 6 18:58:04 php-fpm 81762 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
              Jan 6 18:58:13 php-fpm 5363 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:13 php-fpm 5363 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:13 php-fpm 5363 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
              Jan 6 18:58:14 php-fpm 81762 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:14 php-fpm 81762 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:14 php-fpm 81762 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
              Jan 6 18:58:23 php-fpm 5363 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:23 php-fpm 5363 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:24 php-fpm 81762 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
              Jan 6 18:58:24 php-fpm 81762 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:

              **** Secondary LOG ****
              Jan 6 18:57:58 check_reload_status 371 Syncing firewall
              Jan 6 18:57:59 check_reload_status 371 Reloading filter
              Jan 6 18:58:01 kernel carp: 17@vtnet9: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 12@vtnet0: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 13@vtnet1: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 9@vtnet10: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 10@vtnet11: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 14@vtnet5: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 16@vtnet14: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 15@vtnet13: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 kernel carp: 7@vtnet8: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:01 check_reload_status 371 Carp backup event
              Jan 6 18:58:02 rc.gateway_alarm 225 >>> Gateway alarm: GW_LAN (Addr:10.0.0.254 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:58:02 check_reload_status 371 updating dyndns GW_LAN
              Jan 6 18:58:02 check_reload_status 371 Restarting ipsec tunnels
              Jan 6 18:58:02 check_reload_status 371 Restarting OpenVPN tunnels/interfaces
              Jan 6 18:58:02 check_reload_status 371 Reloading filter
              Jan 6 18:58:02 rc.gateway_alarm 4313 >>> Gateway alarm: GW_VPN (Addr:10.19.5.150 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:58:02 rc.gateway_alarm 1846 >>> Gateway alarm: GW_MPLS (Addr:10.19.5.129 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:58:02 rc.gateway_alarm 4271 >>> Gateway alarm: GW_SG (Addr:10.19.6.240 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:58:02 check_reload_status 371 updating dyndns GW_VPN
              Jan 6 18:58:02 check_reload_status 371 Restarting ipsec tunnels
              Jan 6 18:58:02 check_reload_status 371 Restarting OpenVPN tunnels/interfaces
              Jan 6 18:58:02 rc.gateway_alarm 9331 >>> Gateway alarm: GW_BROCADE_INTERC_VRRP (Addr:10.19.250.10 Alarm:1 RTT:0.000ms RTTsd:0.000ms Loss:100%)
              Jan 6 18:58:02 check_reload_status 371 Carp backup event
              Jan 6 18:58:02 kernel carp: 5@vtnet6: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:02 kernel carp: 6@vtnet7: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:02 kernel carp: 3@vtnet4: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:02 kernel carp: 2@vtnet3: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:02 kernel carp: 1@vtnet2: MASTER -> BACKUP (more frequent advertisement received)
              Jan 6 18:58:02 check_reload_status 371 Carp backup event
              Jan 6 18:58:02 check_reload_status 371 Carp backup event
              Jan 6 18:58:02 check_reload_status 371 Carp backup event
              Jan 6 18:58:02 check_reload_status 371 Carp backup event
              Jan 6 18:58:03 php-fpm 48015 /rc.carpbackup: HA cluster member "(10.19.17.1@vtnet5): (DMZ_2)" has resumed CARP state "BACKUP" for vhid 14
              Jan 6 18:58:04 minicron 36209 (/etc/rc.prunecaptiveportal) terminated by signal 15 (Terminated)

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                There is something wrong with your configuration. The secondary shouldn't be seeing gateway events like that when a CARP transition happens. That makes me think you have some incorrect NAT rules, or possibly incorrect gateway definitions as well.

                It's also possible you have the option set to kill firewall states when a gateway goes down which, coupled with those gateway events, could lead to communication errors between the nodes.

                It may be behaving differently on 2.5.0 for a variety of reasons, but it looks more like a configuration error than a bug.

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                L 1 Reply Last reply Reply Quote 0
                • L
                  Luca De Andreis @jimp
                  last edited by

                  @jimp

                  ... I can try to recreate full gateways structure in the isolated box, exactly like in production environment. NAT seems ok, NAT inbond/outbond use only CARP (or alias CARP) VIPs.

                  I refine the box configuration by adding the missing gateways and try. Thank you very much, if I have any news I will update you.

                  viktor_gV 1 Reply Last reply Reply Quote 0
                  • viktor_gV
                    viktor_g Netgate @Luca De Andreis
                    last edited by

                    @luca-de-andreis unable to reproduce your issue on my 2.5 HA cluster,

                    Please check your configuration, make sure you have set captive portal HA (services_captiveportal_hasync.php) on the slave node only!

                    L 1 Reply Last reply Reply Quote 0
                    • L
                      Luca De Andreis @viktor_g
                      last edited by

                      @viktor_g

                      OK, full gateways structure is online, all gateways are UP.

                      • Yes, captive portal HA is set only on secondary node (PfSense 2.4.5p1 did not have this setting).
                      • State Killing on Gateway Failure is disabled on all nodes.

                      Now the new logs:

                      Primary in state Master going to state Backup:
                      **** Primary LOG ****
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 kernel carp: 3@vtnet4: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 1@vtnet2: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 5@vtnet6: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 2@vtnet3: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 6@vtnet7: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 kernel carp: 12@vtnet0: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 15@vtnet13: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 9@vtnet10: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 17@vtnet9: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 13@vtnet1: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 16@vtnet14: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 7@vtnet8: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 10@vtnet11: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 kernel carp: 14@vtnet5: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:53 check_reload_status 371 Carp backup event
                      Jan 7 08:09:55 php-fpm 89749 /rc.carpbackup: HA cluster member "(10.19.15.1@vtnet13): (LABORATORI_INTERNET)" has resumed CARP state "BACKUP" for vhid 15

                      **** Secondary LOG ****

                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 kernel carp: 3@vtnet4: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 2@vtnet3: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 5@vtnet6: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 1@vtnet2: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 6@vtnet7: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 kernel carp: 9@vtnet10: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 12@vtnet0: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 15@vtnet13: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 17@vtnet9: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 13@vtnet1: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 16@vtnet14: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 7@vtnet8: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 10@vtnet11: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 kernel carp: 14@vtnet5: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:53 check_reload_status 371 Carp master event
                      Jan 7 08:09:55 php-fpm 50633 /rc.carpmaster: HA cluster member "(10.19.16.1@vtnet14): (VIDEOCONFERENZA)" has resumed CARP state "MASTER" for vhid 16
                      Jan 7 08:09:55 minicron 75224 (/etc/rc.prunecaptiveportal) terminated by signal 15 (Terminated)

                      Primary in state Backup going to state Master:

                      **** Primary LOG ****

                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 kernel carp: 2@vtnet3: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 1@vtnet2: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 3@vtnet4: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 6@vtnet7: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 5@vtnet6: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel arp: 10.19.5.130 moved from 00:00:5e:00:01:01 to aa:7a:fa:ff:fd:e0 on vtnet2
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 kernel carp: 12@vtnet0: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 15@vtnet13: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 9@vtnet10: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 17@vtnet9: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 13@vtnet1: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 10@vtnet11: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 7@vtnet8: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 16@vtnet14: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 kernel carp: 14@vtnet5: BACKUP -> MASTER (preempting a slower master)
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:23 check_reload_status 371 Carp master event
                      Jan 7 08:15:24 php-fpm 89749 /rc.carpmaster: HA cluster member "(10.19.10.1@vtnet7): (LABORATORI)" has resumed CARP state "MASTER" for vhid 6
                      Jan 7 08:15:24 php-fpm 88005 /rc.carpmaster: HA cluster member "(10.19.15.1@vtnet13): (LABORATORI_INTERNET)" has resumed CARP state "MASTER" for vhid 15
                      Jan 7 08:15:25 php-fpm 89749 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
                      Jan 7 08:15:25 php-fpm 88005 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
                      Jan 7 08:15:35 php-fpm 89749 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:35 php-fpm 89749 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:35 php-fpm 89749 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
                      Jan 7 08:15:35 php-fpm 88005 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:35 php-fpm 88005 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:35 php-fpm 88005 /rc.carpmaster: Beginning XMLRPC sync data to https://10.19.99.2:443/xmlrpc.php.
                      Jan 7 08:15:45 php-fpm 89749 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:45 php-fpm 89749 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:45 php-fpm 88005 /rc.carpmaster: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:
                      Jan 7 08:15:45 php-fpm 88005 /rc.carpmaster: New alert found: A communications error occurred while attempting to call XMLRPC method captive_portal_sync:

                      **** Secondary LOG ****

                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 kernel carp: 2@vtnet3: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 6@vtnet7: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 1@vtnet2: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 3@vtnet4: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 5@vtnet6: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 kernel carp: 12@vtnet0: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 15@vtnet13: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 9@vtnet10: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 17@vtnet9: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 10@vtnet11: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 13@vtnet1: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 7@vtnet8: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 14@vtnet5: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 kernel carp: 16@vtnet14: MASTER -> BACKUP (more frequent advertisement received)
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:23 check_reload_status 371 Carp backup event
                      Jan 7 08:15:25 php-fpm 67498 /rc.carpbackup: HA cluster member "(10.19.17.1@vtnet5): (DMZ_2)" has resumed CARP state "BACKUP" for vhid 14
                      Jan 7 08:15:25 minicron 85350 (/etc/rc.prunecaptiveportal) terminated by signal 15 (Terminated)

                      L 1 Reply Last reply Reply Quote 0
                      • L
                        Luca De Andreis @Luca De Andreis
                        last edited by

                        Another information:
                        If I disable xmlrpc on "Captive Portal" all works fine.....

                        9bc0691b-dfc5-4627-bace-b1dc1bc7de29-immagine.png

                        viktor_gV 1 Reply Last reply Reply Quote 0
                        • viktor_gV
                          viktor_g Netgate @Luca De Andreis
                          last edited by

                          @luca-de-andreis Please provide more info about your CP configuration

                          L 1 Reply Last reply Reply Quote 0
                          • L
                            Luca De Andreis @viktor_g
                            last edited by

                            @viktor_g

                            Thanks for reply !!!!

                            I tried to completely delete all the configuration imported from version 2.4.5p1.

                            • If I disable the captive portal everything works without warning.

                            • If I set even a minimal configuration: define a zone, enable captive portal, select the interface and everything else set by default, no MAC no voucher no customization, nothing ...

                            814f0260-a259-4495-b4cf-02229bbbd403-immagine.png

                            L 1 Reply Last reply Reply Quote 0
                            • L
                              Luca De Andreis @Luca De Andreis
                              last edited by

                              I tried to convert NICs from virtio (vtnet) to e1000 (em) getting exactly the same error.
                              With the latest versions of PfSense the virtio works correctly even in HA mode. I double-checked everything and I don't think there are any errors in the HA configuration. It seems a problem of version 2.5, with 2.4.5p1 it works perfectly, I don't know ....

                              L 1 Reply Last reply Reply Quote 0
                              • L
                                Luca De Andreis @Luca De Andreis
                                last edited by

                                @viktor_g

                                I keep trying, with no results.

                                I updated to the latest version: 2.5.0.a.20210124 without success, the behavior is absolutely the same.

                                • If I disable the "Captive portal" item in XMLRPC sync everything works correctly, the problem disappears.

                                • No problems in the LOG regarding the gateways or network, everything works as it should and there are no alerts.

                                The alert occurs during the transition from secondary to primary.

                                I ran out of ideas :(

                                L 1 Reply Last reply Reply Quote 0
                                • L
                                  Luca De Andreis @Luca De Andreis
                                  last edited by

                                  ... I use 15 interfaces and 14 CARP VIPs (other several ALIAS VIPs).
                                  Possible internal timeout ?

                                  L 1 Reply Last reply Reply Quote 0
                                  • L
                                    Luca De Andreis @Luca De Andreis
                                    last edited by

                                    YESSSSSSSSSSSS found the solution !!!!!!!!!!!!!!!!!!!!!

                                    It's a bug. The problem disappears if I use the default web interface port (443) I used to use a non-standard port before (8443)

                                    It is not an ACL problem, it's a bug.

                                    F 1 Reply Last reply Reply Quote 0
                                    • F
                                      free4 Rebel Alliance @Luca De Andreis
                                      last edited by free4

                                      @luca-de-andreis Hi,

                                      I'm the user who developed this feature

                                      I am actually a bit sorry for this issue... It's basically a stupid copy paste issue (coming from from there) where I forgot to properly rename a variable ( $port => $xmlrpc_port) ...

                                      It also passed through all my tests (and the ones of Netgate) because I didn't think of changing the GUI port during them...I guess everyone's make mistakes 👼 .

                                      It's not really critical through : the issue can easily be fixed by updating the file (using the Services->File manager menu. It's a one-line fix so it's ok i guess), by using the patch package (with this URL), or by simply reverting the GUI to the port 443 (which may not be an acceptable workaround...I understand)

                                      I'm not entirely sure of what Netgate will do now that 2.5.0 is out there. If I read correctly @jimp comment on the issue i guess there will be a day-one patch containing few hotfixes including this one ?

                                      L 1 Reply Last reply Reply Quote 0
                                      • L
                                        Luca De Andreis @free4
                                        last edited by

                                        @free4

                                        Hi, no problem, for now the version 2.5.0 still presents this problem, however it is sufficient to modify the php file as you specified and everything will work again.
                                        It's really not a problem, I just went crazy for at least a month because I thought it was my configuration problem and I couldn't find a solution ... everything seemed correct.

                                        Thanks so much

                                        F 1 Reply Last reply Reply Quote 0
                                        • F
                                          free4 Rebel Alliance @Luca De Andreis
                                          last edited by

                                          @luca-de-andreis the day-one patch just got applied on git. I'm guessing the new ISO is being generated, it should be available for everyone soon

                                          1 Reply Last reply Reply Quote 0
                                          • jimpJ
                                            jimp Rebel Alliance Developer Netgate
                                            last edited by

                                            We don't re-roll releases like that. There isn't really a "day one patch" per se. I committed a fix into git but that doesn't mean it goes anywhere beyond that yet.

                                            You can install the System Patches package and then create an entry for fef846ce7ec4158a140f359b0fb35182f6ae9db9 to apply the fix, or you can make the change manually.

                                            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                            Need help fast? Netgate Global Support!

                                            Do not Chat/PM for help!

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