{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "item": { "id": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "slug": "pfsense-xmlrpc-sync-interface-local-settings-boundary", "url": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary.md", "json": "https://update.dsesecurity.com/api/v1/posts/pfsense-xmlrpc-sync-interface-local-settings-boundary/" }, "title": "Document what pfSense XMLRPC synchronization deliberately leaves local", "summary": "Synchronized firewall rules do not prove that both HA nodes have matching local configuration.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:33+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 262, "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.", "primary_source": { "name": "Netgate — XMLRPC config sync", "url": "https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html", "published_on": null, "authority": "docs.netgate.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

Source facts

\n

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.

\n

Source: Netgate — XMLRPC config sync.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official reference

\n

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

", "content_text": "Synchronized firewall rules do not prove that both HA nodes have matching local configuration.\nSource facts\npfSense 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.\nSource: Netgate — XMLRPC config sync.\nApplicability\nThis 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.\nDSE recommendation\nDSE 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.\nVerification\nApply 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.\nOfficial reference\nNetgate — XMLRPC config sync. Reviewed October 15, 2026.", "content_markdown": "Synchronized firewall rules do not prove that both HA nodes have matching local configuration.\n\n## Source facts\n\npfSense 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.\n\nSource: [Netgate — XMLRPC config sync](https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html).\n\n## Applicability\n\nThis 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nApply 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.\n\n## Official reference\n\n[Netgate — XMLRPC config sync](https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html). Reviewed October 15, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "url": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-15" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Document what pfSense XMLRPC synchronization deliberately leaves local", "item": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/#article", "identifier": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "url": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/", "headline": "Document what pfSense XMLRPC synchronization deliberately leaves local", "description": "Synchronized firewall rules do not prove that both HA nodes have matching local configuration.", "abstract": "Synchronized firewall rules do not prove that both HA nodes have matching local configuration.", "articleBody": "Synchronized firewall rules do not prove that both HA nodes have matching local configuration.\nSource facts\npfSense 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.\nSource: Netgate — XMLRPC config sync.\nApplicability\nThis 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.\nDSE recommendation\nDSE 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.\nVerification\nApply 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.\nOfficial reference\nNetgate — XMLRPC config sync. Reviewed October 15, 2026.", "datePublished": "2026-10-15T13:33:33+00:00", "dateModified": "2026-10-15T13:36:17+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/pfsense-xmlrpc-sync-interface-local-settings-boundary/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Document what pfSense XMLRPC synchronization deliberately leaves local" }, "articleSection": [ "Business Continuity", "Networks & Infrastructure" ], "keywords": [ "Business Continuity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 262, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Netgate — XMLRPC config sync", "url": "https://docs.netgate.com/pfsense/en/latest/highavailability/xmlrpc-sync.html" } } ] } }