Three kinds of OpenVPN failover on pfSense, three mechanisms

"OpenVPN failover" on pfSense covers at least three unrelated designs, and each one needs a different mechanism. Keeping a tunnel alive across a backup internet link, reconnecting to a different server, and steering LAN traffic into another established tunnel are not variations of one feature. Pick the failure you are defending against before you build a gateway group. The group that fixes one of them does nothing for the other two.

Name the failure before you build a group

Write the sentence you want to be true during an outage. "The tunnel reconnects over the backup WAN" and "the branch keeps reaching the application through the other tunnel" are different sentences. Only the first one is about the transport.

Then match it to a mechanism. Local WAN loss is an interface-selection problem, a dead remote endpoint is a connection-list problem, and an unusable path inside an established tunnel is a routing and policy problem.

Local WAN: move the transport

For a pfSense OpenVPN client, the supported multi-WAN arrangement selects an appropriate gateway group as the interface the client binds to. That is what lets the outer connection leave over the backup link when the primary fails. It does not by itself change how the inner traffic is routed.

The server side of the same design is separate. An OpenVPN server that should be reachable over several public addresses needs a listener and ingress policy for each of those entries, not just a client that can dial out over two links. One working public entry is not evidence that the second one is configured.

A policy-routing rule for forwarded LAN packets is not the setting that moves a locally generated VPN transport connection. Those are two different lookups, and changing one does not change the other.

Remote endpoint: a different server

An alternative remote is a connection-list feature. The client tries the next entry when the current one does not answer, which is useful when a specific host is down rather than when your own uplink is. The two failures look similar from a user's desk and need different fixes.

Each candidate has to be a real substitute: compatible authentication, compatible client policy and access to the same private resources. A second hostname that resolves to the same failed infrastructure is not a backup. A server without the required route is not one either, however healthy its handshake looks.

This mechanism also does not make two tunnels forward at once. It replaces one connection with another, sequentially, and the gap between them is visible to whatever was running.

Tunnel path: choose another exit

When two tunnels are already up and you want traffic to use the healthier one, the mechanism is an assigned VPN interface with its own gateway, plus an explicit policy rule that sends the right traffic to it. A gateway group over those assigned interfaces can express priority and monitoring.

That design is about selection, not recovery. Moving new connections to the second tunnel says nothing about sessions already established on the first, and nothing about whether the far side will accept the new source address. Treating it as a recovery mechanism is how expectations get set too high.

If the requirement is that existing sessions survive, say so explicitly. Most implementations do not migrate a live flow between tunnels, and designing as if they do produces a failover that looks correct in a diagram and drops every open connection in practice.

Monitors, NAT, and the fail-closed rule

A monitor should test something the tunnel is meant to deliver. A target that answers from the tunnel peer but not from the application network beyond it will report healthy while users see nothing. An unreachable diagnostic target will report dead while the path is fine. Choose the address deliberately and confirm it is reachable only through the intended tunnel.

Check outbound NAT for both exits. A working translation on the primary does not describe the backup's source address, and the remote private network needs a return route that matches whichever source you present. Translation that is correct on one path can be silently wrong on the other.

Then decide what happens to traffic that must never use the WAN. pfSense has defined behaviour for rules whose selected gateway is down, and a later broad pass rule or a default route can undo your intent. Write the blocked outcome down as a requirement, then verify it by taking the path down.

Test loss and recovery separately, with traffic you are authorised to generate, and watch three things at once: the WAN that carries the outer connection, the tunnel that carries the application request, and the path the reply takes. A pair of green gateway indicators is not one of those three. The Netgate multi-WAN guide describes the transport binding and the exported client alternatives this depends on.