Allow for lost sessions while pfSense HA nodes run incompatible state-sync versions

An HA upgrade can preserve failover capability while still interrupting established connections.

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

What you need to know

An HA upgrade can preserve failover capability while still interrupting established connections.

Potentially affected

This applies to redundant pfSense firewalls during major-version upgrades. The current release notes and upgrade guide take precedence over a generic sequence, especially for DHCP or hardware-specific changes.

DSE recommendation

DSE recommends writing the upgrade window around both service availability and session interruption.

An HA upgrade can preserve failover capability while still interrupting established connections.

Source facts

Netgate’s HA upgrade guide distinguishes failover from stateful failover. The pfsync protocol can change with the underlying FreeBSD version, leaving mixed-version nodes unable to synchronize states. In that situation, failover can still occur, but existing connections are dropped. The documented general sequence backs up both nodes, upgrades and checks the secondary, shifts service using persistent CARP maintenance mode on the primary, then upgrades the primary and tests again. Release-specific instructions and state-policy compatibility must also be reviewed.

Source: Netgate — Upgrading HA clusters.

Applicability

This applies to redundant pfSense firewalls during major-version upgrades. The current release notes and upgrade guide take precedence over a generic sequence, especially for DHCP or hardware-specific changes.

DSE recommendation

DSE recommends writing the upgrade window around both service availability and session interruption. Identify applications that cannot tolerate a reconnect and notify their owners before the role transition. Preserve separate backups for both nodes and verify the alternate node’s packages, services, and logs before moving traffic. Define the conditions for returning service to the original node if validation fails. Do not promise uninterrupted sessions merely because CARP still changes roles or because both nodes show healthy interfaces.

Verification

In a representative test or approved maintenance window, track a long-lived test connection across each role change and verify new connections separately. Record software versions and observed state synchronization. Recheck application behavior after the nodes return to the same supported version and intended primary role.

Official reference

Netgate — Upgrading HA clusters. Reviewed October 15, 2026.

Primary reference

Review the official source

Netgate — Upgrading HA clusters · 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