Home and Office Subnets Collide Over a VPN: Three Fixes

Your client reports connected and the tunnel is up, yet the office file server answers from somewhere in the kitchen. Both ends usually run 192.168.1.0/24 because that is what consumer routers ship with, and no route resolves an ambiguity that exists on both sides at once. The failure can look like a broken tunnel or a broken server, and it is neither. Identify which collision you have before touching a configuration, because the kinds have different fixes and only one of them is about routing.

A connected route beats anything you push

A host calls an address local whenever a connected route covers it. On a laptop whose own interface is 192.168.1.20/24, the address 192.168.1.50 is a neighbour, so the packet leaves through the home interface and never reaches the tunnel.

Pushing a route for the office prefix changes nothing, because that prefix already exists as a directly connected network. The operating system keeps answering from the connected entry, and it is consulted before the tunnel is asked anything. You can watch the order for yourself: ip route get 192.168.1.50 names the home interface, not the tunnel. The far end mirrors the problem, since the office router also believes the laptop's home range belongs to it.

Quiet collisions beyond the obvious one

Not every instance is a routing decision. A home DHCP lease can land on exactly the address the office server holds, and then the client talks to itself while the tunnel carries nothing.

Names collide the same way. Two machines sharing a computer name break name-based tools even when every packet is routed correctly, and a hosts entry pointing at the office address fails when the local machine already owns that name, because local resolution wins. Rename the local machine or use the fully qualified name instead of editing hosts.

Hypervisors add a third case. A host-only adapter usually sits on 192.168.56.0/24, which can collide with a corporate range nobody remembers is in use.

Renumber the side you own

Renumbering removes the ambiguity instead of dodging it, and in a home office that is the side you own. Pick something that will not appear anywhere else, and list every device holding a static address before you touch the router.

10.0.0.0/8 and 172.16.0.0/12 are the usual candidates. The firmware defaults, 192.168.0.0/24 and 192.168.1.0/24, are exactly what to leave.

Renumbering the office is rarely on the table, and a home renumber costs an evening of reconnecting printers and plugs. It is still cheaper than a workaround repeated on every laptop in the company.

Publish a range that cannot collide

Where the office range has to stay, make the tunnel side harder to collide with. Carving the client pool as a small prefix rather than borrowing a whole /24 gives a specific route instead of a broad one.

If the gateway can translate, publish the office subnet under an alias range, so the client's destination cannot fall inside its own LAN. A site-to-site design can give each site its own alias, which keeps two customers with identical numbering distinguishable.

Translation is not free. It has to run in both directions and cover the source address and the destination, and applications that write addresses into their own payloads will ignore it completely. That makes it the answer when renumbering is impossible and the client count is small.

Choose by what you can change

One or two laptops at home: renumber the home LAN. A managed office that cannot renumber: alias translation at the gateway. Repeated numbering across customer sites: per-site aliases, planned once. When only name-based tools fail, treat it as a name collision rather than a routing fault.

Whichever you pick, test against an address that lives only on the far side. Pinging your own router says nothing about which network replied.