OpenVPN Server and Client on One Host: Why Clients Drop

Add a client profile to a machine that already runs a VPN server and the original service is the first casualty. The new tunnel may never establish, or it may come up while the server's existing clients quietly stop hearing back. Two collisions produce both results: a tunnel pool that is already in use, and a default route installed by the new client half that covers the whole table. Neither produces an OpenVPN error message, which is why the failure gets read as a server problem.

One machine, two roles, and two incompatible answers about where replies should go.

Same Pool, Two Servers: Which One Wins

Every server instance needs a tunnel subnet of its own. Copying a line such as server 10.8.0.0 255.255.255.0 into the second configuration gives two instances the same prefix, and the outcome is either a refusal to start or a quiet contest in which clients of one server receive addresses the other also believes it owns. Different UDP ports and different device names do not help, because neither touches the address space. Change the second pool, and change it everywhere the routes mention it.

Enumerate what is live before editing: ip -4 addr show lists the tunnel devices, ss -lunp lists the listeners, and systemctl list-units names the units. One glance at the tunnel addresses settles whether the pools collide.

What the Client Profile Adds to the Table

The client half writes routes as soon as it connects. redirect-gateway def1 splits the default route into 0.0.0.0/1 plus 128.0.0.0/1, both routed through the new device, together with a host route to the far server that is deliberately pinned to the physical interface. That pin exists so the tunnel keeps a path for its own transport. Everything else, including the replies the local server owes its own clients, now follows the new default and leaves through the remote link.

So the second collision is not a broken tunnel. It is a working tunnel in the wrong place in the table.

Three Ways to Keep the Roles Apart

The least invasive fix keeps the default route out of the client profile: route-nopull plus explicit route lines for the remote prefixes, so the local table changes only where you asked. The next step is a policy rule that exempts the local tunnel subnet, letting replies to local clients leave on the interface they arrived on even while a default route exists. The most thorough is a separate network namespace for the client role, which removes the shared table entirely and costs a second routing context to maintain.

Whichever path you take, the exception must name the local tunnel subnet rather than the LAN. The reply the local server sends has a tunnel address as its destination, so a LAN-shaped exception never matches it.

Which of the Two Instances Is at Fault

Stop the client instance and retest the original clients. Immediate recovery means routing, not the server. Bring the client back and trace a single reply with ip route get supplied both a source and a destination address, which shows the path the kernel would choose, then watch the interface that packets really use with tcpdump -ni any port 1194. The server's status file, written every few seconds through the status directive, carries the connected client list and byte counters for both directions.

Read those counters against each other. Traffic that leaves and never comes back is a routing answer rather than a handshake problem.