# Protect the pfSense pfsync network as a state-table trust boundary

> pfsync state exchange has no built-in authentication, so the network carrying it matters.

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

## What you need to know

pfsync state exchange has no built-in authentication, so the network carrying it matters.

## Potentially affected

This concerns pfSense HA state synchronization. It does not describe encryption or authentication provided by an independently designed network transport, nor does it replace configuration-sync or failover validation.

## DSE recommendation

DSE recommends inventorying every device and port that can reach the synchronization segment.

## Article

pfsync state exchange has no built-in authentication, so the network carrying it matters.

## Source facts

Netgate documents pfsync as the mechanism that exchanges firewall state information between pfSense HA nodes. Unlike XMLRPC configuration synchronization, state synchronization must be enabled on every participating node. The documentation warns that pfsync has no authentication and that a user with access to its network segment may manipulate the state table. A dedicated interface is recommended for security and performance. The Sync interface must explicitly permit the pfsync protocol; general permission for all traffic is broader than needed.

Source: [Netgate — State synchronization](https://docs.netgate.com/pfsense/en/latest/highavailability/pfsync.html).

## Applicability

This concerns pfSense HA state synchronization. It does not describe encryption or authentication provided by an independently designed network transport, nor does it replace configuration-sync or failover validation.

## DSE recommendation

DSE recommends inventorying every device and port that can reach the synchronization segment. Keep the trust boundary limited to the intended cluster nodes and approved administration dependencies. Review physical cabling, switch membership, and firewall rules together rather than treating the Sync label as evidence of isolation. Use narrowly scoped rules for the required protocol. Record state-policy and interface assumptions with the cluster documentation, and revisit them when replacing hardware or adding network connections near the synchronization path.

## Verification

Inspect both nodes’ state-sync settings and the relevant interface rules. From approved management evidence, confirm that unintended endpoints are not members of the synchronization segment. Exercise a controlled failover with a test connection and document continuity separately from the segment-isolation review.

## Official reference

[Netgate — State synchronization](https://docs.netgate.com/pfsense/en/latest/highavailability/pfsync.html). Reviewed October 15, 2026.

## Primary reference

- Name: Netgate — State synchronization
- Authority: docs.netgate.com
- URL: https://docs.netgate.com/pfsense/en/latest/highavailability/pfsync.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Protect the pfSense pfsync network as a state-table trust boundary,” DSE Security, https://update.dsesecurity.com/updates/pfsense-pfsync-isolated-sync-segment-trust/
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.