VPN and Overlay Network Addressing: WireGuard, Tailscale, and the Ranges That Don't Collide

Connect to a VPN (Virtual Private Network, an encrypted tunnel that makes a distant network behave as if you were plugged into it directly) from home and everything works: the office file server appears, the internal wiki loads, the shared drives mount. Take the same laptop to a hotel, connect the same VPN, and half of it is gone. No error message explains it, because address collisions do not produce error messages; connections just quietly time out. The hotel's network and your office network claimed the same range of IP (Internet Protocol) addresses, and your laptop, holding one route for each, picked a side without telling you. This post is about how VPNs and their modern descendants, overlay networks, get their addresses: where remote-access pools come from, why two sites so often overlap, how WireGuard and Tailscale each answered the question, and why every overlay vendor converged on one odd block, 100.64.0.0/10, that was never set aside for any of them.

A VPN works by giving your device an extra network interface, a virtual one that exists only in software. Traffic entering that interface gets encrypted, carried across the ordinary internet, and decrypted at the far end, and because the interface behaves like any other, it needs an address. So every device on a VPN holds at least two addresses at once: the one its local router assigned, and the one it uses inside the tunnel. The routing table decides which interface handles which destination by one rule, the most specific matching route wins. (If ranges written like 10.0.0.0/8 are unfamiliar, our visual guide to CIDR notation, short for Classless Inter-Domain Routing, explains the slash numbers from scratch.) A collision happens when the same range becomes reachable through two interfaces. The routing table never warns you; it applies its rule, sends everything for that range one way, and the losing network's devices become unreachable in complete silence.

The most common version of this failure involves the two most popular subnets on Earth. Home routers ship with factory defaults, overwhelmingly 192.168.0.0/24 or 192.168.1.0/24, both carved from the private space that a standards document called RFC 1918 (from the Request for Comments series, where internet standards are published) set aside for anyone to reuse, part of the tour in our guide to the 10 reserved IP ranges every engineer should know. Suppose the office LAN (local area network, the network within one building) was also numbered 192.168.1.0/24, because somebody kept the defaults there too. Connect from home and your printer at 192.168.1.50 and the office file server at 192.168.1.20 now live in the same contested range. Depending on the VPN's configuration, either packets meant for the office die in your living room, or the tunnel swallows everything including the packets meant for your printer. Away from home you inherit whatever range the hotel or coffee shop chose, which is why a VPN can behave perfectly for months and then fail somewhere new.

Traditional remote-access VPNs, the corporate kind built on protocols like OpenVPN or IKEv2 (Internet Key Exchange version 2), handle their side of the tunnel with an address pool: a range the VPN server owns and hands out from, one address per connected user, much the way a home router leases addresses by DHCP (Dynamic Host Configuration Protocol, the standard that lets devices request an address instead of being configured by hand). The pool has to dodge two things at once: every subnet the company actually uses, and every subnet an employee's home or hotel might use. The first is under your control. The second is a matter of probability, and the odds are friendlier than they sound, because home equipment clusters heavily on a few defaults. The block 10.0.0.0/8 alone contains 65,536 different /24 subnets, and almost nobody's home router sits at 10.213.77.0/24. A pool picked at random from deep inside 10.0.0.0/8, avoiding round numbers, beats any default, and our free subnet calculator will carve whatever you pick into pools of the right size.

WireGuard, the protocol underneath much of the modern VPN world, makes the addressing question impossible to ignore, because it declines to answer it for you. WireGuard is an open-source tunneling protocol, built into the Linux kernel since 2020 and admired for doing very little, very fast: it encrypts packets between peers and moves them, and that is close to the entire feature list. There is no pool, no DHCP, no server assigning anything. You write every peer's tunnel address into a configuration file by hand, and each peer's AllowedIPs line declares which addresses live behind it, doubling as the routing table. The configuration file is the address plan:

One WireGuard config is also its network's entire address plan

# wg0.conf on the office server
[Interface]
Address = 10.213.77.1/24       # this machine, inside the tunnel
ListenPort = 51820
PrivateKey = (hidden)

[Peer]                          # the laptop
PublicKey = hQ1x…
AllowedIPs = 10.213.77.11/32

[Peer]                          # branch-office router, plus the subnet behind it
PublicKey = 9dLf…
AllowedIPs = 10.213.77.12/32, 10.88.4.0/24

The discipline this demands is IPAM (IP Address Management, keeping an authoritative record of which addresses are assigned to what) at its smallest possible scale: a text file. Hand the same tunnel address to two peers and you have manufactured the classic duplicate-address fight, with the same quiet breakage our guide to IP address conflicts dissects, except spread across cities. A hand-edited file holds up fine at five peers and decays steadily from there, and choosing the tunnel subnet is the same collision lottery as choosing a pool: the tutorials all say 10.0.0.0/24, which is precisely why you shouldn't.

Tailscale exists because most people would rather not maintain that file. It is a mesh VPN built on WireGuard, mesh meaning every device connects directly to every other rather than through one central server, and Tailscale's coordination service manages the keys, the connections, and, crucially for this story, the addresses. When a device joins your network, which Tailscale calls a tailnet, it automatically receives an address it keeps for as long as it remains a member. Those addresses come from somewhere surprising: 100.64.0.0/10, which belongs to none of the private ranges. That block was set aside in 2012 by RFC 6598 for exactly one purpose, CGNAT (carrier-grade Network Address Translation, or NAT: the large-scale address sharing that ISPs, Internet Service Providers, run when they place many customers behind one public address, and one of the variants sorted out in our plain-language tour of NAT). The reasoning behind the squat is sound. An overlay vendor assigning addresses cannot know what its users' local networks look like, but it can be nearly certain that homes and offices sit somewhere in the RFC 1918 ranges, so any pick from those invites the hotel problem. The CGNAT block is different: banned from the public internet, rarely present inside anyone's building, and about four million addresses deep. Tailscale claims the entire /10 for its networks and even parks its internal DNS service (Domain Name System, the directory that turns names into addresses) at the memorable 100.100.100.100.

The trouble with a clever choice is that everyone else's engineers are clever too. NetBird, another WireGuard-based mesh, defaults to the same block. Headscale, the self-hosted implementation of Tailscale's coordination server, does too. Kubernetes teams borrow the range for pod networks when 10.0.0.0/8 runs dry, the escape hatch we recommended with cautions in our guide to IP planning for Kubernetes. Engineers reach for it as neutral ground when translating between overlapping networks. And mobile and satellite providers use it for its original chartered purpose, actual carrier-grade NAT, which means millions of home connections already sit inside the range before any overlay software shows up. A block chosen because nothing lived there has become one of the busiest neighborhoods in private addressing, and collisions among its tenants are exactly as baffling as the 192.168.1.0/24 kind: an overlay node and an ISP gateway both answering for 100.72.x.x, or a mesh route fighting a Kubernetes pod range, with nothing in any log to say why.

Tunnels between whole networks raise the stakes, because a collision stops being one laptop's problem. Site-to-site VPNs connect a branch office to headquarters, or an office to a cloud environment, and routing between two networks only works if their ranges are distinct: a packet addressed to 192.168.0.15 cannot carry a footnote about which 192.168.0.0/24 it means. When both sides overlap, the honest options are three. Renumber one side, the durable fix, for which our survival guide to merging networks after an acquisition is the full playbook. Translate at the boundary with NAT, buying time at the price of permanent bookkeeping. Or route around the overlap entirely, which is what Tailscale's feature for this situation does by carrying the duplicated ranges inside IPv6 (Internet Protocol version 6, the successor addressing system) packets, a workaround whose existence tells you how common the problem is. Site-to-site tunnels also consume addresses of their own, since each tunnel typically wants a tiny transit subnet, the /30 and /31 point-to-point links we've covered before, and as our guide to multi-cloud and hybrid IPAM warns, a company with a dozen tunnels usually has a dozen transit subnets recorded nowhere but device configs.

All of this condenses into a short set of choices, one per thing you might be numbering. Each row pairs the habit that causes collisions with the pick that avoids them.

The last row deserves a word, because it reveals the whole problem as an artifact of the small size of IPv4 (Internet Protocol version 4, the addressing system most networks still run). IPv6, whose address space is vast beyond intuition, includes ULAs, unique local addresses, a private range in which the standard instructs you to generate 40 bits of your prefix at random. Follow the instruction and the chance that two organizations, or your tunnel and your hotel, ever pick the same prefix is negligible. The collision avoidance that IPv4 practitioners perform with dice rolls and unpopular numbers is built into the address format itself, and WireGuard and Tailscale both run IPv6 inside tunnels today; our guide to IPv6 address planning covers ULAs and why conservation instincts mislead there.

Whichever ranges you settle on, remember that an overlay is a real network that exists in no building, and its allocations tend to live in the least durable places: a vendor's admin dashboard, a wg0.conf on a server, a tunnel definition in a cloud console. They belong in the same address plan as your ordinary subnets, because the engineer borrowing 100.64.0.0/10 for a Kubernetes cluster will not think to check the Tailscale admin panel first. In IPCraft that takes a few minutes: create 100.64.0.0/10 as a subnet owned by the overlay, register WireGuard peers as addresses with custom fields for the public key and device owner, and give VPN pools and transit /30s their own entries so every claim shows up in one tree. If two environments genuinely must keep overlapping ranges, support for VRFs (Virtual Routing and Forwarding instances, explained in our guide to VLANs vs VRFs) holds both plans intact instead of pretending the overlap away.

The rule that survives all the detail is short. Every tunnel adds a network, every network needs a range, and a range is chosen well only if it stays clear of every other network its members will ever touch, including hotel Wi-Fi you cannot predict and carrier equipment you never see. So pick unpopular numbers, accept vendor defaults consciously rather than by omission, and write every range down where the next allocation will trip over it. Address collisions raise no alarms, which makes the written plan the only warning system you get.