Firewall high availability: what actually survives a failover

Two modes, and what each buys

The choice between active-passive and active-active is a choice about complexity rather than about capacity.

Active-passive

One member carries all traffic. The other holds synchronized configuration and session state, and takes over when the active member fails. Its behaviour under failure is straightforward to reason about, because the surviving unit was already carrying the full load before the failure occurred.

Troubleshooting is straightforward for the same reason. Traffic goes through one device, so the logs, the session table and the counters on that device describe the whole picture.

Active-active

Both members carry traffic while both are healthy. Implementations vary widely between platforms in how traffic is distributed and in what happens to a flow whose two directions land on different members.

Three costs come with it. Asymmetric flows require the members to coordinate, and the handling of that is where implementations differ most. Troubleshooting requires knowing which member handled a given flow before the logs make sense. And the failure case presents the survivor with the combined load, which is the arithmetic in the next section.

Active-active earns its complexity where a design needs traffic distributed across paths for reasons other than capacity. It rarely earns it as a way to buy capacity, because the survivor still has to carry everything.

The two modes and their general characteristics are common to every major enterprise firewall platform. What differs between vendors is the traffic distribution method in active-active, the handling of asymmetric flows, and which state is synchronized. Confirm all three against the administration guide for the platform and release being deployed. Checked 12 August 2026.

What survives a failover

A stateful pair synchronizes some state and not all of it.

This is the section that decides whether a failover is invisible to users or produces a wave of tickets. The behaviour varies by platform, by release, and by which synchronization options are enabled, so the right use of this table is as a checklist to confirm rather than as a statement of what your platform does.

The state categories and the general pattern of which synchronize are common across enterprise firewall platforms and are documented in each vendor's high availability guide. The specific behaviour for any one of these rows depends on the vendor, the release and the configuration, which is why the third column is written as a question rather than an answer. The tickets we associate with each row come from operating these pairs and are our observation rather than a vendor statement.

The two VPN rows are the ones customers notice first, because a tunnel that renegotiates and a client that reconnects are both visible to somebody. What each platform's client does on reconnection, and which IPsec parameters have to match for the tunnel to come back at all, is covered on the remote access page.

Redundancy is not capacity

The capacity that matters in a pair belongs to one member.

In active-passive this is obvious once stated. The standby carries no production traffic, so it adds no capacity. The requirement for the pair is the requirement for a single appliance.

In active-active it is less obvious and more consequential. Consider two members each running at sixty percent of their capacity, which reads as comfortable on any dashboard. When one fails, the survivor is presented with one hundred and twenty percent of its capacity. It is now saturated, and it is saturated at the exact moment the estate is depending on it.

The same arithmetic sets the ceiling for a healthy active-active pair. For the design to survive a single member failure, each member has to run below fifty percent of its own capacity, at which point the pair provides the throughput of one appliance and costs two.

Two further loads land on the survivor at the same moment.

• Session re-establishment. Everything that did not synchronize is rebuilt at once, which is a burst of new sessions per second rather than a gradual increase.
• Resynchronization when the failed member returns. The recovering unit has to be brought back into sync, and that work is performed by the member currently carrying production traffic.

The rule that follows is short. Size one appliance to carry the full requirement, with your headroom applied, then buy two. The sizing method treats the redundancy model as an explicit input for this reason.

The heartbeat and split brain

The heartbeat path is a single point of failure that most designs treat as infrastructure.

Members determine each other's health over a dedicated link. Losing that link does not tell a member that its peer has failed. It tells the member that its peer is unreachable, and those are different conditions with the same symptom.

Where a platform cannot distinguish them, both members may conclude the other has failed and both become active. Both then claim the same addresses. The resulting behaviour is worse than a plain outage, because traffic succeeds intermittently depending on which unit it reaches, and the cause is not visible from any single device.

Three design decisions address it.

• Redundant heartbeat paths on separate physical links. Two links that run through the same switch, the same patch panel or the same conduit are one link for this purpose.
• A secondary reachability check. Monitoring an external address gives a member a second opinion about whether it is the isolated one.
• A defined behaviour when isolated. Confirm what each member does when it loses the heartbeat and cannot reach its monitored target, and decide whether that behaviour is the one the customer wants.

Physical separation matters as much as the logical design. A pair mounted in one rack, on one power feed, patched through one switch, has consolidated most of its failure paths into things a second appliance does not protect against.

Upgrades, the everyday use

Most high-availability pairs perform more planned failovers than unplanned ones.

The routine reason to own a pair is the firmware upgrade. Upgrading one member, failing over to it, then upgrading the other allows the estate to be patched inside a shorter service interruption than a single appliance permits. Across a large estate, that difference decides how current the firmware stays, and firmware currency is a security outcome.

Three practical points shape how well this works.

Mixed-version operation is a transitional state. Platforms support running members on different releases during an upgrade, within defined limits. Outside that window, a mismatched pair may refuse to synchronize or may synchronize incompletely. Confirm the supported version skew before planning the sequence.

The rollback path is the part to plan. Upgrading the standby first means the untested release runs on the unit carrying nothing. Failing over is then the test, and failing back is the rollback. That sequence is what makes the pair worth owning.

The upgrade is when latent problems surface. A pair that has never failed over may have a synchronization fault that nobody has noticed, because nothing has depended on the standby. The first upgrade is frequently where that is discovered, and the discovery is easier to handle inside a change window than during an outage.

What it does not protect against

High availability addresses hardware failure of one appliance.

Set against the incidents that actually take a firewall offline, that is a narrow scope. Anything that affects both members equally passes straight through the design, and configuration is synchronized by definition.

This table follows from what a high-availability pair synchronizes rather than from any vendor claim, and applies on every platform. It is worth putting in front of a customer who has bought a pair and believes they have bought continuity, because the gap between those two things is where the next incident review starts.

The point to make to a customer is not that the pair was a poor purchase. It is that a pair answers one question, and the remaining questions have their own answers, most of which are operational rather than capital.

Testing the failover

An untested failover is a design assumption.

Pairs that have never failed over accumulate faults silently. A synchronization option disabled during a troubleshooting session two years ago, an interface added to the active member and not the standby, a license that was never applied to the second unit. None of these are visible until the failover happens, and the failover happens at the worst time by definition.

Test it deliberately, on a schedule, with the customer's agreement.

1. Fail over inside a change window and leave it there. Running on the secondary for a full business day proves it can carry production, which a thirty second test does not.
2. Record what users noticed. The value of the test is the list of state categories that did not survive. That list becomes the runbook entry.
3. Verify the standby's licensing and connectivity separately. A standby that has never been active may never have proved it can reach the licensing service, the log collector or the management platform.
4. Fail back, and treat that as a second test. Failback is a distinct operation and it can fail on its own terms.

Attach the result to the customer's service record. A tested failover with a written record of what users experienced is worth considerably more at the next incident review than an assurance that the pair is configured correctly.