Copying the tunnel /32 will not route the office subnet
The address the VPN hands your adapter describes the link, not the destination. Add the resource prefix to the profile and leave the default alone.
The VPN connects, the interface shows an address with a thirty-two bit mask, and the office server stays unreachable. The next move is often to reuse that mask in a route, on the theory that the interface is describing what the tunnel can reach. It is not. That address describes the local end of a point-to-point link, and the destination you care about lives in a different prefix on the other side of it.
Two different things are being conflated: the address the tunnel gave you, and the network you want to reach through it.
Two addresses, two jobs
On a point-to-point tunnel, the client address is often a single host address because there is exactly one peer at the other end of the link. There is no shared segment and no ARP, so a mask that would look absurd on Ethernet is completely normal here.
The destination prefix is a fact about the office network, not about the tunnel. If you need one server, the route is a host route for that server. If you need the whole office subnet, the route is the subnet. Neither answer can be read off the interface, and choosing one because it appeared next to the tunnel address is how a working setup gets broken.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
That third row is where optimism becomes an outage. Routing an entire private range into a tunnel that only serves one site pushes unrelated traffic into a path that cannot deliver it, and the resulting failures look like a broken VPN rather than an over-broad route.
Choose the prefix from the requirement
Write the requirement as a sentence before touching a profile: which hosts must be reachable, and what is the narrowest prefix that covers them? A single server is a host route. A subnet is a subnet route. A range of subnets is a summary, and a summary is a promise that every address inside it is reachable, which is rarely true.
Then check the number against what the office actually uses. Copying a prefix out of a chat message without confirming it against the site's addressing plan is how a route ends up pointing at a subnet nobody owns.
Remember too that a route is a path, not a permission. The gateway still decides whether your client may use the destination, and a service can still refuse you. Installing the route correctly gets the packet there and answers nothing about authorization.
Append to the profile, never replace it
Routes in a NetworkManager profile are a multi-value property, and the difference between setting and appending is one character. Use the plus form to add an entry and keep everything already saved.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Without the plus, the assignment replaces the whole list. On a profile that already carries several prefixes, that silently deletes the ones that were working, and the symptom arrives later as a service that used to be reachable from this laptop.
Use the UUID rather than the name. Names are duplicated after restores, and the connection you edit may not be the one carrying your traffic. Check for an existing identical entry first, because appending a duplicate is untidy even when it is harmless.
The route property reference documents the destination, optional next hop, metric and attribute syntax for the installed version. Read it before adding a next hop, because whether one is required depends on the integration and the topology, and guessing it from the first address in an interface listing is not a method.
Default route and DNS are separate decisions
Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.
Automatic routes are the other thing not to disturb casually. Suppressing them to solve one missing entry can remove several working ones, and the person who suggested it was usually looking at a different profile with different pushes.
DNS has its own path and its own failures. A name that resolves to the right address over the wrong resolver, or a resolver that cannot answer for the private zone, will look like a routing problem while the route is perfect. Test the address and the name separately, then decide which layer actually failed.
Verify what was applied
A saved modification is not an applied one. Reconnect through the manager's supported lifecycle, then look at the actual route for the intended destination and at the policy rules that decide which table gets consulted.
If the prefix is there and the connection still fails, you have moved to a different problem: source address selection, a return route at the far end, or a service that refuses your client. Each of those is a better place to look than the profile you already corrected.