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

      Hi all,

      Need your wisdom here, kind of lost.

      I have 2 Pfsense in HA, both hosted on VMWARE 6.5 hosts. I think it used to work, but now for some reason I am having issues, it can be due to version 2.5.0 or something I changed on the recent past.

      Environment:
      lan:
      vip: 192.168.15.1
      pf1: 192.168.15.2
      pf2: 192.168.15.3

      dmz:
      vip: 10.10.30.1
      pf1: 10.10.30.2
      pf2: 10.10.30.3

      When PF1 is the master:

      • From LAN I can ping all 3 LAN IPs (VIP, pf1 and pf2)

      • From LAN I can ping DMZ VIP and PF1, but ping DMZ PF2 IP fails!

      • From DMZ I can ping DMZ VIP and PF1, but ping DMZ PF2 IP fails!

      When I disable CARP in pf1, pf2 becomes the master for all VIPs with no issues, pf1 becomes backup.

      When PF2 is the master:

      • lan still has network connectivity

      • DMZ loses connectivity right away;

      • From DMZ I cannot ping PF1, PF2 or VIP, it is like DMZ is gone

      • From LAN I can ping all 3 LAN IPs (VIP, pf1 and pf2)

      • From LAN I can ping DMZ VIP and PF2, but now ping DMZ PF1 IP fails! (seems that I can only ping the PF IP is it is the master);

      I have double checked VMWARE vswitch and port groups, they look fine to me.

      Any ideas are very welcome!

      1 Reply Last reply Reply Quote 0
      • 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.