Should your OpenVPN client use nobind or a fixed port?

Two profiles that differ by a single line behave differently the moment a second client starts on the same host. One carries nobind and takes whatever local port the kernel hands out; the other reserves 1194, and the second instance dies with an address already in use. That line decides who picks the source port, which in turn decides whether the profile can coexist with anything else on the machine. Three questions settle it, and the first one answers most profiles before you reach the other two.

What nobind actually skips

By default the client binds a local socket before it dials, and the local port defaults to 1194 unless the profile says otherwise. nobind removes that reservation, so the stack allocates an unused port at connection time. It is an opt-out rather than a default, and a client without the line holds 1194, which is exactly why an unpinned second instance collides. Most shipped client profiles carry the directive for that reason, and a sample file doing something is not the same as the mechanism defaulting to it.

What does not change is the far side. The server still listens where the profile says it listens, and the destination port in the configuration is still the destination port. A dynamic source port changes the return address of your own socket and nothing about the server's.

It also hides nothing. Your public address is whatever the path translates it to, the packet still crosses the local network, and whoever runs that network still sees a flow. nobind is neither a privacy feature nor a firewall bypass.

Three conditions that decide it

One question decides the other two, so answer it before editing anything. If the peer dials out, the remaining questions only refine a decision that is already made. If it accepts inbound connections, no amount of local-port tuning makes it reachable.

Does this peer initiate the connection? If it dials out, a dynamic source port is harmless and usually preferable, because the reply follows the same flow back. If it waits for inbound connections, a dynamic port makes it unreachable unless something in front publishes the port. That one answer separates every client profile from every server profile.

Does the path filter on source port? A strict rule written for one known port forces an explicit local port, and the profile should record which rule it satisfies. Most networks filter on destination only, so this condition is rarer than the first. Where it does apply, it overrides the preference for a dynamic port.

Do several instances share the host? A single fixed port cannot serve two of them, and a restarted instance may find 1194 still in a closing state. Dynamic ports remove that conflict without changing anything else. If you cannot answer this one confidently, assume yes and let the kernel choose.

Where a pinned port is the right answer

Some networks filter on source port as well as destination, so an operator may have written a rule that only passes traffic from one known port. Pinning the local port is then correct, and the profile should carry a comment naming the rule it satisfies. Pinning for symmetry with the server port is not a reason, because the two numbers have nothing to do with each other. If the pin exists only because a template had it, delete it.

Otherwise a pinned port buys trouble: two clients on one machine cannot both hold 1194, and the second one fails with an error that points at the port rather than at the profile. A container that restarts quickly hits the same wall. The repair is the directive the shipped profiles already contained.

Server and client are not symmetric

The OpenVPN 2.6 manual places nobind beside lport, which is the argument in one line: one option says the kernel chooses, the other says you do. A dynamic local port only works for the peer that dials, because the answering side cannot know the port in advance. That is why copying a client profile onto a server produces a listener nobody can reach.

On a multi-homed host the address is a separate decision from the port. Binding a specific local address and binding a specific port are two different settings, and a server with two uplinks usually pins both. A client that pins both has taken on the same rigidity for no benefit at all.

The summary is about roles rather than security: whoever dials can be flexible about its own source, and whoever answers cannot. Neither choice changes what the other end learns about your identity. That is also why the directive turns up in client samples and almost never in server ones.

Verify the port the kernel chose

After connecting, read the socket rather than the configuration, because the configuration states intent and the socket states what happened. The facts worth recording are the local port, the remote endpoint, and whether anything is still listening. On a Linux host all three are one command away.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

A client with nobind shows a high local port and the configured remote port, which is the expected shape. A server shows a listening socket on its configured port, and if that socket is missing the profile either is not a listener or failed to bind. When a flow exists but no packets come back, compare the chosen source port against any port filter on the path before editing the profile. Change one thing, reconnect, and read the socket again.