Your VPN pool is not the LAN DHCP range: why it breaks

The tempting shortcut is to hand VPN clients addresses from the same range the office DHCP server uses, on the theory that everything is one network anyway. It is not. A routed tunnel carries unicast packets between two endpoints, while the LAN pool exists to answer broadcast requests on a physical segment. Reusing the numbers puts two allocators in charge of one address space and leaves the return path undefined.

Two allocators, one address space

The LAN DHCP server knows which addresses it has leased and to which MAC address, and it defends them with ARP. The VPN server has its own pool and no knowledge of those leases. Neither is wrong; they were never introduced.

An address from the LAN pool that the VPN server hands out may already belong to a printer. Now two devices claim one address on the same prefix, and the switch's forwarding table decides which one answers.

That is the failure people meet first: a client that connects successfully and then reaches the wrong machine, or reaches the right one intermittently.

Why the router does not hand out VPN addresses

DHCP discovery is a broadcast, and broadcasts stop at a routed boundary. Unless the design bridges the tunnel or runs a DHCP relay with matching authority, the client's request never reaches the LAN server.

So the VPN server assigns the address itself: a pool in the server configuration, a per-peer address in a WireGuard setup, or an address pushed by the authentication layer in an IKEv2 deployment. Those mechanisms are independent of the LAN lease database, which is exactly why they need a range of their own.

The same reasoning explains why changing the DHCP scope does not fix a VPN client that never gets an address. The client is not asking the LAN server, and no amount of scope editing makes it ask.

The overlap shows up as a conflict, not a slow network

Two networks sharing a prefix without a supported design is a different problem from duplicate ownership, and they are often confused. If the VPN pool is a separate prefix, overlap only matters when a route sends traffic to the wrong side. If the pool sits inside the LAN prefix, the conflict is immediate and local.

In practice you see ARP replies from the wrong device, connections that reset halfway, and a client whose own address is claimed by somebody else. None of those look like a routing problem, which is why the fix gets applied to the wrong layer. A duplicate lease is easy to confirm and annoying to live with. It also survives reboots, because both allocators keep insisting on the same address.

Return path is a separate problem

Even with a clean, distinct pool, LAN hosts need to know how to answer a client. Their default gateway is the router, and the router needs a route for the pool pointing at the VPN server, unless the design translates client traffic instead.

Read the path in both directions before changing anything. On the gateway, ask which interface the kernel would use for a client address; on the client, ask which route it uses for a LAN address.

These commands show the forward decision on the gateway and the neighbour entries that reveal a duplicate:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

If the first command answers with the tunnel interface, the return route exists. If it answers with the LAN interface, the router believes the client is on the wire and will try to ARP for it.

Bridged designs exist, but they must be chosen

Bridging a tunnel to the LAN is a real design, used when clients must receive broadcasts or be discovered by protocols that assume one segment. It requires the server to own that bridging behaviour and the address handling that goes with it.

What does not work is imitating the result by copying numbers. A shared pool with no bridge gets you the conflict without the discovery, which is the worst of both arrangements.

Choose layer three with a distinct pool unless the application genuinely needs the segment, and document the pool so the next administrator does not reuse the DHCP range for tidiness.