Does Every OpenVPN Peer Need a remote Line? Not Exactly

Two peer configurations are compared side by side, one has a remote line and the other does not, and the conclusion is that one of them is broken. That inference is wrong often enough to be worth unpacking. The directive describes where the first packet should be sent. It does not select whether the process acts as an initiating client or a waiting gateway, and it does not decide which side proves its identity to the other.

What remote actually specifies

A remote entry names a host, optionally a port and a transport, and optionally several such entries to try in order.

Its absence has a defined meaning rather than an undefined one: the process waits and does not act on packets from an address unless that peer authenticates. A gateway serving roaming users therefore has no reason to name any of them in advance.

Read the entry as an address relationship. Whether the far end is trusted is answered by certificates and the verification options, not by the fact that an address was written down.

Three arrangements decide the answer

A roaming client needs a destination, because it must initiate and it has no idea where the gateway is without one. A multi-client gateway needs no per-user destination, because clients arrive and authenticate. A deliberate two-peer link with known endpoints can have a destination on one side, both sides, or neither, depending on which side initiates.

Pasting a fixed client address into a general gateway is the mistake that follows from ignoring those categories. It works for the one peer whose address was recorded and misleads everyone else.

Nothing about the directive converts a configuration into a multi-client server, and nothing about its presence prevents a server role either. The OpenVPN 2.6 reference documents the optional arguments and the absent-remote behaviour separately, which is a hint about how independent they are.

Transport roles are a different axis

For TCP, one side waits and the other dials. Those are separate directives from the destination, and mixing them produces a pair that both wait or both dial.

There is also a TCP source-filter role, which is why the flat statement that a server may never contain remote is wrong.

For UDP there is no connection to establish, so both ends use the corresponding UDP transport and the directive only says where to aim. Address changes by an authenticated peer are handled by dedicated behaviour rather than by adding more entries. Getting the transport right is a precondition for the destination to mean anything, and confusing the two produces configurations that look plausible and never complete a handshake.

Why an absent remote is not an open door

A process without a destination still refuses traffic from peers that do not authenticate, which is the part people miss when they read the absent line as a listener open to anyone.

Authentication and destination are independent, and the first is the one that matters for trust.

The reverse error is more dangerous. A fixed source address can feel like an access control because it is specific and easy to check, but it proves nothing about who is on the other end. Keep certificate verification, and keep the identity checks that bind a certificate to its role. Replacing them with an address match trades a real control for an appearance of one.

Write down what the configuration assumes

For each side, record three things: how the first packet reaches the peer, which side can accept the transport, and what each side verifies about the other.

Those assumptions are the design. The directives are only their spelling.

If the two files differ, check whether they are expressing different assumptions rather than assuming one is wrong. A symmetric pair of files is neither necessary nor sufficient for a working tunnel, and the asymmetry is often the part that makes a topology work.