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

    Pfsync not syncing states

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    15 Posts 5 Posters 4.5k 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.
    • J
      jsvg
      last edited by

      It's currently blank for both sides and it's not working :(

      1 Reply Last reply Reply Quote 0
      • dotdashD
        dotdash
        last edited by

        Verify you can ping each box from the other via the sync if. These both physical boxes with matched interfaces?

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          Having the wrong IP in there maybe got it into a weird state that removing didn't undo, try rebooting both of them.

          1 Reply Last reply Reply Quote 0
          • P
            podilarius
            last edited by

            @dotdash:

            Verify you can ping each box from the other via the sync if. These both physical boxes with matched interfaces?

            I had this problem too. Mine was the change that pfsense made to require matching interfaces on secondary to match primary unless you hack it with LAGG.
            As dotdash asks above.

            1 Reply Last reply Reply Quote 0
            • J
              jsvg
              last edited by

              The reboot didn't help, even though failover worked just fine (minus the state transfer). Still tons of packets arriving on the backup on the SYNC interface. If I disable sync on the master, the traffic dies off :( Makes me think the problem might be on the backup.

              I had this problem too. Mine was the change that pfsense made to require matching interfaces on secondary to match primary unless you hack it with
              LAGG.
              As dotdash asks above.

              AH that's the problem then. They are not matched. How do I "hack this with a LAGG"?

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                Well, create a lagg with a single NIC on both boxes. Silly? Yeah, 300%. NFC what's the benefit here. Never got a good explanation why's it good to have states tied to physical NIC names.

                1 Reply Last reply Reply Quote 0
                • J
                  jsvg
                  last edited by

                  Do I create a LAGG for the upstream ISP interfaces, or the SYNC interface?

                  1 Reply Last reply Reply Quote 0
                  • dotdashD
                    dotdash
                    last edited by

                    All the nics need to match, IIRC. So you'd have to LAGG any nics that weren't physically the same.

                    1 Reply Last reply Reply Quote 0
                    • P
                      podilarius
                      last edited by

                      @j@svg:

                      AH that's the problem then. They are not matched. How do I "hack this with a LAGG"?

                      If you search the forums, there was a setup type guide on doing this, but I cannot find it quickly to post in here.
                      I used it to setup the single interface lag. After that, it pretty much a standard carp setup.

                      1 Reply Last reply Reply Quote 0
                      • J
                        jsvg
                        last edited by

                        Thank you for the help guys! One of the instances is physical, the other is virtual. We were holding up moving to 100% virtualized because of this problem, but we're going to move forward since the interfaces will be named the same after the upgrade.

                        Cheers!

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