Multiple OpenVPN remotes: failover list, not link bonding

Two remote lines in one profile look like a second lane; they are a second attempt. When the first endpoint stops answering, the client moves on and the session gets no wider. Call the list failover early, or you will tune the wrong dial.

What a remote list buys you

Treat the profile as an ordered set of attempts, not a pool of capacity. Each entry gets a turn at bringing up the tunnel, and the session lives on whichever one answered. A longer list improves your odds of connecting, not the size of the pipe.

Real aggregation is a different machine. Splitting one flow across several paths takes software at both ends to divide and reassemble the traffic in order.

A vendor promising faster tunnels from more servers is selling that second model, not a longer list. If the client only tries endpoints in turn, five entries change your odds and nothing else. Watch an outage: the session drops and returns somewhere else, which the log shows as a new endpoint, never a wider pipe.

Blocks that keep settings with one endpoint

A plain remote line carries an address, and sometimes a port and protocol. When an endpoint needs a proxy, or a transport the rest of the file does not use, wrap those settings in a connection block that keeps them with it. Inline blocks also work in one .ovpn file, which is how most profiles ship.

Anything outside a block acts as the default for entries that do not override it. That is why one built block and four plain remotes behave in ways the address list cannot explain.

Deleting a block you do not recognise is not cosmetic. The endpoint it belonged to falls back to the file's defaults, which may be a different transport than the one it listens on. Remove the wrong wrapper and one entry fails while the rest work, so it looks like a bad server rather than a broken profile. Read each remote with its transport, port and proxy before editing.

Retry order and the cost of remote-random

Order matters because every dead entry costs time before the next attempt. Put the endpoint you want first and treat the rest as ranked fallbacks.

remote-random shuffles the starting order, which spreads load across equivalent servers and backfires when one endpoint is clearly primary. Either way, log the endpoint the client selected; the profile name says nothing when a connection feels slow. Grepping the link line from a verbose log shows where the session landed.

Mixing operators breaks the trust statement

A profile is also a claim about identity: these addresses are the service you meant to reach, and the pinned certificate belongs to it. Dropping free public servers into that file breaks the claim: their certificates and yours describe different services. The usual outcome is an identity failure, or credentials offered to a host outside your provider's network. Keep alternatives inside the set your operator distributes, with matching credentials and trust material.

If you need endpoints from two providers, that is routing, not a profile edit. Answer it above the tunnel, where you can say which traffic takes which path.

Testing each entry instead of assuming

After an approved profile update, connect to each required endpoint on purpose and confirm which transport came up. A verbose run makes that visible. Start openvpn --config office.ovpn --verb 4 and read the link line for the address you expected. Then check the resources behind the tunnel; an entry can complete the handshake and still route you nowhere.

Failover needs its own test rather than a hope. Block the first endpoint in a lab, start the client, and time how long it takes to move on. A long list behind a slow first entry is worse than a short one that starts well.

Re-check the list whenever the operator changes it. An imported set is useful only while its entries exist and speak the transport your blocks describe. The OpenVPN 2.6 manual covers the remote, connection and random-order directives here, and it is the version to check when syntax is in doubt.