Last updated: July 2026
A business running two, three, or four branch offices usually starts with ad-hoc VPN tunnels between sites, or worse, unencrypted site-to-site connections over the public internet. The cleaner fix is a VPS as VPN gateway hub for multiple offices: one central WireGuard server that every branch connects to, turning a tangle of point-to-point links into a single, manageable hub-and-spoke network. This guide walks through building that hub on a KVM VPS, from picking a location to writing the peer configs for each site.
VPS as VPN Gateway Hub Multiple Offices: The Hub-and-Spoke Advantage
Connecting Office A directly to Office B, then B to C, then C to D creates a mesh that gets harder to manage with every new location. Firewall rules multiply, key rotation becomes a spreadsheet exercise, and if one office's router goes down, routes to other sites can break with it. A single VPS acting as the VPN gateway hub eliminates that sprawl: every office holds one tunnel to the hub, the hub routes traffic between offices, and adding a fifth location means adding one peer, not four new tunnels. This is also the core setup pattern behind a site-to-site vpn vps setup that a solo IT admin can actually maintain without dedicated network staff.
Choosing the Right VPS for the Job
The hub itself doesn't need to be a beast of a server, but it does need full root access, since WireGuard is a kernel module and its configuration lives outside any control-panel abstraction. A KVM VPS with full root — like the plans on x-zoneservers.com/vps-hosting — checks that box. For most 2-4 office setups, a Micro tier (4GB RAM, 2 vCPU, 80GB SSD) handles WireGuard's encryption overhead comfortably, since the protocol is lightweight compared to OpenVPN's userspace stack; busier deployments with heavier east-west traffic can size up to Starter or Basic. Unmetered 1 Gbps bandwidth matters more than raw CPU here, since the hub is relaying, not just terminating, traffic between every branch.
Picking a Central Datacenter Location
Where the hub physically sits affects latency for every office connecting to it, so this isn't a decision to make on autopilot. If a company's branches are clustered in Western Europe, a Frankfurt or Amsterdam hub keeps round-trip times low for all of them; a US-heavy footprint points toward Ashburn instead. With 12 datacenter cities across Europe and the US to choose from — each with its own location page listing specs for that site — the right approach is to estimate the geographic midpoint of the offices rather than defaulting to whichever city is cheapest.
Step 1: Provision and Harden the Hub VPS
Deploy the VPS, choose Ubuntu or Debian, and log in as root. Since KVM VPS deployment on X-Zone Servers completes in under 60 seconds, the hub can be up and reachable before IT staff have finished writing down IP ranges for each office.
- Update packages and install WireGuard:
apt update && apt install wireguard - Enable IPv4 forwarding (and IPv6 forwarding, since dual-stack networking is supported): set
net.ipv4.ip_forward=1andnet.ipv6.conf.all.forwarding=1in/etc/sysctl.conf, thensysctl -p - Generate the hub's key pair:
wg genkey | tee hub_private.key | wg pubkey > hub_public.key - Lock SSH down to key-based auth only before opening the WireGuard UDP port in the firewall
Step 2: Write the Hub Configuration
The hub's
/etc/wireguard/wg0.conf defines the internal VPN subnet and lists each office as a peer. A typical hub interface block looks like this:[Interface]— hub's private key, an internal address like10.10.0.1/24, andListenPort = 51820- One
[Peer]block per office — each office's public key, itsAllowedIPs(its local LAN subnet plus its assigned VPN IP), and noEndpointline if that office's public IP changes frequently PostUp/PostDownrules usingiptablesornftablesto masquerade and forward traffic between peers
Bring the interface up with
wg-quick up wg0 and enable it on boot with systemctl enable wg-quick@wg0.Step 3: Configure Each Branch Office as a Spoke
On the router or a small gateway device at each office, install WireGuard and generate that site's own key pair. Each office's config points a single
[Peer] entry back at the hub: the hub's public key, the hub's public IP as Endpoint, and AllowedIPs set to the internal VPN range plus whichever other office subnets that location needs to reach. PersistentKeepalive = 25 is worth setting on every branch, since most office routers sit behind NAT and the tunnel will drop silently without a keepalive. Repeat this for each site — this is the wireguard vps office locations pattern that scales linearly instead of exponentially as offices are added.Routing and IP Addressing Across Offices
Assign each office a distinct subnet before writing any config — trying to renumber four LANs after the fact is far more painful than planning it up front.
| Site | Local LAN | VPN IP (on wg0) |
|---|---|---|
| Hub (VPS) | — | 10.10.0.1 |
| Office A | 192.168.1.0/24 | 10.10.0.2 |
| Office B | 192.168.2.0/24 | 10.10.0.3 |
| Office C | 192.168.3.0/24 | 10.10.0.4 |
With this table in place, each office's
AllowedIPs can be filled in without guesswork, and the hub's routing table cleanly maps every packet to the right tunnel.Securing the Hub Against Abuse and Attack
A VPN hub is a single point of failure by design, so it deserves more hardening than a typical web server. Restrict the WireGuard UDP port to expected traffic only, keep SSH off the default port or behind key-only auth, and rotate peer keys on a schedule rather than never. Because the hub sits on the open internet with a public IP, it's also a target for volumetric attacks aimed at knocking the whole office network offline — DDoS protection running at the network edge, included on every plan at Layer 3, 4, and 7, is what keeps the tunnel up during an attack rather than the VPS itself becoming the outage.
Monitoring the Hub Over Time
Once four offices depend on one VPS for connectivity, uptime visibility stops being optional. Watch bandwidth trends on the hub's network interface to catch a misbehaving peer or a saturated link before users start complaining, and keep an eye on the Tier-1 backbone path quality that carries every peer's traffic to the hub.
wg show on the hub gives a quick live view of handshake times and data transferred per peer, which is usually enough to spot a stale or dropped tunnel at a glance.Scaling Past Four Offices
The hub-and-spoke model keeps working as the business grows — a fifth or sixth office is one more
[Peer] block on the hub and one more spoke config at the new site, not a redesign. If the hub VPS starts showing CPU pressure from encrypting traffic for a growing number of sites, resizing to a larger tier is the straightforward next step, since the underlying WireGuard configuration doesn't change when the server underneath it gets bigger.Verdict
For a business with 2-4 branch offices, a single well-placed KVM VPS running WireGuard is a more maintainable answer than a mesh of point-to-point tunnels — one hub, one set of peer configs, and a clean path to add more sites later. X-Zone Servers provides the full-root KVM access, IPv6 dual-stack support, unmetered 1 Gbps bandwidth, and a choice of 12 datacenter cities needed to place that hub exactly where the offices need it.