Why copying the OpenVPN server config to a branch fails

Copying the working server configuration, swapping a couple of addresses, and calling it a branch profile usually produces a connection. That is the worst outcome, because the branch then runs with the wrong role, exposes material that should not leave the hub, and leaves a route association nobody remembers making. The connection hides three problems at once, and the tunnel comes up before anyone checks them.

Treating the branch as a peer with its own identity and network role is what makes the profile correct. The fix is not a better copy, and the rest of this page is about what a client should actually hold.

Two roles that look like one file

In TLS mode the two peers have complementary jobs. One side listens, holds the server certificate and key, and decides which clients may connect. The other side initiates, verifies the listener, and presents its own identity.

A server file contains directives that make no sense on a client: a bind address and port to listen on, a pool of addresses to hand out, and often a push list for settings the clients should receive. Copying those to a branch produces a device that tries to be a listener and a client at the same time.

The private key is the part that matters most. A client must never carry the server's private key, and it does not need the CA's signing key either. A CA certificate is public trust material; the signing key belongs wherever certificates are issued.

What a branch profile must contain

A branch profile needs the remote endpoint and transport, the trusted server identity, the branch's own certificate and key, and the routes and DNS settings the branch actually requires. Nothing else is mandatory.

Keep the branch identity separate per site. Two branches sharing one certificate means revoking one disables the other, and the hub's logs cannot tell them apart. A per-site identity is what makes both the audit trail and the revocation story work.

Be careful with appliance workflows. pfSense's Client Export package produces profiles for eligible Remote Access contexts, and its server list only includes servers configured in a Remote Access mode. A site-to-site server of another mode does not appear, and that absence is information, not an invitation to copy the server's secrets.

If the appliance does not export the profile you need, use its documented site-to-site client workflow or build the profile from the installed release's supported example. Export a server backup to the branch only if the plan is to restore a server, which it is not. A backup also carries the hub's private material, so moving one to a branch is a key-handling decision, not a file transfer. Keep it on the hub and generate the client identity where certificates are issued.

The peer-to-network association is separate

A branch client that connects successfully still cannot pass traffic for its LAN until the hub knows that this peer owns that prefix. That association lives on the hub, keyed to the client's identity, and it is separate from the branch's own route toward the remote networks. Without it, the branch's hosts appear reachable in the tunnel's statistics and unreachable in practice. The hub log is the place to confirm whether the association was applied.

Adding a route on the hub's operating system is not the same thing as telling OpenVPN which client owns the prefix. Without the per-client association, the packet reaches the tunnel interface and is dropped because no peer claims the destination.

On the branch side, the corresponding need is a route toward the networks it should reach, plus a LAN router that knows how to return traffic to the branch. Server-side ownership and client-side destination routes are distinct objects, and a working tunnel only proves the first hop. Write both down in the branch's handover notes, because the next engineer will find only one of them.

Proving the branch is the peer you think

Verify identity before verifying traffic. The hub's log should show the branch's certificate common name, and the address the client received should match the pool or fixed assignment you intended. If the log shows a different name, the profile is carrying someone else's identity.

Then verify the association by sending one request from a branch host to a hub-side resource, and confirm it succeeds with the expected source address. Test a destination the branch must not reach and confirm it fails, because a permissive route that happens to work is not the same as a correct policy.

Finally, revoke the branch identity and confirm the connection fails while the hub's own certificate and other sites keep working. If revocation breaks the hub, roles and identities were shared somewhere, and that is the finding worth taking back to the design.

A finished branch is one with a documented identity, a client-only profile, a peer-to-network association on the hub, and a tested return path. Reversing text in a server file gives you none of those.