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

    HA strange behaviour, problems on passive box

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    15 Posts 2 Posters 1.4k 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.
    • V
      ViniciusBr
      last edited by

      So more info:

      While PF1 is the master, a server inside the DMZ can see the mac address of VIP and PF1, not PF2:
      pf1.JPG

      While PF2 is the master, same server in the DMZ can see the mac addresses of PF1 and PF2, but not VIP:
      pf2.JPG

      Another thing: when getting back to PF1 I am getting this message, not sure if it is actually an issue or not:
      carp-demotion.JPG

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

        @viniciusbr
        Seems not to be a normal behavior.
        What tells the system log?

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

          Logs after the failover:

          PF1:
          NOTE: check the top line, this one is ONLY for the DMZ, not for the others, not sure why
          log-pf1.JPG

          PF2:
          log-pf2.JPG

          PF2 goes to MASTER as expected:
          pf2-master.JPG

          PF1 has disabled status:
          35c6a07c-2500-4954-adcf-d505d89e9d79-image.png

          Now let's get all back, cleared the logs first

          PF1 logs after becoming master again:
          pf1-failback.JPG

          And then that RESET DEMOTION STATUS button appeared again, when clicking it I get new lines in the log:
          pf1-failback2.JPG

          And PF2 logs after becoming backup:
          pf2-failback.JPG

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

            @viniciusbr
            Don't disable CARP on PF1, just activate the "persistent maintenance mode".

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

              @viragomann

              The way you suggested:

              PF1 went to backup status as expected and PF2 as master as expected.

              NOTES:

              • PF1 as master I sill cannot ping PF1 IP from DMZ;
              • PF2 as master DMZ is gone, can only ping PF1 IP, VIP and PF2 IP does not work;

              PF1 logs:
              771d47f4-f2fd-44c4-af11-14c88e8b663e-image.png

              PF2 logs:
              6dd59395-00a6-4216-8ca3-030a957e7c71-image.png

              V 2 Replies Last reply Reply Quote 0
              • V
                viragomann @ViniciusBr
                last edited by

                @viniciusbr
                Just to be sure, is the promiscuous mode enabled on ESXi?

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

                  @viragomann

                  Yes:

                  PF1:
                  517d4e12-f474-4b17-81ea-09cb7ae616e2-image.png

                  PF2:
                  938a8ee7-39bc-4b57-bc43-9599cc14df68-image.png

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

                    @viniciusbr
                    Check out the ARP entry in the PF2 log where you've hidden the IP.
                    It shows the IP moving from a CARP MAC to an physical MAC, when PF2 takes over. That seems strange to me.
                    Possibly the virtual IP has the wrong type or something else is miss-configured on that interface.

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

                      @viragomann said in HA strange behaviour, problems on passive box:

                      y the virtual IP has the wrong type or something else is miss-configured on that interfa

                      I am investigating this, but that one is a public IP, which as far as I understand I am not having issues with.

                      DMZ is still the problem.

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

                        Here are the virtual IPs:

                        PF1:
                        b3815f0c-3f1c-499e-9d01-468618d6eb49-image.png

                        PF2:
                        04a142fd-45c0-4b51-8e93-17d14805ecc4-image.png

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

                          Now the basic questions:

                          • why from LAN I can ping both PF1 and VIP but NOT PF2? (DMZ IPs)
                            9003c799-9ad2-4ddf-8c65-22c3f039d6a4-image.png

                          Looking at the firewall, it is allowed:
                          0caad4a2-6325-4eeb-85cc-4c6a420df275-image.png

                          • same issue from DMZ:
                            5f88f1e9-8364-44a7-b378-6ffeeda9cbaf-image.png

                          28ab73c7-589d-4884-aa6a-7c5a2d6e8358-image.png

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

                            I was able to find the root cause of the issue:

                            Nothing to do with pfsense: vmware vs switch port access/trunk modes misconfiguration.

                            Thanks for the help!

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

                              @viniciusbr
                              Thanks for coming back with clarification.

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

                                @viragomann Thanks for your help!

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