@derelict Yeah, same conclusion i had. @viragomann Yup.

@viragomann Issue resolved with hostname override and haproxy listnening on LAN interface Thx

@skid9000 Perhaps some screenshots of the setup? Can you get it working without the VLANs and add those in after? I've not had occasion to set HA up with VLANs but have done so with aliases for other subnets on LAN.

Just for your info. We've now seen the issue on multiple installations (even different hardware and pfsense versions) and could solve it on every single system by moving the sync-vlan to a dedicated physical interface.

@viragomann i think it's that https://forum.netgate.com/topic/150505/xmlrpc-restore_config_section-error because my rule to NAT with CARP ip make the backup node not able to reach the gateway so as it explain on that like you sent Filter reload sees the down gateway and resets states, terminating the connection currently used for XMLRPC. it make sense Thanks you very much, i think you resolve my issue :)

@kayavila OK this is great info, thank you! I read your entire write up you linked to as well but I'm still trying to wrap my brain around it. Think I've got it figured out but wanted to pose an example. This particular one will be between different VLAN/subnets rather than with WAN as I personally don't ever allow those connections via the WAN. So in theory if you had VLAN1 and VLAN2 setup, and there was an any-any rule below a block "This Firewall" rule on VLAN1, and some device on VLAN1 tried to contact the LAN interface of VLAN2, due to state syncing this would be let through? Since the first node would see the connection to the VLAN2 IP and see that it's not in it's block list but matches the any-any rule, and then the state would sync to the secondary which wouldn't assess it's rules? If that is the case, I would imagine not having a rule on the primary node that allows access to any would solve the issue, but since some people do use an any rule for internet access it could pose a problem (though best practice is of course to use an alias for RFC1918 and explicitly allow the inverse of that).

@viragomann Thanks ! Went with the port forward + outbound option, NAT is working finally.

@starsandbars What questions do you have after reading this? https://docs.netgate.com/pfsense/en/latest/highavailability/index.html

@mrfrenchfry You can export the interface config from the secondary node: Diagnostics > Backup & Restore > Backup & Restore At Backup area select "Interfaces". Download the file. Then load it into a text editor and order the interfaces accordingly to the primary. Save the file and re-import it into the secondary.

More photos: [image: 1648852380286-20220201_181442-resized.jpg] [image: 1648852382954-20220131_180718-resized.jpg] [image: 1648852386758-20220201_181457-resized.jpg] [image: 1648852458418-20220119_165632-resized.jpg] [image: 1648852516449-20210929_162052-resized.jpg] [image: 1648852642104-20201214_141056_hdr-resized.jpg]

Sorry, it probably was only a temporary problem while the network reconfigured to the static IP. It now seems to work properly.

@skorpio The CARP alias skew is set in each alias: https://docs.netgate.com/pfsense/en/latest/recipes/high-availability.html#configuring-the-carp-virtual-ips "A primary node is typically set to 0 or 1, secondary nodes will be 100 or higher. This adjustment is handled automatically by XML-RPC synchronization."