Where Does the Route Belong in OpenVPN: Client or Server?
A bare route in the server config changes the server, not the client. Choose the client file, a global push or a per-client push, and check what arrived.
You add route 10.60.0.0 255.255.255.0 to the server configuration, restart, reconnect a laptop, and the subnet is still unreachable from that laptop. The line was accepted, the service started cleanly, and nothing in the log looks wrong. What happened is that the route was installed on the machine you edited: the gateway now believes it can reach that prefix, while the client was never told anything. Placement is the whole question, and there are four places the same line can live.
The four locations and who receives each
A route can be added by the client's own configuration, offered to every client through a global push, offered to one client through a client-specific file, or written into the server's own routing context.
Those four cases use nearly identical syntax and produce completely different results. The first three affect what a client sends into the tunnel; the fourth affects how the server reaches a network, which is useful when the server itself needs a path and harmful when it is mistaken for distribution.
Decide which of the four you want before writing the line, then confirm the receiver.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Why the bare server route surprises people
The server configuration is where administrators look first, and a route directive there reads like a statement about the VPN network. It is not. OpenVPN treats it as a local route installation on the machine running the daemon, which is exactly the same kind of change you would make with ip route and then forget.
Distribution requires the route to be pushed, and pushing requires the client to pull. A client started with pulled options disabled ignores the offer entirely. Check both ends of that handshake before rewriting the server file, because the server log will not complain: from its side, the offer was sent. An accepted route also lands only at the next connect, never in the session you are already in.
Once you see the two as separate operations, the failure stops being mysterious: the server can reach the prefix, the client cannot, and both statements are true at the same time.
Per-client files and the identity they match
A client-specific file is named after the identity the server authenticated, which by default is the certificate's common name. A friendly connection name in a desktop client is not that value, and a mismatch produces a file that is never read.
Check the directory the server actually uses, then confirm the filename matches the authenticated identity exactly, including case.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Inside that file the route still has to be pushed, because the per-client context is a set of options applied to that client's session rather than a local routing table. A bare route there has the same problem as a bare route in the global file.
The client's own file and the tool that owns it
A route placed in the client's configuration is installed when that client connects and removed when it disconnects, which is the right lifecycle for a static destination.
If a network manager owns the profile, it may import those options once and then keep its own copy. Editing the downloaded file afterwards changes nothing, which is a common source of "the route is there but does not apply".
Check the active profile rather than the file you downloaded, and check the imported settings the manager displays. Then connect and ask the system which path a specific address uses, rather than assuming the tunnel won because the route existed in a text file.
Verify on the client, then check the return path
Ask the client's own routing table for the destination, not the server's. A lookup for a single host inside the prefix is enough to show the interface and next hop that will be used.
ip route get 10.60.0.10If the lookup points at the tunnel, distribution worked and the remaining problem is elsewhere. If it points at the default gateway, the route was not installed, was filtered by a client-side option, or belongs to a profile the client is not using.
Assume distribution worked and still nothing responds: then check forwarding on the gateway, the far side's return route, and any firewall between them. A route chooses a path, it does not grant access.