Network setup for new offices and branches
A new site should join the client’s network as if it had always been part of it. We plan its addressing and VLANs, configure the firewall, switches and site-to-site VPN before anything is installed, and stay on the call while it goes in.
- Desk: staff untagged, voice tagged
- Printers and devices
- Access point: management, with staff and guest Wi-Fi tagged
- Uplink to the firewall, every VLAN tagged
- Spare, shut down until needed
The addressing plan comes before the second site
Plenty of first offices run on whatever subnet the router shipped with, very often 192.168.1.0/24. That’s fine until another site needs to reach it. Give the new branch the same default and the tunnel comes up, but nothing crosses it: each end thinks the other’s addresses are local. The workarounds, NAT across the tunnel or renumbering in a hurry, cost more than planning it once.
So the plan starts with the whole network, not the new site: head office, every other branch and the client’s Azure virtual networks. Each site gets its own block with room to grow, laid out so a single route covers it.
An example plan for branch 2
The second octet is the site and the third is the VLAN, so anyone reading an address knows where it is and what it is.
The colours are the ones on the switch above: the plan and the port map describe the same network.
| VLAN | ID | Subnet | What lives there |
|---|---|---|---|
| Staff | 10 | 10.20.10.0/24 | Desktops and laptops, on desk ports and the staff Wi-Fi. |
| Voice | 20 | 10.20.20.0/24 | Desk phones, tagged on the same ports as the PCs. |
| Devices | 30 | 10.20.30.0/24 | Printers, screens and anything else that needs a fixed address. |
| Guest | 40 | 10.20.40.0/24 | Visitor Wi-Fi. Internet only; nothing internal answers it. |
| Management | 99 | 10.20.99.0/24 | Switches and access points, reachable from admin addresses only. |
The calls that decide how a branch behaves
These decisions shape how the site works day to day and what happens when something fails, and we settle them with you before anything is built.
-
Where does internet traffic leave the site?
Usually straight out of the branch’s own connection. Sending everything back through head office makes Microsoft 365 and video calls depend on another office’s link and firewall. Some clients need central filtering or a fixed public address for a service, and then backhauling is a deliberate trade-off, not a default.
-
What still works when the tunnel drops?
If staff get their addresses, resolve names or print through head office, a dropped VPN stops the branch. So we look at what the site depends on across the tunnel, and set up the addressing, DHCP and routing so the branch only depends on head office where you’ve decided it should.
-
How does the carrier hand the service over?
Static or dynamic address, PPPoE or not, a VLAN tag on the handoff, a carrier-managed router or none at all. These details decide how the firewall’s WAN interface is built, and a mismatch is a common reason a new site sits offline on install day.
-
Which networks can talk to which?
VLANs only separate traffic if the firewall rules between them say so. Guest Wi-Fi reaches the internet and nothing else, devices answer the staff who use them, and management interfaces answer administrators rather than everyone on the floor.
-
Do the phones need their own lane?
Call quality is the first thing people notice on a busy uplink. Putting phones on their own VLAN lets the network prioritise voice and keeps phone provisioning apart from the PCs sharing the same desk ports.
-
If there’s a second link, what happens on failover?
A backup service, even a mobile one, only helps if failover is designed: which traffic moves, how the site-to-site VPN re-forms over the other path, and what moves back when the main link returns.
Install day
The equipment goes in already configured, so the visit is about cabling and checking, not decisions. Whoever is on site, your technician or the client’s cabler, puts it in while we work through it with them remotely.
Rack and power
The firewall and switches go in with their configuration already loaded.
Patch by the port map
Each lead goes where the map says, so the documentation and the room agree from the first day.
Bring up the internet link
We check the WAN against the carrier’s details and adjust the firewall if the handoff doesn’t match what was ordered.
Bring up the tunnels
Site-to-site VPN to head office, other branches or Azure, confirmed from both ends.
Test every VLAN
A device on each network gets an address, reaches what it should and is refused what it shouldn’t, such as guest to staff.
Record what was installed
Anything that changed on the day goes into the as-built before it’s handed over.
What’s handed over
-
A configured network
Firewall, routing, switching and site-to-site VPN, built to the plan and tested with the people on site.
-
The addressing and VLAN plan
The site’s place in the client’s whole network: its block, its VLANs and subnets, and what belongs on each. It’s also where the next branch starts.
-
As-built documentation
What’s configured where, as it was installed: devices, interfaces, VLANs, tunnels and the port map.
Hardware we work with. Firewalls, routing and switching from Fortinet, Palo Alto Networks, Cisco, Meraki, SonicWall, WatchGuard, Sophos, Check Point, Juniper and Huawei.
How it’s delivered. Remotely, as a white-label project under your brand or as your named partner. We quote you a fixed price for the agreed scope, and you keep the client and the ongoing service.
Opening a new site for a client?
Tell us about the site and the network it’s joining, and we’ll come back with a fixed price for the work.