Don't Guess the Office Prefix From One Server Address

Start with the address you were given, then resist the urge to widen it into something that feels tidy. One server at 10.22.8.19 says nothing about whether the office owns 10.22.8.0/24, 10.22.0.0/16 or a handful of scattered /28s. Choosing 10.0.0.0/8 because the number starts with 10 captures home networks, container ranges and partner links you did not intend. The prefix is a boundary to be obtained, not derived.

A prefix length describes how many leading bits are significant; it does not describe who owns the range.

A Server Address Is Not a Network

A server, a subnet and a site are three different things. A single service might sit in a small dedicated subnet while the rest of the office occupies separate ranges, and a host route can be entirely appropriate for an intentionally single-address service. It stops being appropriate when the site redirects to another host, authenticates through a separate server, or changes address. Those dependencies are the actual requirement, and they are worth asking about before any prefix is installed.

A subnet calculator translates a known prefix into a mask, a range or a host list. It cannot infer an organisational boundary from one hostname, and treating its output as authority is how unrelated networks end up routed.

Ask for the Approved Prefixes

Get the destination ranges from whoever operates the VPN or the network. There may be several distinct prefixes and a separately located private DNS server, which is often forgotten until names fail. Record them as an approved list with an owner and a date, not as a range reconstructed from an example. If the list is long, that is information about the network rather than an invitation to summarise it into something broader.

A read-only route lookup on the Mac, aimed at the destination you care about, shows which path is in use right now. That is current behaviour, not an authorisation.

Check Overlap Before You Apply Anything

Compare the approved prefixes against every local range before applying them: home LAN, container bridges, virtual machine networks and any other VPN. A precise route to the office still cannot tell you which device at that address you meant when the same range also exists locally; the table has no such concept. Overlap produces symptoms that look like broken services rather than routing mistakes, and they are hard to diagnose after the fact.

Have the supported owner install the prefixes, through the client's own configuration or the server's pushed routes, so a reconnect restores them instead of relying on a command somebody typed once.

A Route Is Not Access

Routing a prefix into the tunnel does not grant access to the services inside it. The gateway must permit the traffic, the destination must accept it, and a return path must exist, and each can fail independently of the route. Test one intended service after the route is in place, then confirm an unrelated resource is still refused. A route that reaches a firewall is not the same as a working connection.

Document the prefix list, the overlap check and the owner together. When an address changes, those three are what the next person needs.

The prefix is an agreement about boundaries. Treat it that way and the route stops being a guess.