VPN and Home LAN Use the Same Subnet: Walk the Route First

You connect to the office VPN, the tray icon turns green, the intranet loads, and the printer two metres away stops answering. The share that worked this morning times out on the same machine, and nothing in any log mentions a printer. The reflex is DNS, because a name that does not resolve looks like a name that does not exist, but the address is the problem: two adapters now claim 192.168.1.0/24 and only one route can win that prefix. Walk it in this order and you will see which adapter took it before you change anything.

Start at the symptom, not at the tunnel

The tell is scope. If the intranet works and every local device fails, the tunnel is healthy and the local path is not. If local devices work and the intranet fails, the reverse. If everything works except one host, you are looking at a single address that exists on both sides.

Write down one local address and one remote address before touching a setting. "The printer" is not testable; 192.168.1.40 is. That one step prevents the most common wasted hour on this problem, which is rewriting DNS settings for a routing decision.

Step 1: see both adapters claiming the prefix

Open Network Connections (ncpa.cpl) and read the two adapters side by side. The Ethernet adapter shows 192.168.1.50/24 with gateway 192.168.1.1. The VPN adapter shows 192.168.1.201/24, pushed by the server. Both are legitimate, both believe the prefix is on-link, and the stack will keep a single route for it.

Get-NetIPAddress -AddressFamily IPv4 lists the addresses, and Get-NetIPInterface | Sort-Object InterfaceMetric shows the order the stack will use them in. That metric column is the decision you are about to read, so note the numbers rather than remembering them.

Prove the DNS theory wrong cheaply: Resolve-DnsName printer.office.lan returns the same address it returned yesterday. The name resolved; the packet then left through the wrong adapter. Two minutes here saves an afternoon in resolver settings.

Step 2: read the route that actually won

Find-NetRoute -RemoteIPAddress 192.168.1.40 prints the interface, next hop and source the stack would use for that address. Treat that output as the answer, not as a hint. route print -4 gives the whole table when you want to see which entry lost and by how much.

Specificity beats intent. A pushed 192.168.0.0/25 defeats a local 192.168.0.0/24 because the prefix is longer, so 192.168.0.0 to 192.168.0.127 leave through the tunnel while the upper half stays local. Half a LAN disappearing without an error message is correct behaviour for that table.

tracert -d 192.168.1.40 confirms it from outside the table: if the first hop is a tunnel address instead of your own router, the route is the whole story. On Linux the same question is ip route get 192.168.1.40, which prints source address and device on one line. When the reply names tun0, stop looking at the browser.

Step 3: check the return path before blaming the client

A correct forward route still fails if the far side cannot answer. When a client LAN is reached through the tunnel, the LAN gateway has to know where the tunnel pool lives: ip route add 10.8.0.0/24 via 192.168.1.12 on that router, and push "route 192.168.1.0 255.255.255.0" from the server so clients know the reverse.

Without the first entry the reply leaves the target for its default gateway, which forwards a private address to the ISP and drops it. The symptom is one-directional and easy to misread: requests appear on tun0, replies never do.

A masquerade rule on the VPN host removes the need for that static route: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. It also hides the real source addresses, which makes every later log question harder. A target host with the wrong default gateway produces the same silence, with an ICMP redirect as the best case and a black hole as the normal one, which is why the capture belongs on both ends.

Step 4: choose a repair you can live with

Five repairs get used for this, and they are not interchangeable. Pick by what has to stay reachable at the same time, not by which command is shortest.

Metrics are the cheap option and the one people reach for first. The change applies to the interface, so it works while the tunnel is up, and it belongs in a script next to the client rather than in a shell you will forget. It cannot give simultaneous access to the same address on two networks, which is the limit that sends everyone else down the table.

Renumbering the home LAN to 10.10.0.0/24 is the clean fix: one DHCP lease renewal plus the reservations, printer queues and hard-coded addresses that mention the old range. Renumbering the office side is usually not your decision. IPv6 removes the collision entirely when both networks carry it, using a unique local prefix from fd00::/8 instead of something memorable, but test the application over TCP, not a ping, because ICMP can work while the service does not.

OpenVPN's own translation option is the last resort, pushed from the server into a client-specific directory entry. It takes four parameters after the option name — direction, network, netmask and alias — and the alias is not optional: push "route 192.168.2.0 255.255.255.0" and push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". The network and netmask are the range the client sees (192.168.2.0/24), the alias is the real office range on the server side (192.168.1.0/24), and the pushed route is what makes that visible range reachable. The office then appears to that client under 192.168.2.x. Document the mapping in the profile, or the next person will debug it as a routing fault.

Publishing a single service is the narrow version of translate, and it does not need OpenVPN's option at all. A DNAT rule on the VPN host republishes one port, so the LAN keeps its addresses and reaches the service at the host address it already knows. The cost is the usual one: the service sees the VPN host as the source, so per-client logs and reverse lookups stop meaning anything. That covers one printer queue or one admin page, not hosts on both sides reaching each other.

What still will not work, and what to record

Broadcast does not cross a routed tunnel. DLNA, UPnP, NetBIOS browsing and Wake-on-LAN depend on broadcast or multicast that a tun device does not carry, so no route fixes discovery. Bridging with dev tap extends the segment, and with it DHCP broadcasts, ARP and every other discovery packet; prefer a unicast host route such as route 192.168.2.1 255.255.255.255 for the LAN-side address of a remote router.

Two routers both using 192.168.1.1 on the same path belong to the same family of problem: the local address always wins, so the far router's page stays unreachable until one LAN moves. Adding a second adapter changes nothing about either case.

Record the evidence before you edit anything: ip route get or Find-NetRoute, ping -c 3 to the address in question, a traceroute, and tcpdump -ni tun0 icmp on the client, then the routing table and NAT counters on the server. A ping that works one way and dies the other points at the return path, not at the tunnel, and that single distinction decides which of the repairs above you actually need.