CARP topology and hardware planning
OPNsense CARP Hardware Guide: Interfaces, Switches & pfSync
CARP makes a shared IP address follow the active OPNsense firewall, but the reliability of that move depends on ordinary hardware details: both nodes need Layer-2 reachability on every protected network, interface assignments must line up, adjacent switches must learn the virtual MAC correctly, and the WAN provider must permit the chosen addressing model. CARP is therefore a topology problem before it is a checkbox.
Quick answer
Give every protected network two node addresses plus the shared service address
For a conventional two-node design, each firewall has its own static address on a CARP-enabled network and the pair exposes a shared virtual IP used by clients or upstream routing. Keep a separate pfSync path when practical. Verify the exact subnet, VHID plan, switch VLAN and ISP handoff before creating addresses; a working LAN CARP design does not automatically mean the WAN side can be built the same way.
Live Amazon hardware
Hardware commonly used around CARP pairs
The catalogue surfaces multi-port firewall appliances, managed switches and Intel PCIe NICs. It does not claim that a switch or ISP will support a specific CARP design solely because the product has enough ports.
Buying decision
Stable CARP starts with predictable interfaces and switching
Choose hardware that gives the two firewalls the same port roles and driver layout, then build switch paths that preserve the required Layer-2 domains. Extra public addresses should not be treated as independent CARP groups by default; OPNsense documents IP aliases on an existing CARP VIP for common cases. This keeps the topology understandable and reduces needless virtual-MAC churn.
Interactive planner
OPNsense CARP Topology Planner
Estimate the number of routed CARP networks and flag common switch, sync and WAN-design dependencies.
The planner counts logical routed networks, not the total number of IP aliases. Verify actual VHIDs, subnet masks, IPv6 behavior and provider requirements in the current OPNsense documentation.
Compatibility checkpoints
CARP topology checkpoints
Node addressing
Each firewall needs its own reachable address on protected networks in addition to the shared CARP virtual address.
Layer-2 continuity
Both nodes must remain in the correct VLAN/broadcast domain so CARP advertisements and virtual-MAC movement can work.
State synchronization
CARP takeover and pfSync state replication are separate; reserve and test the pfSync path independently.
WAN feasibility
Confirm the ISP handoff can support both firewalls and the proposed shared address before treating WAN CARP like LAN CARP.
Separate node addresses from service addresses
A CARP pair has more addresses than a single firewall because each node must remain individually reachable while the shared virtual address represents the service. This distinction matters for monitoring, configuration synchronization and troubleshooting. Administrators should be able to open each firewall directly even when it is in BACKUP state, while clients normally use the CARP VIP as gateway or DNS target. Label node addresses and VIPs clearly in documentation so a maintenance engineer does not accidentally point a service at the primary node address and silently bypass failover.
Keep interface assignments identical
OPNsense warns that interface assignments on both systems must match. A LAN mapped to one physical interface on the primary and a different logical role on the backup can lead to mixed MASTER/BACKUP behavior and confusing address placement. Use the same port labels, VLAN parent interfaces and driver families when possible. During commissioning, compare interface overview screens side by side. Hardware symmetry is valuable here because it turns a conceptual diagram into the same physical wiring pattern on both devices, reducing mistakes during replacement or emergency cable moves.
Understand CARP advertisements and VHIDs
CARP uses a Virtual Host ID to identify a virtual interface group and advertisement priority to determine which peer is MASTER. Do not reuse VHIDs casually across unrelated Layer-2 domains without understanding the effect, and keep a simple allocation record as the network grows. The virtual password, advertisement settings and subnet mask need to agree between peers. OPNsense guidance also recommends using the same subnet mask for a CARP VIP as its parent interface; configuration shortcuts that appear to pass traffic can break dependent services such as DHCP failover.
Use IP aliases for additional public addresses when appropriate
A block of routed or directly connected public addresses does not necessarily require a new CARP VIP and VHID for every address. OPNsense documents the use of IP Alias virtual addresses tied to a CARP VIP for additional addresses in common IPv4 setups. This reduces the number of CARP groups and keeps failover behavior easier to observe. The exact provider routing model still matters, so distinguish addresses that must participate in ARP/CARP on the WAN from addresses routed toward an existing shared gateway.
Outbound NAT should follow the shared identity
If internal traffic is translated to the primary firewall node address, sessions can break when the backup takes over because the external source identity changes unexpectedly. In a conventional CARP design, OPNsense documentation shows outbound NAT using the WAN CARP VIP. The same principle applies to services that should remain available across failover: bind or advertise the shared address rather than a node-specific one where the service supports it. Audit DNS, DHCP gateway options, VPN listeners and monitoring probes for accidental node-address dependencies.
pfSync is not optional just because CARP works
CARP can move the gateway address while existing TCP sessions still reset if the backup does not know their states. pfSync is the component that replicates those firewall states. OPNsense highly advises a dedicated interface for state synchronization. A direct cable can eliminate a switch dependency for a two-node pair, while a dedicated VLAN can be easier in larger physical layouts. In either case, verify the sync path under load and during failure. A state table that quietly stopped replicating may not become visible until the worst possible moment.
Switch behavior deserves explicit validation
Managed switches can implement MAC security, flap detection, storm control, IGMP behavior or stacking logic that changes how quickly a CARP virtual MAC moves between ports. OPNsense CARP documentation calls out switch infrastructure and configuration as a troubleshooting area. Do not rely solely on standards labels. Trigger a failover while capturing switch MAC-table changes and measuring client recovery. If two switches are used, verify both firewalls can see all required VLANs and that the virtual MAC is relearned on the surviving path after a switch loss.
Preemption is an operational policy choice
When the original primary returns, CARP can move MASTER status back according to preemption and advertisement behavior. Automatic return to the preferred node is convenient, but some operators prefer to stabilize the recovered system before moving traffic again. Decide this policy before an outage and document how planned maintenance differs from emergency recovery. The hardware plan should support either approach with independent management access and enough capacity on the active backup. Failback is another traffic transition to test, not simply the reversal of failover.
Split-brain testing belongs in commissioning
A split-brain condition occurs when both peers believe they should be MASTER, often because CARP advertisements cannot pass between them even though clients can reach both. That can create duplicate address ownership and unpredictable forwarding. Simulate the failure modes that could isolate peer communication, such as a VLAN filtering mistake or switch path loss, and verify monitoring alerts before a real outage. Physical design can reduce ambiguity by using simple Layer-2 paths, clear VLAN membership and dedicated synchronization, but only testing proves the network reacts as intended.
WAN CARP depends on the provider handoff
An ISP may supply a static subnet suitable for two node addresses and a shared VIP, or it may provide a single DHCP lease, PPPoE session or modem behavior that prevents direct CARP. Do not buy a pair of firewalls assuming the provider edge will act like an Ethernet lab switch. Ask how public addresses are delivered, whether multiple MAC addresses are allowed, how ARP is handled and what happens when the active firewall changes. When direct WAN CARP is impossible, upstream routing or a different multi-WAN design can still provide resilience.
Console and management paths reduce recovery risk
CARP failures are network failures, so an administrator may lose the very path normally used to fix them. Preserve a management method that does not depend on the shared VIP whenever possible: node-specific addresses, serial console, local keyboard/display or an out-of-band network. Label which switch ports belong to WAN, LAN and pfSync. During a fault, the ability to identify and reach each node independently is more valuable than another benchmark percentage, because it allows the operator to distinguish a firewall problem from a switch or addressing problem.
Prove failover with application traffic
A successful ping to the CARP VIP is only a basic test. Keep long-lived SSH, RDP, VoIP or other representative sessions active, remove the primary from service, and observe whether stateful connections survive. Test DNS and DHCP behavior, inbound NAT, VPN listeners and any public services bound to the shared identity. Then restore the primary and validate the chosen failback behavior. Record timings and unexpected resets. CARP is valuable because it can make a hardware failure routine, but only if the whole application path has been exercised.
Questions people ask
CARP hardware and topology questions
What hardware is required for OPNsense CARP?
At minimum, two OPNsense nodes with compatible interfaces and shared Layer-2 access to each protected network. A dedicated pfSync interface and managed switching are strongly recommended for a controlled design.
Does every CARP network need three addresses?
A typical two-node IPv4 CARP network uses one unique address per node plus one shared CARP VIP. Additional public addresses may use IP aliases depending on the design.
Do CARP nodes need the same NICs?
Matching NICs are not a pure CARP requirement, but OPNsense warns that different interface drivers can prevent pfSync state synchronization. Symmetry reduces that risk.
Can CARP work through a managed switch?
Yes, provided the switch preserves the required Layer-2 domain and handles CARP advertisements and virtual-MAC movement correctly. Test security and MAC-flap features.
Can I connect pfSync directly between firewalls?
Yes. A direct dedicated link is a common two-node approach and removes a switch dependency from the state-synchronization path.
Should clients use the CARP VIP as their gateway?
In the usual LAN design, yes. Using a node-specific address as the default gateway would bypass automatic gateway failover.
Does each extra public IP need another CARP VHID?
Not necessarily. OPNsense documents IP aliases on an existing CARP VIP for additional addresses in common scenarios.
Why can WAN CARP fail even when LAN CARP works?
ISP addressing, DHCP, PPP, modem restrictions or limits on multiple MAC addresses can prevent the WAN from supporting the same Layer-2 shared-address model.
What is split brain in CARP?
It is a condition where peers cannot correctly see each other and more than one node becomes MASTER for the same virtual service, creating duplicate ownership.
How should I test CARP?
Use real stateful sessions and test primary loss, restoration, switch behavior, pfSync health, NAT, DNS, DHCP and any VPN or inbound services that depend on the virtual addresses.
Official references and methodology
Verify the live topology and hardware before deployment
Cloudzat models CARP as a hardware-and-topology system rather than a generic two-firewall recipe. The page follows OPNsense documentation for CARP addresses, pfSync, configuration synchronization, interface symmetry and switch limitations. Amazon listings are used only to surface relevant hardware classes. Actual provider addressing, switch behavior and state continuity must be validated on the deployed network.
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.