Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
Fix WireGuard Overlapping Subnets Without Breaking Access
Ryan Foster
October 11, 2026· 10 min read
WireGuard overlapping subnets occur when the same destination range identifies machines on both sides of a tunnel. Fix the ambiguity by renumbering one controlled LAN, then updating its routes, peer prefixes, and dependent services; a successful handshake or wider AllowedIPs cannot distinguish two hosts with the same address.
Key Takeaways
- Identify the local and remote machines before changing a route.
- Preserve a management path independent of the LAN being renumbered.
- Change one site's addressing, not every site's defaults at once.
- Verify target identity, return traffic, DNS, permissions, and persistence.
Why do WireGuard overlapping subnets need an address plan?
This guide covers Ubuntu 24.04 LTS distribution WireGuard tools, an existing site-to-site tunnel, and control of the remote LAN. It is compiled from official documentation for the listed environment and has not received a complete end-to-end author test. NetworkManager-managed interfaces, container networks, IPv6 renumbering, and managed corporate gateways need their own approved change procedures.
Use the self-hosting planning checklist to establish responsibility and recovery. Linux routes select an interface; WireGuard's peer prefixes select a peer for outgoing packets and constrain incoming source addresses. They do not create an identity for an otherwise ambiguous destination.［1］［2］
This is a private-resource task. Keep your self-hosted or organization-managed access method when you need that resource. Only if the task changes to an internet exit should you compare a home gateway with a maintained VPN service; that decision does not repair an address collision.
Step 1: Map the two LANs and the management route
Confirm the proposed range is unused across your organization, peers, containers, and reachable networks. Substitute your inventoried interfaces and addresses; private prefixes are not globally unique.
| Role | Before | After the remote-site change |
|---|---|---|
| Local LAN A | 192.168.50.0/24 | Unchanged |
| Remote LAN B | 192.168.50.0/24 | 192.168.77.0/24 |
B's LAN gateway on ens19 | 192.168.50.1 | 192.168.77.1 |
| Authorized target on B | 192.168.50.10 | 192.168.77.10 |
| WireGuard A / B | 172.31.253.1/32 / 172.31.253.2/32 | Unchanged |
| B's independent management | Console or separate management interface | Unchanged |
The WireGuard endpoint transport must remain reachable through its original management/WAN path. The tunnel range is separate from both LANs. If the conflict is actually the tunnel range, or you cannot change B, stop this renumbering procedure and select an appropriate design with the owner.
Record static leases, DHCP scope, gateway settings, DNS records, service bindings, ACLs, monitoring, and every affected peer. Reserve a maintenance window and verify console access with a new session. Back up the exact Netplan, WireGuard, and firewall-manager files privately, preserving permissions; do not paste wg showconf or wg show ... dump into a ticket because they can expose key material.［1］
Step 2: Prove the VPN route collision
Check the affected Ubuntu client or gateway read-only, using its interface and target addresses:
ip -brief address
ip -4 rule show
ip -4 route show table all
ip -4 route get 192.168.50.10
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer
Save only sanitized observations. A route to the local LAN explains why an apparent remote target can be reached without crossing WireGuard. A handshake proves recent peer communication, not the identity of a LAN host or authorization to access its service. Inspect policy rules as well as the main table.［2］［3］
Confirm the intended machine using an inventory identifier, a verified TLS certificate, or an SSH host key checked through your established trust process. Ping alone cannot identify it. Do not accept a changed SSH key or certificate merely because the address conflicts; reach the owner through the independent management path.
If routing already selects the expected nonoverlapping remote range, investigate the connected-but-no-traffic checklist instead. Do not renumber a working LAN to compensate for a blocked service or missing forwarding permission.
Step 3: Choose a WireGuard subnet conflict remedy
Renumbering B gives its machines distinct addresses end to end. This is the main procedure below. A host route that forces 192.168.50.10 through the tunnel might choose B, but then hides the same local address from that routing context; it does not make both identities available simultaneously.
| Approach | Suitable condition | Cost or boundary |
|---|---|---|
| Renumber one LAN | You control its addressing and dependencies | Change DHCP, static hosts, DNS, and policy together |
| Controlled address translation | An owner cannot renumber and operates the gateway | Reserve an alias prefix and map both directions deliberately |
| Separate routing context | Applications can use isolated namespaces | Requires explicit interface, DNS, and management ownership |
WireGuard documents namespace isolation, but moving an interface also changes the network context visible to applications; it is not a casual remote-session fix.［2］ Netgate's conflicting-subnet recipe demonstrates translation using OpenVPN, not WireGuard. It is evidence for the mapping principle and limitations, not a source of WireGuard commands.［4］
A translation design must specify the real and alias prefixes, inbound destination mapping, any source mapping, return route, DNS answers, and logs. Embedded IP addresses and applications initiating reverse connections may still fail. NAT does not grant access permission or replace firewall rules. If those fields cannot be specified, stop rather than applying a broad masquerade rule.
Step 4: Renumber only the controlled remote site
Start on B through its console. On the existing Netplan configuration's ens19 entry, change only the LAN address from 192.168.50.1/24 to 192.168.77.1/24; preserve its renderer and every management-interface field. The example is a field fragment, not a replacement for all Netplan files:
ens19:
addresses:
- 192.168.77.1/24
Update B's DHCP range and router option if it serves DHCP. Change the authorized test target to 192.168.77.10/24, gateway 192.168.77.1, using its existing network manager and console. Migrate reservations and other static hosts deliberately, avoiding duplicate leases. Update service listen addresses and narrowly scoped firewall rules for the new prefix; retain the existing forwarding policy and endpoint rules.［5］
Validate and try B's Netplan change from the independent console:
sudo netplan generate
sudo netplan try --timeout 120
Confirm only after the console, management route, new LAN gateway, and target are reachable as intended. Netplan documents rollback caveats: after rejection or timeout, independently check the actual network and on-disk files rather than assuming everything reverted.［6］ If another manager owns the interface, stop here and use that manager's documented rollback process.
On A, edit only B's peer entry in the private wg-quick configuration. Preserve its actual public key, endpoint, and credentials. For this topology, its complete prefix set becomes:
AllowedIPs = 172.31.253.2/32, 192.168.77.0/24
This assignment replaces that peer's old prefix set; it is not an additive command. If the peer owns additional authorized networks, retain those explicitly. B's peer for A must still permit A's real source prefixes, here 172.31.253.1/32 and 192.168.50.0/24, with corresponding return routing. Peer prefix and route responsibilities explain why changing one field is insufficient.［1］
For this inventoried, dedicated wg-quick tunnel, apply the saved configuration from A's independent console using sudo wg-quick down wg0, then sudo wg-quick up wg0. Interruption is intentional. Review hooks and SaveConfig first: if SaveConfig = true, shutdown can overwrite your file edits; stop and reconcile runtime and persistent state before proceeding. wg set alone would not update system routes.［7］
Never flush routes, reset the entire firewall, widen to 0.0.0.0/0, or change both sites' defaults to get a response. For a shared tunnel, obtain its owner's maintenance procedure instead of restarting other users' access.
Step 5: Verify identity, return traffic, and DNS
Repeat route checks from A for both 192.168.50.10 and 192.168.77.10. The local address should retain its local path; the new remote address should select wg0. On B, inspect the return route to the actual A source address. Use a permitted application request and its verified server identity, not only ICMP.［3］
| Check method | Expected observation | If it differs |
|---|---|---|
| Compare routes for old-local and new-remote targets | Distinct local and tunnel paths | Inspect policy tables and stale routes |
| Verify the remote service certificate or approved host key | The intended B machine responds | Stop on identity mismatch |
| Inspect B's route to A's source and peer prefixes | Return traffic uses the approved path | Correct the narrow return route or peer entry |
| Query the relevant private DNS resolver | Remote service name resolves to the new address | Update authoritative records and bounded caches |
| Request one allowed and one denied service | Original permissions remain enforced | Correct prefix-specific rules, never disable policy |
| Reconnect, then reboot during an approved window | Address, routes, and service return consistently | Repair the owning manager's persistent configuration |
Do not change public DNS to diagnose a private name that only the organization's resolver knows. Account for record TTLs and application caches before retiring the old address. These checks concern private resources and do not require a public-IP website.
If another application path crosses a proxy, verify that path independently using the hop-by-hop chain checks. A successful proxy request does not establish this WireGuard route or its return path.
Step 6: Restore narrowly or keep the new address plan
If acceptance fails, stop further changes. From the independent consoles, restore B's original LAN, DHCP, target address, and only the policy/DNS entries changed in this window. Restore A's saved peer configuration and restart only the dedicated tunnel through its inventoried manager. Do not re-enable a revoked peer or overwrite unrelated concurrent policy changes.
Read back original management access, listeners, address assignments, routes, and a known original service. Returning to the old overlap restores the baseline fault; it is not proof the collision was solved. Record the unresolved limitation and postpone further experiments if restoration cannot be verified.
If acceptance succeeds, retain the new inventory and private backup under the owner's retention policy. Revoke temporary credentials, remove temporary permissions, and document DHCP/DNS ownership. Verify persistence by reconnecting/rebooting, not merely saving files.
Summary
- Prove the address ambiguity before changing topology.
- Renumber one controlled LAN with independent management.
- Update routes, peer prefixes, DNS, and policy consistently.
- Verify two distinct target identities and the return path.
FAQ
Will wider AllowedIPs fix WireGuard overlapping subnets?
No. Wider prefixes can capture more traffic, but they cannot distinguish two machines using the same destination address within one routing context.
Why does WireGuard show a handshake while the wrong host answers?
A handshake confirms peer communication, while the application's route may still select a local machine with the same address as the remote target.
Can I use a host route instead of renumbering?
A narrow host route can deliberately choose one side, but the other machine at that address becomes unavailable through the same routing context.
Is translation always easier than changing the LAN?
No. Translation needs deliberate forward and return mappings, compatible applications, correct DNS, and maintained policy; it can obscure logs and reverse connections.
Should I change the WireGuard endpoint address too?
Not when only B's internal LAN changes. Preserve the working WAN endpoint and independent management path unless their own approved change requires otherwise.
Can I restart the tunnel over my only SSH connection?
Do not use this procedure through your only management path. Establish and verify an independent console before changing addresses or restarting the tunnel.
Does reverting the old files mean recovery is complete?
No. Independently verify runtime addresses, routes, DNS, permissions, and management access; a saved file or a rollback timer alone does not establish recovery.
Sources:
- Ubuntu 24.04 — wg(8)
- WireGuard — Routing & Network Namespaces
- Ubuntu 24.04 — ip-route(8)
- Netgate — Connecting OpenVPN Sites with Conflicting IP Subnets
- Netplan — Configuration examples
- Netplan — netplan try
- Ubuntu 24.04 — wg-quick(8)
Sources checked 11 October 2026.
Related Articles:
