Fix a Local IP Address Conflict After Connecting to a VPN

Every one of these reports sounds the same and means something different: the laptop complains about an address conflict, but only sometimes, and mostly while the VPN is up. Three separate faults produce that message: a genuine duplicate on your own link, an overlap where the remote network uses your LAN range and nothing is duplicated at all, and a tunnel that handed one address to two peers. The repair differs in each case, and the wrong one moves the symptom instead of removing it. So decide which case you have before you edit anything.

Three faults that share one error message

A duplicate means two machines on the same segment both claim one address. The kernel notices because the reply to its own probe comes from a different MAC, and what happens next depends on the stack: Linux logs it, Windows disables the interface and writes a System log entry, and a DHCP client may decline the offer.

An overlap duplicates no address at all. Your LAN is 192.168.1.0/24, the office network is also 192.168.1.0/24, and now the route to the office points at addresses that are also your printer and your NAS. Nothing is in conflict in the ARP sense; the packet simply goes to the wrong device on one of the two networks.

A pool collision is the tunnel's own fault. Two peers were configured with or assigned the same tunnel address, so the server cannot tell them apart when it sends return traffic. One of the two clients sees a working handshake and no data, which reads like a routing problem and is not one.

Test 1: is the duplicate on your own segment?

Start by listing what your machine actually holds, not what you remember configuring. A VPN adapter address is private to the tunnel and is not the same as the address websites see, so a shared public exit is not a conflict.

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

On Windows the same information comes from ipconfig /all and Get-NetIPAddress, with the neighbour cache in arp -a. If the disputed address is on the physical adapter and the complaint appears without the VPN running, the VPN is a bystander and you should stop troubleshooting it.

To prove a duplicate rather than guess, probe the address from a device that does not own it. arping -D sends the probe with a zero source address, so a reply from an unexpected MAC proves another host already answers for that address.

sudo arping -D -I eth0 -c 3 192.168.1.50

Then find the owner through the network administrator rather than by picking a different address yourself. Static assignments that live only in someone's notes, printers with a fixed address, and reservations on the DHCP server are the usual culprits, and a device that is switched off still owns its lease.

Test 2: do the two networks overlap?

Compare the prefix the tunnel gives you with the prefixes on your own interfaces. If the remote range equals or contains your LAN, the failure is overlap, and the giveaway is that a host reachable without the VPN goes dark, or your own printer answers on an office address.

ip route get 192.168.1.10
ip -br addr show

The route lookup tells you which interface the kernel would use, and that answer is the whole diagnosis. If it says the tunnel for an address that belongs to your local printer, you have an overlap and no amount of lease renewal will change it.

There are three honest ways out, and only one is usually available to you. The remote side can masquerade traffic for the overlapping subnet, so your client only ever sees the server's tunnel address. The tunnel can carry a narrower remote prefix that does not collide with your LAN. Or the client can route by source address with policy rules, which works but is fragile and hard to hand to a colleague.

Renumbering the office network is rarely yours to decide. Renumbering your own LAN to dodge the collision is a bigger change than most people expect once printers, cameras and static hosts are involved.

Test 3: did the tunnel hand out one address twice?

WireGuard has no address pool. Each peer is identified by its public key and by the prefixes in AllowedIPs, so a duplicate appears when the same tunnel address is written into two peer entries or the same key pair is installed on two machines.

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

Traffic counters are the useful column here: a peer that shows a recent handshake but no transfer is either misaddressed or being shadowed by another entry claiming the same prefix. Put a prefix on exactly one peer and give each device its own key pair.

OpenVPN does have a pool, and the common collision is a shared client profile with a fixed --ifconfig line copied to a second machine. Both clients then request the same tunnel address, and the server accepts whichever session it processes first. Pool exhaustion with --duplicate-cn produces a similar outcome when several sessions of one certificate compete for one entry.

Read the server log rather than the client log for this one. The server knows which session claimed which address, and repeating addresses there are visible as warnings that never reach the client.

Repair at the source, then re-check both devices

Order matters. Fix a LAN duplicate first, because a client that cannot keep an address cannot hold a tunnel either. Then fix provisioning on the VPN side, because a client-side edit to a pool assignment is undone at the next connect. Last, deal with duplicated identities: separate key pairs on WireGuard, separate certificates or at least separate profiles on OpenVPN.

On the client the mechanical part is short. Release and renew a DHCP lease, or ask for the address to be changed on the server for a reservation. Do not type a random address that looks free.

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

Then verify from both ends, not one. Confirm the gateway, then the service you actually need, then reconnect and repeat. If two devices were involved, check both: moving one address leaves the other with stale neighbour entries or an old lease that reappears later.

What not to do on the way through

Do not silence the symptom. Duplicate address detection is what stops you from taking an address that is already in use, and disabling it converts a visible conflict into intermittent packet loss that is much harder to trace. The same applies to accepting a certificate warning from an unexpected host: that is not an address problem at all, and clicking through it hides a different fault.

Do not change a managed network's addressing on your own either. Record the original setting, ask the owner when the address is assigned centrally, and keep the change small enough to reverse. The RFC 5227 address-conflict detection rules explain what a correct probe proves, which is worth knowing before you call a conflict real.