# Document what pfSense XMLRPC synchronization deliberately leaves local

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

- Canonical URL: https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:33:33+00:00
- Modified: 2026-10-15T13:36:17+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, Networks & Infrastructure
- Reading time: 2 minutes

## 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.

## Article

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](https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html).

## 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](https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html). Reviewed October 15, 2026.

## Primary reference

- Name: Netgate — XMLRPC config sync
- Authority: docs.netgate.com
- URL: https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Document what pfSense XMLRPC synchronization deliberately leaves local,” DSE Security, https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.