Active/passive versus active/active — the two HA topologies and when each is the right answer

A two-firewall deployment has two fundamentally different topologies. In active/passive, one firewall carries all traffic; the other sits idle, ready to take over. In active/active, both firewalls carry traffic at the same time, splitting the load between them. The two topologies look similar on a diagram — two boxes, two power supplies, two uplinks — but they have very different operational characteristics, very different failure models, and very different price tags. OPNsense supports both, but the practical answer for most deployments is active/passive. This lesson covers the two topologies, the trade-offs, and the patterns that decide which is the right answer.

Active/passive: one active, one standby

In active/passive HA, the primary firewall (the “master” or “active” node) carries all traffic. The secondary firewall (the “backup” or “passive” node) is running but not forwarding — its interfaces are up, its configuration is synchronised, but no traffic flows through it. The two firewalls exchange health advertisements (CARP, covered in Part XXVII); when the active node stops advertising, the passive node takes over.

The pattern:

   ISP ──── Primary ──── Switch ──── LAN
              │
              │ (CARP advertisements)
              │
            Backup (idle)

The active/passive model has several virtues:

• Simple state model. Only one node holds active state at any time. There is no question about which state belongs to which node — all state belongs to the active node.
• Simple configuration. Both nodes have the same configuration. The active node runs the show; the passive node is a copy. No load-balancing configuration, no traffic-splitting rules, no asymmetric routing to reason about.
• Predictable failover. When the primary fails, the secondary takes over the same addresses. The transition is one node replacing the other — same addresses, same configuration, same behaviour.
• Easier troubleshooting. The operator only has to reason about one active node at a time. The passive node is verified by failing over to it periodically.

The cost: the passive node is paid for but not used. Half the firewall hardware budget is sitting idle for 99% of the time. For a deployment where the operator cannot afford a second firewall, active/passive is not an option — but it is the right pattern when the budget allows.

Active/active: both carry traffic

In active/active HA, both firewalls carry traffic at the same time. Typically, the load is split — half the traffic goes through one node, half through the other — by a load balancer, by BGP, by source-based routing, or by service-based routing (some services on node A, some on node B).

The pattern:

   ISP ──── Primary ──── Switch ──── LAN (half the hosts)
              │           │
              │ (CARP)    │ (CARP)
              │           │
            Backup ──────┴────────── LAN (other half the hosts)

The active/active model has different virtues:

• Both nodes do useful work. The budget buys throughput, not redundancy. For a deployment where one node cannot keep up with the traffic, active/active doubles the throughput.
• Better resource utilisation. A passive node is idle CPUs and idle RAM. Active/active puts them to work.
• Lower latency under load. With both nodes carrying half the traffic, each node’s queue is shorter.

The cost is significant:

• State synchronisation is harder. When a packet hits node A and the return packet hits node B, the state must be on the node that sees the return. Either both nodes must synchronise state to each other in real time, or the load balancer must guarantee the same node sees both directions of every flow. Both are hard.
• Asymmetric routing is harder to debug. The operator has to reason about which node saw the SYN and which node saw the SYN-ACK. PF’s state table is per-node; an asymmetric flow across two nodes is two separate state entries that must agree.
• Split brain is more dangerous. When both nodes believe they are the active node for the same virtual IP, the network sees duplicate addresses. With active/passive, split brain is recoverable. With active/active, split brain may have already produced traffic loss before the operator notices.
• Configuration is doubled. Every rule that distinguishes by source or destination has to be replicated on both nodes. A change to one node must propagate to the other; a missed change produces two firewalls that disagree.

The OPNsense support model

OPNsense’s HA support is built around CARP (Common Address Redundancy Protocol, covered in Part XXVII). CARP itself is an active/passive protocol — one node is master for a given virtual IP, the other is backup. The active/active patterns are achieved by having each node be master for some virtual IPs and backup for others:

• Active/passive HA. Node A is master for all VIPs; node B is backup for all VIPs.
• Asymmetric active/active. Node A is master for VIPs serving LAN-A; node B is master for VIPs serving LAN-B. Each node is active for some traffic, passive for the rest. The two nodes do not share the same traffic stream — node A handles LAN-A’s outbound, node B handles LAN-B’s outbound, and the states do not cross.
• Symmetric active/active. Both nodes are masters for the same VIP at the same time, sharing the load. This is not a pattern CARP supports natively — it requires a load balancer that splits the traffic and guarantees same-node affinity, or state synchronisation between the two nodes for every flow.

The asymmetric active/active pattern is the OPNsense-friendly version of active/active. The two nodes carry different traffic streams; they do not need state synchronisation between them because no flow crosses nodes. The pattern works when the operator can partition the traffic by service or by subnet.

$ for i in igb0 igb1 igb2; do echo "== $i"; ifconfig $i | grep vhid; done

== igb0
      inet 198.51.100.10 netmask 0xffffff00 broadcast 198.51.100.255 vhid 2
      carp: BACKUP vhid 2 advbase 1 advskew 100
== igb1
      inet 192.0.2.10 netmask 0xffffff00 broadcast 192.0.2.255 vhid 1
      carp: MASTER vhid 1 advbase 1 advskew 0
== igb2
      inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 vhid 3
      carp: MASTER vhid 3 advbase 1 advskew 0

The decision matrix

Summary

• Active/passive: one node carries traffic, the other is a hot standby. Simple, predictable, the right default.
• Asymmetric active/active: each node is master for different VIPs (different subnets or services). The two streams do not cross, so state synchronisation is not needed.
• Symmetric active/active: both nodes are masters for the same VIP, sharing the load. Requires state synchronisation or a load balancer with affinity, and pays a constant tax on every packet.
• OPNsense supports active/passive and asymmetric active/active natively. Symmetric active/active is achievable but expensive.
• The trap to avoid: active/active without state sync or without LB affinity produces asymmetric flows and broken connections.