OPNsense high availability hardware guide
OPNsense High Availability Hardware: CARP, pfSync & Redundancy
High availability is not created by buying a second firewall and copying the configuration. A dependable OPNsense pair needs compatible interface assignments, CARP-capable Layer-2 paths, state synchronization, a sensible configuration-sync workflow, adequate resources on each node, and power and switching that do not collapse both systems together. The hardware plan should therefore begin with failure domains and port roles rather than with CPU benchmark scores.
Quick answer
Each firewall must be capable of carrying the full production load
Design both nodes so either one can route, filter, inspect and terminate VPN traffic without depending on the failed peer. Reserve a dedicated pfSync path where practical, keep interface assignments and driver families aligned, and make sure the LAN and WAN switching allows the shared CARP addresses to move between nodes. Redundancy only works when the remaining node still has viable network and power paths.
Live Amazon hardware
Live hardware for two-node OPNsense HA
These listings emphasize multi-port firewall appliances, managed switches and PCIe NICs suitable for building repeatable interface layouts. Product cards show only evidence present in the listing; exact FreeBSD support, delivered NIC revision and firmware still require verification.
Buying decision
Buy symmetry where it lowers operational risk
Identical boxes are not an absolute protocol requirement, but matched NICs, interface counts and performance envelopes make CARP and pfSync easier to reason about. OPNsense specifically warns that differing network drivers and interface names can prevent state synchronization. For a production pair, the small savings from mismatched hardware rarely outweigh the extra testing and recovery complexity.
Interactive planner
OPNsense HA Hardware Planner
Check per-node port count, state-sync planning and basic symmetry before buying the second firewall.
The result is a topology screen. It does not prove CARP compatibility with an ISP, switch or hypervisor. Test actual state synchronization and link failure on the exact production interfaces.
Compatibility checkpoints
Hardware checkpoints for a failover pair
Per-node capacity
Size each firewall for the complete routed, VPN and IDS/IPS workload because failover removes the other node from the capacity pool.
Interface symmetry
Keep interface assignments and driver families consistent wherever possible so pfSync state records map cleanly between peers.
Dedicated synchronization
OPNsense recommends a dedicated interface for state synchronization to reduce congestion and state-injection exposure.
Redundant dependencies
Map switches, UPS units, ISP handoffs and power circuits; two firewalls cannot compensate for one failed dependency shared by both.
CARP is only the visible part of HA
CARP moves shared virtual IP addresses between peers, but a production design normally also needs pfSync for state tables and configuration synchronization for selected settings. Treat these as separate data paths with separate failure consequences. CARP can move an address even if state synchronization is broken, which may cause active sessions to reset. Configuration can also be synchronized incorrectly even while CARP behaves normally. During design and testing, verify each mechanism independently so a green CARP status is not mistaken for proof that the entire HA system is healthy.
Give both nodes the full workload budget
A failover pair should not depend on both CPUs being active to meet the normal traffic target. During an outage, one firewall may have to handle every routed flow, VPN tunnel, DNS query, IDS/IPS inspection and logging task. Size CPU, memory, NIC throughput and thermals per node for that condition. If the primary normally runs near saturation, failover will turn a hardware fault into a performance incident. Headroom also helps during updates, when one node may be intentionally offline while the remaining firewall carries production traffic alone.
Match interface assignments before chasing performance
OPNsense CARP guidance emphasizes identical interface assignments across peers and warns about differing network drivers because pfSync state records reference interface names. Matching appliances simplify this: WAN, LAN, DMZ and synchronization can be wired and labeled the same way on both chassis. When mixed hardware is unavoidable, verify the actual FreeBSD interface names and state synchronization behavior rather than assuming VLAN labels in the GUI hide driver differences. Consistency is operational value because it makes documentation, spares and emergency troubleshooting easier under pressure.
Reserve a dedicated pfSync path when practical
State synchronization can contain sensitive connection state and can also become noisy during busy periods. OPNsense recommends a dedicated interface for pfSync for security and performance reasons. A direct cable between the two firewalls can be simple for a small pair; a dedicated VLAN can be workable when physical ports are scarce, but then the synchronization traffic shares switch and trunk dependencies. Whatever topology is chosen, document the peer addresses, permit only required traffic, and verify that the path remains available when other links or switches are intentionally failed.
Configuration sync should flow in one direction
The primary should be the source of configuration synchronization. OPNsense explicitly cautions against configuring configuration sync on the backup toward the master, because reverse synchronization can overwrite the intended configuration. This has hardware consequences too: give administrators a clear way to identify the primary and backup devices, keep console access to both, and label cables and management addresses. Operational mistakes can defeat redundancy faster than component failures, so the design should make the safe workflow obvious during routine changes and emergency recovery.
Keep OPNsense versions compatible
Current OPNsense HA documentation provides a sync-compatibility control and advises keeping both nodes on the same version to avoid state synchronization issues. Plan upgrades as an availability exercise rather than updating both boxes simultaneously. Confirm the backup is healthy, update it according to the chosen workflow, verify services and CARP state, then move through the remaining node. Hardware should support this process with reliable console access and enough standalone capacity that one firewall can remain in service throughout maintenance.
The switch is part of the CARP system
CARP advertisements and virtual MAC movement depend on the adjacent Layer-2 infrastructure behaving as expected. Managed switches may have security, MAC-flap, multicast, storm-control or stacking behaviors that influence failover. Place both firewall interfaces in the required VLAN and verify the switch learns the active path after a takeover. If two switches are used for redundancy, confirm the VLAN exists end to end and that losing one switch does not isolate the active firewall. Switch redundancy that has never been tested can be more complex than a well-understood single-switch design.
WAN addressing can be the limiting factor
Private LAN CARP is usually straightforward compared with WAN failover. The ISP must allow the addressing and Layer-2 behavior required by the intended virtual IP design. A single DHCP lease, PPP session, locked modem MAC or provider CPE can prevent a textbook shared-WAN topology. Before buying duplicate WAN NICs or switches, document exactly how each circuit hands off service and whether both firewalls can be attached simultaneously. When the provider model cannot support CARP directly, separate multi-WAN or upstream redundancy strategies may be more appropriate.
Power redundancy must extend past the firewalls
Putting two nodes on one UPS protects them from a utility outage but keeps a common power dependency. Using two UPS units can improve resilience only if switches, modem/ONT equipment and cabling are also arranged so the surviving firewall has usable paths. Map which device plugs into which power source and which circuit feeds each UPS. For small networks, one UPS may be an acceptable tradeoff; for business continuity, a deliberate A/B power design with tested battery runtime provides a clearer failure model.
Physical and virtual HA have different traps
A virtual OPNsense pair can eliminate some hardware duplication, but both VMs on one hypervisor or one physical switch still share large failure domains. Mixing a physical node with a virtual node introduces interface-driver differences that OPNsense warns can affect pfSync. If virtualization is part of the design, document hypervisor placement, bridge or passthrough mapping, storage dependencies and boot order. The goal is not to maximize abstraction; it is to ensure that the backup remains reachable and capable when the specific component you expect to lose is actually unavailable.
Maintenance is one of the best reasons to build HA
A well-designed pair lets you patch, reboot or replace one node while the other carries traffic. Use that capability deliberately. Before maintenance, confirm CARP state, state synchronization, configuration currency, VPN services and monitoring. Move traffic in a controlled way, observe active sessions, then service the inactive node. This routine creates continuous confidence in the failover path. If the organization never exercises planned failover, an emergency takeover months later may reveal stale configuration, failed batteries, changed switch settings or cabling mistakes.
Test failures one dependency at a time
Commissioning should include controlled loss of the primary firewall, a relevant LAN link, the pfSync link, a WAN link, a switch path and power where safe. Observe CARP state, session continuity, DHCP/DNS reachability, VPN behavior and monitoring alerts. Restore the failed component and verify preemption/failback behaves according to policy. Record the results and exact recovery steps. The point is not to create chaos; it is to prove that the redundancy assumptions encoded in the cabling and configuration match the way the real network fails.
Questions people ask
High-availability hardware questions
Do OPNsense HA nodes need identical hardware?
Not strictly, but matching interface assignments, NIC drivers and performance classes reduces risk. OPNsense warns that differing network drivers can prevent pfSync state synchronization because interface names differ.
How many OPNsense firewalls are needed for HA?
Two nodes are the common minimum for a CARP failover pair. Each should be able to handle the full production workload alone.
Do I need a dedicated pfSync interface?
OPNsense strongly recommends a dedicated state-synchronization interface for security and performance. A shared path can work, but it adds congestion and dependency risk.
Does CARP synchronize firewall states?
No. CARP handles virtual-address failover. pfSync is the mechanism used to replicate connection states between peers.
Does CARP copy the OPNsense configuration?
No. OPNsense uses configuration synchronization separately, typically from the primary to the backup.
Should both nodes run the same OPNsense version?
Yes. Current OPNsense HA guidance advises keeping versions compatible and provides a sync-compatibility setting to reduce state-sync problems.
Can one switch support both HA nodes?
Yes, but that switch remains a single point of failure. Two switches can reduce that risk only if the Layer-2/VLAN design preserves connectivity after one switch fails.
Can I run one physical and one virtual HA node?
It is possible, but OPNsense warns that different network drivers/interface names can interfere with state synchronization. Test the exact mixed design carefully.
Will two firewalls fix a single-ISP outage?
No. Firewall redundancy and WAN redundancy are separate. A single ISP circuit, ONT or modem can still take internet service down.
What should I test before relying on HA?
Test firewall loss, state synchronization, configuration currency, LAN/WAN link failures, switching behavior and power recovery while observing real application sessions.
Official references and methodology
Verify the live topology and hardware before deployment
This guide separates CARP, pfSync and configuration synchronization because they solve different availability problems. Live hardware listings are screened for relevant appliance, switch and NIC classes, but Cloudzat does not infer driver compatibility or ISP support from marketplace copy. Official OPNsense HA and CARP documentation remains the authority for configuration behavior, and production failover must be proven with the actual switches, links and software versions.
- OPNsense High Availability documentation
- OPNsense Configure CARP guide
- OPNsense hardware sizing documentation
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Prices, firmware, UPS runtime, battery condition, NIC revisions, SSD variants, appliance configurations and seller terms can change. Verify the exact delivered hardware and current OPNsense documentation before production deployment.