No Route Fixes a VPN Pool That Overlaps Your LAN

The app claims a healthy tunnel, and yet half the destinations you need never answer. The reflex is to add a route or lower a metric, and that reflex is the myth worth killing first. When the client's own LAN and the tunnel's pool claim the same prefix, the routing table is holding two incompatible facts, and neither a default nor a metric resolves them. The repair is an addressing decision, and no amount of route editing substitutes for it.

Why an Extra Route Cannot Split One Prefix

A route cannot separate two claims on one prefix, which is why the sensible move is to stop hunting for the right route line. The stack will not place an identical prefix ahead of the connected route, and a more specific entry does capture the address, only to make the local host that owns it unreachable. What looks like a routing problem is an addressing collision, and both repairs change addresses rather than routes. Test the claim on your own machine before accepting it.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Query the system about a single address and note which interface it names. Linux, macOS and Windows each answer that with a read-only lookup that reports the chosen interface and next hop without transmitting anything. When the answer points at the physical adapter while the tunnel is up, the kernel is treating the address as on-link rather than as something the tunnel could carry.

Put the provider-granted prefix beside the one the home router serves and compare them as strings. An exact match is the clear case, and a wider provider pool that contains the home subnet fails identically while being easier to miss. Two prefixes that merely look similar are not a collision, so write both down before changing anything.

Read the Pool the Client Actually Got

Read what the client received, not the provider's marketing page. Raise an OpenVPN client's log verbosity and the server-pushed routes appear in it, revealing the tunnel prefixes; elsewhere the pool shows up in the connection details or on the adapter itself. Ask the provider for the full list of private ranges it uses, because a single /24 today may be two tomorrow. Avoiding the common RFC 1918 blocks is not the same as avoiding the allocation you have actually been given.

A pool can also shrink or move between regions, so the list needs a date and an owner. Treat any provider answer older than your last plan change as a guess rather than a fact. Ask again before committing to a range, and keep the reply with the network notes so the next person inherits the evidence.

Renumbering Is the Fix You Can Make

If the VPN server is not yours to change, moving the home LAN is the only repair available, and that is the usual situation with a commercial provider. Pick a range outside the provider's pool and outside the ranges you might need later, and check it against every other site you reach over a tunnel. Expect a short outage and a longer tail of forgotten devices: one still holding the old address appears to work until it needs the gateway.

1. Inventory first: the router's own address, the DHCP scope, reservations, port forwards, and any device whose address was typed by hand.
2. Then change the router's LAN prefix and the DHCP scope together inside a maintenance window, and renew wired leases before wireless ones.
3. Next, correct the static addresses: printers, network storage, anything with a hard-coded gateway.
4. Finally, reconnect the VPN client and confirm the tunnel address no longer collides with the LAN.

Work through the addresses in that order rather than all at once, and keep the old range documented for a while so a stale device is recognisable instead of mysterious. A device that never renews announces itself by failing to reach the gateway, which is a far better clue than a support call. If the router hands out leases longer than a day, shorten them for the duration of the window.

What an Alias Can and Cannot Do

Where the server is yours, translating addresses on the client can expose the remote prefix inside a spare local range, so the same host answers at a second address. Community OpenVPN does this with client-nat, and that directive is specific to that client, absent from the commercial and mobile clients people usually compare it against. The arrangement needs a route that matches the translation, a free range for the alias, and a server willing to answer the client's untranslated address. None of it helps when the client belongs to a managed provider you cannot configure.

Once the change lands, reach a local host and a remote host first by address and then by name, noting the route the system picks each time. A name may still resolve into the old range, so addresses and names deserve independent checks. Restart one client and one server-side device if either stayed up through the change, because cached neighbour entries outlive the edit.

Write the prefixes you settled on where people actually look: the network notes, the router's own comment field, the onboarding page. Somebody will choose 192.168.1.0/24 again, and the collision will return with them.