Document what pfSense XMLRPC synchronization deliberately leaves local

Synchronized firewall rules do not prove that both HA nodes have matching local configuration.

Resilient network core with engineered blue and gold data paths.
DSE visual intelligenceNetworks & infrastructureGuide · 2 min read
Executive summary

What you need to know

Synchronized firewall rules do not prove that both HA nodes have matching local configuration.

Potentially affected

This covers configuration synchronization in a two-node pfSense cluster. State synchronization and CARP role changes are separate functions, even when they share the same protected synchronization network.

DSE recommendation

DSE recommends maintaining a two-column HA checklist: settings intentionally synchronized and settings maintained locally on each node.

Synchronized firewall rules do not prove that both HA nodes have matching local configuration.

Source facts

pfSense XMLRPC synchronization copies supported configuration areas from the primary node to the secondary after changes. Netgate identifies interfaces and various installation-specific settings as areas that do not synchronize; most packages also require separate consideration. In a two-node cluster, XMLRPC settings should be enabled only on the primary. Both nodes must use the same GUI protocol and port, and their interface assignments must match exactly. Mismatched assignments can make synchronized rules appear on the wrong interface and can interfere with DHCP failover.

Source: Netgate — XMLRPC config sync.

Applicability

This covers configuration synchronization in a two-node pfSense cluster. State synchronization and CARP role changes are separate functions, even when they share the same protected synchronization network.

DSE recommendation

DSE recommends maintaining a two-column HA checklist: settings intentionally synchronized and settings maintained locally on each node. Record interface assignment identifiers, GUI transport, package-specific configuration, and any expected differences. Review that checklist after hardware replacement or interface changes. Use the documented dedicated synchronization privilege where appropriate and protect the synchronization path. Treat a successful rule copy as evidence for that configuration area only; do not infer that routing, interfaces, packages, or state handling have all been validated.

Verification

Apply an approved harmless test change to a supported configuration area and compare the nodes. Separately inspect local interface assignments and relevant package settings. Confirm that synchronization runs in the intended direction and that a local-only setting remains intentionally correct on both nodes.

Official reference

Netgate — XMLRPC config sync. Reviewed October 15, 2026.

Primary reference

Review the official source

Netgate — XMLRPC config sync · Verified October 15, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE