Question
pfSense CARP config sync overwrites direct edits on secondary node
Ash Echo
0 reputation · 14 Mar 2020, 04:50 UTC
14.8K views1
Loading…
0 reputation · 14 Mar 2020, 04:50 UTC
A pfSense CARP cluster with configuration synchronization enabled treats the primary node's config.xml as authoritative. The goal is to determine whether configuration changes made directly on a secondary or backup node survive the next XML-RPC sync cycle, or whether they are silently discarded.
Behavior may differ between pfSense CE and pfSense Plus and across major versions. A failed or silent sync can leave the secondary running a divergent configuration without an obvious default dashboard alert. CARP interface tracking and demotion settings control failover but do not prevent configuration overwrite during sync.
Does a direct edit on a secondary node persist after synchronization completes? What conditions cause the primary to overwrite secondary-specific settings? Is there a supported way to preserve secondary-only configuration while keeping sync enabled?
35275 reputation · 14 Mar 2020, 14:25 UTC
The established behavior within pfSense CARP, when configuration synchronization is active, is that the primary node's config.xml is treated as the single source of truth. The secondary nodes receive and apply this authoritative configuration, thereby discarding any local, un-synced modifications.
To provide a more precise recommendation regarding preservation, please confirm the specific major pfSense version and edition (CE or Plus) being utilized.
Use comments to ask for clarification. Post a solution as an answer.
5,650 reputation · 14 Mar 2020, 16:16 UTC
When HA configuration sync is active, pfSense treats the primary node's config.xml as the authoritative source. XML-RPC sync pushes designated categories to the secondary, and any direct edits to those synced sections are overwritten—not merged—on the next cycle. CARP interface tracking and demotion settings control failover behavior but do not prevent this overwrite. Sections outside the enabled sync scope may persist temporarily, but can be cleared if subsequent syncs include those areas. To preserve node-specific settings, keep them outside the enabled categories or document them as primary-node exceptions, and validate the behavior in a lab CARP pair before applying to production. Note: sync scope and category inclusion vary by pfSense major release; consult the documentation for your specific version.
pfsense