Home and Office Both Use 192.168.1.x: What Now?

Work through four checks: which address the name resolves to, which prefix the local network uses, which route the kernel selects for that destination, and what answers at the far end. The VPN login is not one of them, because it completes regardless of which network wins. Do the checks in order and the overlap becomes visible at the second step rather than the fourth.

A successful login says the tunnel is up; it says nothing about where a particular address points.

One Address, Two Machines

A host chooses a path from its routing table and policy rules, using the destination address. Nothing tells it that a request to 192.168.1.20 hop is meant for the office server rather than for a device in the next room. With both networks on the same private range, the most specific route wins and everything else depends on which entry a reconnect happened to install. Nothing in the address itself carries the distinction.

ip route get 192.168.1.20

That lookup names the interface and next hop the kernel chose, which is the second check in the list. Compare the local and remote prefixes before doing anything else. If the local LAN is 192.168.1.0/24 and the remote site is also 192.168.1.0/24, the overlap is the finding, and no client option repairs it.

Renumber the Side You Control

A personal router is usually the easier side to move. Pick a range that does not collide with the remote networks you actually use, and note that 10.x.x.x is not automatically free either, since plenty of sites use it. Plan the change: DHCP leases, reserved addresses, printer queues and anything with a hard-coded address all need attention. Do the renumbering in a window when you can recover the router without the VPN.

Check the remote prefix list first, not afterwards. Choosing a new range that collides with a different office site produces the same problem with more work invested.

When Neither Side Can Change

If neither network can be renumbered, the remaining options live on the server. A gateway can translate a remote network into a different subnet for VPN clients, using policy-based NAT or a bidirectional variant, so the client sees a unique address. That is a gateway design rather than a switch every desktop client provides, and it changes which address users type and which names must match. A route copied from a forum cannot distinguish two identical destinations.

Private address ranges remain private; the problem is reuse, not the ranges themselves.

Prove Which Machine Answered

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

After any change, test the office resource and the local devices together. If a familiar home device answers where the office server should be, or the TLS certificate names the wrong host, stop and identify the destination before continuing. Getting an answer from that address does not establish which machine sent it. Checking the certificate subject is one of the few reliable signals available at that point.

Do not replace office private addresses with arbitrary public ones you do not control. That trades an overlap for a routing and ownership problem that is worse and harder to explain.

Record the local prefix, the remote prefix and the change that resolved it. The next overlap will look different but follow the same pattern.