Small Town Sysadmin
Free CJIS checklist

Networks

When a VPN user's home network uses the same subnet as the office

If someone's home router hands out the same addresses as your office network, the VPN connects but office servers can't be reached. Here's why, the quick fix with a VPN route on Windows, and the long-term fix.

A remote user connects to the office VPN, it says Connected, and nothing at the office works. File shares time out, the line-of-business app can’t find its server, and pinging the server either fails or gets a reply from something that clearly isn’t the server. Other VPN users are fine.

One common cause: the user’s home network and the office network use the same subnet. Consumer routers ship with a handful of default ranges, 192.168.1.0/24 and 192.168.0.0/24 being the usual ones, and plenty of small offices were set up with the same defaults years ago.

What’s going on

When the laptop connects, it now has two ways to reach 192.168.1.x:

  • Its home Wi-Fi or Ethernet adapter, which sits directly on 192.168.1.0/24
  • The VPN tunnel to the office, where the servers also live on 192.168.1.0/24

Windows picks a route by prefix length first. Microsoft’s documentation puts it plainly: “If multiple route prefixes match a packet destination, the route with the longest prefix length is preferred. If multiple matching routes exist with the same prefix length, then the route with the lower metric is used.”

Both networks are a /24, so the tie goes to whichever route has the lower metric, and you don’t control the home side of that. When the local adapter wins, the packet for the office file server at 192.168.1.10 goes to whatever is at 192.168.1.10 on the home network, which is usually nothing, sometimes a printer or a smart TV.

Even with the VPN set to send all traffic through the tunnel, the overlap is still a problem: a 0.0.0.0/0 default route is less specific than the home network’s own /24, so the /24 wins.

How to confirm it

On the user’s PC, with the VPN connected, check the home adapter’s address and ask Windows which route it would use to reach an office server:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength
Find-NetRoute -RemoteIPAddress 192.168.1.10

Find-NetRoute returns the local address and the route Windows would pick. If InterfaceAlias is the Wi-Fi or Ethernet adapter instead of the VPN connection, you’ve found it.

The quick fix: a more specific route through the VPN

Since the longest prefix wins, add a route for just the addresses the user needs (a /32 for each server), tied to the VPN connection. A /32 beats the home network’s /24, so traffic to those addresses goes through the tunnel.

For the built-in Windows VPN client, Add-VpnConnectionRoute adds a route to the VPN connection profile. Use the connection’s name exactly as it shows in Windows:

Add-VpnConnectionRoute -ConnectionName "Office VPN" -DestinationPrefix "192.168.1.10/32" -PassThru
Add-VpnConnectionRoute -ConnectionName "Office VPN" -DestinationPrefix "192.168.1.11/32" -PassThru

If the VPN connection was created for all users rather than just the signed-in user, add -AllUserConnection. Then disconnect, reconnect, and run Find-NetRoute -RemoteIPAddress 192.168.1.10 again. It should now show the VPN interface.

A few things to know about this fix:

  • It’s per server, per PC. Every server or device the user needs gets its own route, and every affected PC needs them. That’s fine for one or two remote users. It doesn’t scale.
  • Anything at home on those exact addresses becomes unreachable while the VPN is connected. If an office server’s address collides with something the user needs at home, such as their own router, use the long-term fix instead.
  • Routes set on the VPN server don’t help here. On a MikroTik, for example, the routes field on a PPP secret is described as “Routes that appear on the server when the client is connected.” That’s the router’s routing table, not the laptop’s. The decision that’s going wrong happens on the client.

Don’t forget DNS

Name lookups need to reach the office DNS server (on most small networks, the domain controller) and not the home router. Have the VPN server hand out the internal DNS server to VPN clients. On a MikroTik L2TP or other PPP-based VPN, that’s the dns-server setting on the PPP profile, which MikroTik describes as the “IP address of the DNS server that is supplied to PPP clients.” If the DNS server is itself on the overlapping subnet, it needs a /32 route through the VPN too, or lookups will go to the home network.

The long-term fix: move the office off the default range

The real fix is to stop sharing a subnet with half the home routers in town. RFC 1918 sets aside three private ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Anything in them is fine for an office, so pick something unlikely to match a home network, such as a /24 deep inside 10.x or 172.16–172.31, instead of 192.168.0.x or 192.168.1.x.

Renumbering an office is a real project: DHCP scopes, static addresses on servers and printers, DNS records, firewall rules, VPN pools, and anything with an IP address typed into it. But it fixes the problem for every remote user at once, and it’s worth doing the next time the network is being reworked anyway, such as during a firewall replacement.

If you’re setting up a new office, choose the less common range from the start.

Sources

All articles