End-to-end OPNsense redundancy build
How to Build a Redundant OPNsense Firewall: Hardware & Failover
A redundant firewall build is an availability system, not a two-box shopping list. The two OPNsense nodes must have compatible interfaces and enough performance to operate alone, but they also depend on switching, WAN handoffs, state synchronization, configuration discipline and power. A pair that shares one unprotected switch, one modem, one power strip and one undocumented configuration can still have almost all the same outage modes as a single firewall.
Quick answer
Build two complete nodes, then remove shared failure points in priority order
Start with two firewalls that can each carry the full production workload. Give them matching interface roles and a dedicated pfSync path where possible. Add CARP only on networks where the Layer-2 and addressing model supports it, then examine switches, WAN circuits and UPS power. Eliminate the dependencies whose failure would still disconnect both nodes before spending money on cosmetic symmetry or spare accessories.
Live Amazon hardware
Live hardware for redundant OPNsense builds
The catalogue brings together multi-port firewall appliances, UPS units and managed switches because a redundant build usually fails at the dependencies around the firewall before it fails for lack of CPU.
Buying decision
Redundancy should make maintenance boring
The strongest sign of a good design is that planned updates, reboots and hardware replacement can be performed with a documented traffic handoff and predictable recovery. If administrators are afraid to trigger failover during maintenance, the system is not yet proven. Build the runbook while the hardware is new, and keep node-specific management and configuration backups available even when the shared CARP addresses are unavailable.
Interactive planner
Redundant OPNsense Build Planner
Count node ports and flag common shared failure domains before you commit to the topology.
The planner highlights hardware single points of failure. It does not know whether the ISP, switch stack, VLAN design or power circuits are genuinely independent, so those dependencies still need a physical diagram and failure test.
Compatibility checkpoints
Redundancy checkpoints before buying duplicates
Full-capacity nodes
Either firewall should carry the complete production traffic, VPN and inspection workload without relying on the peer.
Shared dependencies
List switches, WAN handoffs, UPS units, circuits and management paths whose failure can still affect both nodes at once.
State and configuration
Use pfSync for state tables and a controlled primary-to-backup configuration workflow; they are separate from CARP address failover.
Recovery access
Keep node-specific management or console access plus off-device configuration backups so a broken shared network does not block repair.
Define the downtime target before duplicating hardware
A home lab that tolerates a five-minute manual cable move needs a different design from an office where voice, VPN and cloud applications should survive a firewall failure with minimal interruption. Write the availability target and the failure events you are trying to cover: firewall hardware, software update, ISP outage, switch failure or utility power loss. This prevents uncontrolled duplication. CARP addresses and dual firewalls address one set of events, while dual WAN, redundant switching and UPS power address other failure domains. The build should spend money where downtime would actually originate.
Choose two nodes that can each run production alone
Do not split the required performance budget across the pair. During failover or maintenance, only one firewall may be actively forwarding the traffic that matters. Size CPU, RAM, storage, NIC speed and cooling on a per-node basis using the workload from Sprint 5A: WAN speed, IDS/IPS, VPN and VLAN routing. Matched appliances make spares and interface mapping simple, but capacity is the non-negotiable requirement. If the backup is a weaker box, document the reduced-service mode rather than pretending it provides equivalent automatic failover.
Map port roles identically
Label physical interfaces consistently on both firewalls: WAN1, WAN2, LAN trunk, management and pfSync. OPNsense CARP guidance stresses identical interface assignments, and pfSync can be disrupted when driver/interface names differ. A matching port map makes a failed node easier to replace because the cable bundle has an obvious destination. If different appliance revisions are used, verify the actual FreeBSD interface names and link behavior in advance. Keep a printed or offline wiring diagram where it can be reached even when the network management system is unavailable.
Use CARP only where the network can support it
CARP is ideal for shared gateway addresses on Layer-2 networks that both nodes can reach, but it does not magically solve every upstream limitation. LAN VLANs usually fit the model cleanly. WANs may not if the ISP gives one dynamic lease, uses PPP, restricts MAC addresses or places the circuit behind carrier NAT. Build the shared-address plan from actual provider details. Where WAN CARP is not feasible, use the provider’s supported routing model or separate multi-WAN techniques instead of forcing a lab topology onto a commercial handoff.
Make pfSync a first-class link
State synchronization is what allows many established sessions to continue after a CARP takeover. Reserve a dedicated interface where practical, as OPNsense recommends, and treat its health as something to monitor. Direct cabling between two nearby nodes can remove a switch dependency, while a dedicated VLAN may be easier across separated racks. Protect the link from accidental reassignment and verify it under realistic state-table activity. If pfSync stops, the network may still look normal until failover occurs, so status checks should be part of routine maintenance.
Redundant switching must preserve the same VLANs
Two switches only improve availability when either surviving path still places the active firewall in the Layer-2 domains required by CARP and client traffic. This may require stacking, MLAG-like vendor features, carefully planned trunks or simply a small pair of independent access switches depending on the environment. Avoid adding complex switch redundancy that administrators do not understand. Test removal of each switch and watch MAC learning, CARP state and client reachability. A simple topology with known behavior is safer than an elaborate topology whose failure modes have never been rehearsed.
Separate WAN diversity from firewall diversity
A redundant firewall pair connected to one fiber ONT still loses internet when that circuit fails. If the business requirement includes provider outage, add an independent second WAN and decide whether it is failover, load balanced or reserved for critical traffic. Check whether both circuits enter the building through the same carrier infrastructure. Even when perfect provider diversity is impossible, documenting the common path makes the residual risk explicit. Protect both handoff devices with UPS power if they are expected to remain useful during a local utility interruption.
Design power as A/B paths when the requirement justifies it
Two firewalls on one UPS survive utility loss together but also fail together if that UPS electronics or battery system fails. Higher-availability deployments can place nodes on separate UPS units or circuits and distribute switch power supplies accordingly. The exact design depends on equipment capabilities and site wiring. At minimum, calculate the protected load and runtime for the path that must survive. Keep modems, ONTs and management switching in the power map. Redundant compute without redundant network power can create false confidence.
Preserve independent management and console access
During a CARP, switch or VLAN problem, shared management addresses may be unavailable. Keep node-specific addresses and a console method appropriate to the appliance, whether serial, local display or out-of-band management. Restrict and document this access rather than relying on hidden default paths. If the backup firewall is in another rack or room, confirm administrators can still reach it when the primary switch or management VLAN is down. Recovery design is part of redundancy because every automated system eventually reaches a failure it cannot repair by itself.
Keep spares targeted to long replacement times
Buying a third complete firewall is not always the best spare strategy. Identify components with long procurement times or known wear: power adapters, UPS batteries, fans, SSDs, DACs or specialized transceivers. A standardized two-node build can make one replacement appliance or a known compatible NIC much more valuable because configuration and cabling are repeatable. Store the spare with firmware and installation notes rather than an unlabeled box. If a replacement has different NIC drivers, test pfSync and interface assignment before calling it an equivalent hot spare.
Configuration backups protect against synchronized mistakes
HA can replicate configuration quickly, including a bad rule or route if the workflow is careless. Current OPNsense HA guidance deliberately emphasizes controlled updates and keeping the backup in a known-good state during maintenance. Maintain exported configuration backups off the firewalls and know how to reinstall a node from clean media. Before large changes, capture a restore point and confirm which node is authoritative. Redundancy should reduce hardware downtime without turning an operator mistake into a simultaneous configuration failure on both systems.
Turn planned maintenance into your recurring failover test
Use software updates and hardware cleaning as opportunities to prove the backup path. Check sync health, move traffic to the other node, observe key sessions, service the inactive firewall and return it to readiness. Periodically extend testing to switches, WAN paths and UPS behavior during a scheduled window. Record failures and refine the runbook. This turns HA from a feature configured once into an operational capability that remains current as switches, ISP circuits, software versions and staff change over time.
Questions people ask
Redundant OPNsense build questions
What do I need for a redundant OPNsense firewall?
Usually two full-capacity firewall nodes, CARP-capable Layer-2 paths, pfSync, controlled configuration synchronization, adequate switching, and power/WAN redundancy appropriate to the uptime target.
Should both OPNsense firewalls be identical?
Identical hardware is not mandatory, but matching NIC drivers, interface roles and capacity significantly simplify pfSync, cabling, spares and troubleshooting.
Do I need two switches?
Not for basic firewall HA, but one switch remains a common failure point. Two switches only help when the VLAN and uplink design keeps the surviving firewall connected after one switch fails.
Do I need two ISPs?
Only if provider outage is within the availability requirement. Firewall redundancy alone does not make a single WAN circuit redundant.
Should each firewall have its own UPS?
Separate UPS or power paths can reduce common power failures, but the correct design must include switches and ISP handoffs as well as the firewalls.
Can I use one stronger primary and a weaker backup?
You can, but the backup must still support the service level expected during failover. If it cannot, document the reduced capacity rather than calling the pair equivalent.
What is the best pfSync connection?
OPNsense recommends a dedicated interface. A direct link is simple for two nearby nodes; a dedicated switched VLAN can work when physical layout requires it.
What spare parts are useful?
Prioritize components that are hard to source or likely to wear, such as matching NICs, power supplies, SSDs, fans, UPS batteries and specialized network media.
Can a bad configuration take down both HA nodes?
Yes. Configuration synchronization does not distinguish good changes from bad ones, which is why controlled updates and off-device backups are still necessary.
How often should I test redundancy?
Use planned maintenance as a regular failover exercise and periodically test switch, WAN and power failures in a controlled window appropriate to the risk level.
Official references and methodology
Verify the live topology and hardware before deployment
Cloudzat evaluates redundancy by failure domain: node, interface, switch, WAN, power, storage and configuration. The guide follows OPNsense HA/CARP behavior and uses the live Amazon catalogue only to surface relevant classes of hardware. It does not claim a particular uptime percentage or treat duplicated firewalls as proof that the surrounding network is redundant.
- OPNsense High Availability documentation
- OPNsense Configure CARP guide
- OPNsense Multi WAN guide
- OPNsense Network UPS Tools guide
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.