Overlapping Client Subnets: How MSPs Reach Every 192.168.1.0/24 Without Renumbering

Ask any MSP how many of their client sites run 192.168.1.0/24 and the answer is usually "most of them". Nobody chose that range on purpose. It came with the router, the site was small, and nobody renumbered. That is fine until you try to reach all of those sites from one place.

Why overlapping subnets break a central VPN

A router decides where to send a packet by its destination address. If 192.168.1.50 exists at the dental practice and also at the hotel, a central hub has no way to know which one you meant. The address is no longer unique, so the route is ambiguous.

WireGuard makes this concrete. Its AllowedIPs list acts as a routing table for outgoing packets: the destination address decides which peer's key encrypts the packet. A given prefix can belong to only one peer. WireGuard's developers describe this as deliberate, and if you add a prefix that another peer already holds, it is moved to the new peer rather than rejected. So when you add the second client whose LAN is 192.168.1.0/24, the first client silently stops being reachable. No error, just a site that used to work and now does not.

The usual workarounds, and what they cost

Renumber the client. The clean fix on paper. In practice it means re-addressing printers, cameras, PBX handsets, the NVR, static DHCP reservations and anything with a hard-coded IP. It needs a site visit, and it is hard to justify to a client whose network works fine.
One VPN profile per client. The engineer connects to the hotel, disconnects, connects to the dental practice. One site at a time, and useless for monitoring several sites together.
Hand-built NAT per tunnel. Translate each site to a unique range on the router or the hub. The right idea, but done by hand across dozens of sites it becomes a spreadsheet of ranges nobody trusts.
Software on every device. Install an agent on each endpoint and address them by the agent's own overlay IP. The NVR, the PBX, the switch and the UPS card cannot run one.

How ProxyLink handles it: a unique range per site, translated at the gateway

ProxyLink uses the hand-built NAT idea and automates it, so you never keep the spreadsheet.

When you create a gateway tunnel for a client site and declare its LAN subnet, ProxyLink automatically gives that site its own unique range out of 10.128.0.0/9. The ProxyLink side only ever routes to that unique range, so two clients both on 192.168.1.0/24 never compete for the same route. The client's real LAN addressing never enters ProxyLink's routing at all.

The translation itself happens on the client's router, using a NETMAP rule. NETMAP is a static one-to-one mapping between two networks of the same size: the network part of the address is swapped and the host part is kept. If the hotel is assigned 10.128.17.0/24, then 10.128.17.50 arriving through the tunnel becomes 192.168.1.50 on the hotel LAN, and replies are translated back on the way out.

You do not write those rules yourself:

On a Linux gateway, the WireGuard config you download from ProxyLink already contains the iptables -t nat ... -j NETMAP rules in its PostUp and PostDown lines.
On a MikroTik, ProxyLink's auto-configuration adds the matching action=netmap NAT rules over SSH when it sets up the tunnel.
The tunnel page in ProxyLink also shows the rules as copy-paste commands, so you can see exactly what is running on the router.

VLANs get the same treatment

Overlap is not only a primary-LAN problem. Camera and voice VLANs tend to reuse the same handful of ranges too. On gateways running the ProxyLink gateway agent, every VLAN, not just the primary LAN, gets its own unique translated range and its own NETMAP rule. On routers without the agent, additional VLANs are routed directly, and ProxyLink checks them for collisions when you save them, so a clash is caught at configuration time.

What it looks like day to day

You keep thinking in the client's real addresses. A link can point at the hotel NVR on 192.168.1.50 and ProxyLink maps it to the right translated address when it connects, so browser RDP, VNC, SSH, the NVR web interface and the PBX admin panel at both sites open side by side. If you use ProxyLink's engineer VPN from your own laptop, you reach devices by their translated 10.128.x.x address instead, which is what lets two identical LANs sit in one routing table.

Nothing changes on the client side: no renumbering, no DHCP edits, no software on the devices behind the router. One outbound WireGuard tunnel from the router covers the LAN and its VLANs, and because the tunnel initiates outbound, the site needs no public IP and no open ports.

Try it on your two most identical clients

Pick the two client sites whose LANs are the same range and put a tunnel on each router. If you can open a device at each site at the same time, the overlap problem is solved for every site after them too. ProxyLink is free during early access, with no card and no trial countdown. Start at app.proxylink.dev, and read the setup guides at proxylink.dev/docs.