Multi-Site IP Address Management: How to Keep Branch Office Networks Organized

By Mike Walton, Founder of Subnet24

With 20+ years managing IT infrastructure, I’ve seen the same story play out again and again: one office runs smoothly, the second office is “basically the same,” and by the fifth location nobody can say with confidence which subnets live where. Multi-site networks don’t become messy all at once. They get there one reasonable shortcut at a time.

---

Your company just opened its sixth branch. The local contractor configured the router with 192.168.1.0/24 because that’s what the router shipped with. It works fine—until the site-to-site VPN comes up and traffic for the new office starts landing at headquarters, which has been using 192.168.1.0/24 for its printers for years.

Nothing is broken, exactly. Everything is just quietly wrong. And now someone has to re-address a live office on a Saturday.

This is the core challenge of multi-site IP address management. Each location is simple on its own. The complexity lives in the spaces between sites: overlapping ranges, inconsistent conventions, and documentation that only exists in the head of whoever set up that office.

Why Multi-Site Networks Drift Out of Control

Single-site networks can survive on informal knowledge for a surprisingly long time. Multi-site networks can’t. A few patterns show up almost everywhere:

• Every site was built by a different person. An in-house admin set up headquarters, an MSP handled two branches, and a local contractor did the rest. Each brought their own habits.
• Default ranges get reused. 192.168.0.0/24 and 192.168.1.0/24 are the defaults on a huge number of consumer and small-business devices. Left alone, several sites will end up on the same range.
• Sites are documented separately—if at all. One spreadsheet per location, a wiki page for headquarters, and a photo of a whiteboard for the warehouse.
• Growth is uneven. One branch doubles in size while another shrinks, and the original subnet sizes stop matching reality.
• Connectivity changes the rules. Isolated sites can safely reuse ranges. The moment you add a VPN, SD-WAN, or cloud interconnect, every overlap becomes a routing problem.

None of these are failures of competence. They’re what happens when there’s no shared plan and no single place to see the whole network.

Start with an Addressing Plan, Not a Spreadsheet

The most valuable thing you can do for a multi-site network is decide on a hierarchical addressing scheme before the next site goes live. A good plan makes the address itself tell you where a device is.

The 10.0.0.0/8 private range gives you plenty of room to work with. One common approach is to carve it up by region, then by site, then by function:

Level	Example	Size	Purpose
Organization	10.0.0.0/8	16.7M addresses	Entire private address space
Region	10.16.0.0/12	16 × /16	One block per region (e.g. East)
Site	10.16.0.0/16	65,536 addresses	One block per office
Function	10.16.10.0/24	254 hosts	Users, voice, servers, IoT, guest

With a scheme like this, 10.16.20.0/24 immediately tells you “East region, first site, voice VLAN.” Anyone on the team can read an address and know roughly where it lives, which makes troubleshooting dramatically faster.

A few guidelines make the plan hold up over time:

• Give every site the same internal layout. If users are always the .10 subnet and voice is always .20, admins can move between sites without relearning anything. This pairs naturally with VLAN and subnet mapping—VLAN 20 is voice everywhere.
• Reserve more than you allocate. Assign each site a large block (like a /16 or /20) even if it only needs a few /24s today. Future subnets for that site then come from the same block and stay summarizable.
• Leave room for sites you don’t have yet. Plan how many regions and sites the scheme supports, and keep unused blocks explicitly marked as reserved.
• Keep ranges summarizable. When each site’s subnets fall inside one contiguous block, routing tables stay small and firewall rules stay readable.

Don’t forget the addresses that don’t belong to any single site: point-to-point WAN links, VPN tunnels, management networks, and cloud VPCs. Give them their own dedicated blocks so they never collide with branch ranges. The best practices for subnet planning apply here as well.

Sizing Subnets for Each Location

Not every branch needs the same amount of space, but every branch benefits from the same structure. A practical approach:

1. Count what’s there today. Users, phones, printers, access points, cameras, and IoT devices—not just laptops.
2. Estimate growth. Plan for at least the next two to three years of headcount and device growth.
3. Add headroom. A subnet that’s 90% full on day one will cause problems within months. Aim to keep utilization comfortably below your warning threshold.
4. Separate device types. Guest Wi-Fi, IoT, voice, and point-of-sale traffic belong in their own subnets for both performance and security. Our article on network segmentation best practices goes deeper on this.

If you’re unsure about the math, the free IPv4 Subnet Calculator will show host counts and ranges for any prefix, and the Network Planner will flag overlapping subnets as you lay out each site. For ongoing growth tracking, see our guide to IP address capacity planning.

Preventing Overlapping Subnets

Overlaps are the most expensive multi-site mistake because they’re usually discovered at the worst possible time—during a VPN rollout, a merger, or an outage.

To prevent them:

• Allocate from one central plan. New subnets should be assigned from the master addressing plan, never chosen locally.
• Check before you configure. Before a new range goes onto a router, confirm it doesn’t overlap anything already in use—including cloud networks and remote-access VPN pools.
• Retire default ranges. Move sites off 192.168.0.0/24 and 192.168.1.0/24 when you can. They’re the ranges most likely to collide with home networks and newly acquired offices.
• Plan for acquisitions. If your organization grows through acquisitions, expect overlapping ranges to arrive with every new company. Our article on IPAM for mergers and acquisitions covers how to handle them.

When an overlap already exists, fix it deliberately: document both sides, pick the site that’s easiest to re-address, schedule the change, and update DHCP scopes, static assignments, firewall rules, and DNS together.

Documentation That Works Across Every Location

A multi-site network needs a single source of truth. Separate spreadsheets per location guarantee drift, because no one ever updates all of them.

Good multi-site documentation answers these questions for every subnet, at every site:

• What is this subnet for, and which VLAN carries it?
• Which site and region does it belong to?
• Who owns it, and who is allowed to change it?
• How full is it, and what’s statically assigned inside it?
• When was it last verified against what’s actually on the network?

Consistent naming makes all of this easier. When site codes appear in subnet names, device hostnames, and VLAN descriptions, searching and reporting become trivial. Our guide to network device naming conventions has practical examples.

Documentation also has to stay accurate. Manual records fall behind as soon as someone plugs in a new device, which is why scheduled network scanning matters so much at remote sites where no admin is physically present. Automated discovery catches undocumented devices and stale entries before they turn into conflicts—and helps with detecting rogue devices that appear at branches without anyone noticing.

Centralized Visibility, Distributed Access

The teams managing a multi-site network are often multi-site themselves: a core network team at headquarters, local IT at larger branches, and an MSP for smaller locations.

The model that works best is centralized visibility with distributed access:

• Everyone works from the same shared plan, so there’s only one version of the truth.
• Local admins can manage the subnets for their site without being able to change another site’s allocations.
• Changes are visible to everyone immediately, so two admins never assign the same address at the same time.
• Every change is recorded, so you can always see who modified what and when.

This is exactly the problem real-time IPAM collaboration solves, and it’s especially important for distributed IT teams spread across time zones.

Opening a New Site: A Repeatable Checklist

Once your plan is in place, bringing a new location online becomes routine instead of improvised:

• Assign the site a code and a block from the addressing plan
• Create the standard subnets (users, voice, servers, IoT, guest, management)
• Map each subnet to its standard VLAN ID
• Reserve addresses for gateways, switches, access points, and printers
• Configure DHCP scopes to match the documented ranges
• Verify no overlap with existing sites, VPN pools, or cloud networks
• Deploy scanning so the site’s inventory stays accurate
• Record the site owner and local contacts

Using the same checklist every time is what keeps site six looking like site one.

Bringing Existing Sites into Line

Most organizations aren’t starting from scratch. If your current sites grew organically, don’t try to fix everything at once:

1. Inventory first. Scan every site and record what’s actually in use, including the ranges nobody remembers creating.
2. Find the overlaps. These are your highest-risk items, especially between sites that are connected.
3. Design the target plan. Map each existing site to its future block in the new scheme.
4. Re-address opportunistically. Move sites during refreshes, office moves, or maintenance windows rather than all at once.
5. Hold the line. Every new subnet from now on comes from the plan, even while older sites are still being migrated.

Bringing It All Together

Multi-site IP address management isn’t about any one clever technique. It’s about consistency: one addressing plan, one naming convention, one source of truth, and one repeatable process for every location.

Get those in place, and adding a new branch stops being a risk and becomes a checklist.

Subnet24 was built for exactly this kind of network. Nested groups make it easy to organize subnets by region and site, real-time updates keep every admin working from the same data, and the on-premises scanner keeps each location’s inventory accurate—even at branches with no IT staff on site.

Get your free Subnet24 account — no credit card required.

---

Mike Walton is the founder of Subnet24, an IP address management platform. He has 20+ years of experience in IT infrastructure and PKI management.