Why two sites with the same subnet are not one LAN

Two offices both use 192.168.77.0/24, and someone proposes a tunnel so they can be one network. The phrase sounds simple and hides three different designs: two independent LANs that collide, one intentional Ethernet segment stretched across a WAN, and a proxy-ARP arrangement that answers for remote addresses. Which one you have decides what a host does with the packet, and the answer is visible before the VPN gateway is involved.

The host decides before the router does

A host with address 192.168.77.10/24 compares the destination against its own prefix. Anything inside that prefix is on-link, so the host resolves the destination's link-layer address directly. Anything outside goes to the default gateway.

That decision happens in the host's stack, not in the tunnel. A route added on the gateway cannot rescue a packet the host never sends there.

So when 192.168.77.20 exists only at the other site, the local host ARPs for it and gets no answer. The VPN handshake can be perfectly healthy while this fails. The failure looks like a dead host rather than a routing problem. Recognizing that signature saves an hour of tunnel debugging.

ARP is a local-link question

ARP asks who owns an address on this link, and the answer has to come from something that can hear the broadcast. A router at the other end of an IPsec tunnel does not hear it unless the design makes the two sites one broadcast domain.

Two devices with the same address make it worse: even a successful resolution cannot tell you which one answered.

Duplicate addressing is not a routing bug and no route fixes it. Either the sites are renumbered into distinct prefixes, or they become one link-layer domain on purpose.

A stretched segment carries frames, not routes

An Ethernet-carrying tunnel attached to bridges makes both sites part of one link-layer domain. ARP broadcasts reach the far side, and each bridge learns which MAC addresses sit where. The Linux bridge documentation describes that MAC-based forwarding boundary.

Here the distant gateway is not routing between two identical subnets at all. Frames cross an underlay that routes IP in its own right, while the bridges extend the Ethernet conversation.

The cost is a bigger blast radius. Flooding for unknown destinations, loops, DHCP allocation, and unique addressing all need one plan that spans both sites. When the WAN drops, hosts lose traffic they consider local. Filtering on the bridge and VLAN rules can restrict what crosses, yet carriage still does not promise that every link-local control frame makes it.

Proxy ARP is a third design

A router can answer ARP for a remote address and then route toward it. That makes the remote host appear on-link to the sender without stretching a broadcast domain.

It is a narrower tool than bridging: it depends on forwarding, return routes, and a clear owner for each address.

It also does not make arbitrary non-IP protocols routable, and it does not reproduce an Ethernet broadcast domain. Use it when the requirement is exactly that substitution, not as a shortcut for postponed renumbering.

Choose from the requirement, then verify

For ordinary interoffice application access, distinct prefixes and explicit routes give a clearer boundary. Bridge when the requirement is genuinely link-layer adjacency. Renumber when the only reason for the shared prefix is that nobody has done it yet.

Confirm which design you actually have by asking a host what it does with the destination:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

An on-link result with a failed neighbor entry points at a missing link-layer path. A via result names the gateway and moves the question to routing. On a bridge, check the forwarding database to see whether the MAC was learned across the tunnel. Each output narrows the design question instead of restarting it.