A site-to-site VPN connects entire office networks — not just individual devices — so employees at any location access shared resources as if they were on the same LAN. Using a Hong Kong VPS as the WireGuard hub with CN2 GIA routing, organisations connect mainland China offices (Beijing, Shanghai, Shenzhen), Hong Kong headquarters, and international sites through a single, encrypted hub with optimal latency for the Asia-Pacific region.
Architecture: Hub-and-Spoke vs Mesh
<code">
Hub-and-Spoke (recommended for most teams):
Beijing Office ──── HK VPS Hub (CN2 GIA) ──── HK Office
Shanghai Office ──────────┤ ──── Singapore Office
Shenzhen Office ──────────┘
Mesh (advanced — direct office-to-office tunnels):
Beijing ─── Shanghai ─── HK ─── Singapore
└──────────────────────────────┘
Hub-and-spoke is simpler to manage — all traffic routes through the HK VPS hub. Mesh is lower latency for direct office communication but requires O(n²) tunnel configurations. Start hub-and-spoke; migrate specific high-traffic office pairs to direct tunnels later if needed.
Step 1: Prepare the HK VPS Hub
<code">apt update && apt install -y wireguard ufw # Enable IP forwarding (required for routing between sites) echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf sysctl -p # Generate hub keypair cd /etc/wireguard umask 077 wg genkey | tee hub_private.key | wg pubkey > hub_public.key echo "Hub public key: $(cat hub_public.key)"
Hub WireGuard Configuration
<code">cat > /etc/wireguard/wg0.conf << EOF
[Interface]
PrivateKey = $(cat /etc/wireguard/hub_private.key)
Address = 10.100.0.1/24 # Hub's VPN IP
ListenPort = 51820
# NAT for hub-to-spoke routing
# Replace eth0 with your actual interface
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; \
iptables -A FORWARD -o wg0 -j ACCEPT; \
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; \
iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; \
iptables -D FORWARD -o wg0 -j ACCEPT; \
iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; \
iptables -D FORWARD -i wg0 -o wg0 -j ACCEPT
# Beijing Office
[Peer]
PublicKey = BEIJING_OFFICE_PUBLIC_KEY
AllowedIPs = 10.100.0.2/32, 192.168.1.0/24 # VPN IP + Beijing LAN subnet
# Shanghai Office
[Peer]
PublicKey = SHANGHAI_OFFICE_PUBLIC_KEY
AllowedIPs = 10.100.0.3/32, 192.168.2.0/24 # VPN IP + Shanghai LAN subnet
# Hong Kong Office
[Peer]
PublicKey = HONGKONG_OFFICE_PUBLIC_KEY
AllowedIPs = 10.100.0.4/32, 192.168.3.0/24 # VPN IP + HK LAN subnet
# Singapore Office
[Peer]
PublicKey = SINGAPORE_OFFICE_PUBLIC_KEY
AllowedIPs = 10.100.0.5/32, 192.168.4.0/24 # VPN IP + SG LAN subnet
EOF
systemctl enable --now wg-quick@wg0
ufw allow 51820/udpStep 2: Configure Each Office Site (Router/Server)
Each office needs a Linux router (a Raspberry Pi, an old PC, or a cloud VM at that location) running WireGuard. Here is the configuration for the Beijing office:
<code"># On the Beijing office router: apt install -y wireguard # Generate Beijing keypair wg genkey | tee /etc/wireguard/beijing_private.key | \ wg pubkey > /etc/wireguard/beijing_public.key cat > /etc/wireguard/wg0.conf << 'EOF' [Interface] PrivateKey = BEIJING_PRIVATE_KEY Address = 10.100.0.2/24 # Beijing's VPN IP # Route all inter-office traffic through WireGuard: PostUp = ip route add 192.168.2.0/24 via 10.100.0.1 # Route to Shanghai PostUp = ip route add 192.168.3.0/24 via 10.100.0.1 # Route to HK Office PostUp = ip route add 192.168.4.0/24 via 10.100.0.1 # Route to Singapore PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE PostDown = ip route del 192.168.2.0/24 via 10.100.0.1 PostDown = ip route del 192.168.3.0/24 via 10.100.0.1 PostDown = ip route del 192.168.4.0/24 via 10.100.0.1 [Peer] PublicKey = HUB_PUBLIC_KEY # HK VPS public key Endpoint = HK_VPS_IP:51820 AllowedIPs = 10.100.0.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24 PersistentKeepalive = 25 EOF echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf sysctl -p systemctl enable --now wg-quick@wg0
Step 3: Configure LAN Routing on Each Office Router
<code"># The office router must be the default gateway for LAN devices # so that inter-office traffic routes through WireGuard # On Beijing LAN devices (or via DHCP): # Default gateway = Beijing WireGuard router's LAN IP (e.g., 192.168.1.1) # Add static routes on the Beijing router for all other subnets: # These are already in the PostUp commands above # Verify routing: # From a Beijing LAN device, ping the Shanghai LAN: ping 192.168.2.50 # Should reach through HK VPS hub → Shanghai office
Step 4: Monitoring the Hub
<code"># On the HK VPS hub — monitor all connected sites
wg show wg0
# Output shows each peer with:
# - Latest handshake (should be within last 2-3 minutes if active)
# - Transfer bytes (RX/TX per site)
# - Allowed IPs (office subnets)
# Check which sites are connected (handshake < 3 minutes ago)
wg show wg0 latest-handshakes | while read peer ts; do
AGE=$(($(date +%s) - ts))
if [ $AGE -lt 180 ]; then
echo "ONLINE: ${peer:0:12}... (${AGE}s ago)"
else
echo "OFFLINE: ${peer:0:12}... (last seen ${AGE}s ago)"
fi
done
# Bandwidth per site
wg show wg0 transferStep 5: DNS for Split-Horizon Resolution
With all offices on the VPN, you can run internal DNS so that fileserver.company.internal resolves to the correct private IP from any office:
<code"># On the HK VPS hub — run a simple internal DNS server apt install -y dnsmasq cat > /etc/dnsmasq.d/company-internal.conf << 'EOF' # Internal domain — resolves from any office connected to VPN domain=company.internal # Internal service DNS entries address=/fileserver.company.internal/10.100.0.4 # HK Office file server address=/gitlab.company.internal/10.100.0.1 # Gitea on HK VPS address=/monitor.company.internal/10.100.0.1 # Grafana on HK VPS address=/vpn.company.internal/10.100.0.1 # WireGuard hub itself EOF # Only listen on WireGuard interface (not public internet) echo "interface=wg0" >> /etc/dnsmasq.conf echo "bind-interfaces" >> /etc/dnsmasq.conf systemctl enable --now dnsmasq # Each office's WireGuard config adds DNS: # DNS = 10.100.0.1 # Hub VPS as DNS server
Latency by Connection Path
| Office-to-Office Route | Via HK VPS Hub | Internet (no VPN) |
|---|---|---|
| Beijing → Shanghai (via hub) | ~80ms (BJ→HK→SH) | ~30ms direct |
| Beijing → HK Office | ~70ms (BJ→HK VPS→HK Office) | ~45ms direct |
| Beijing → Singapore | ~130ms (BJ→HK→SG) | ~100ms direct |
| HK Office → Singapore | ~110ms (HK→VPS→SG) | ~50ms direct |
Hub-and-spoke adds latency for office-to-office paths — two hops through the hub instead of direct. For latency-sensitive office-to-office communication (VoIP, video conferencing), add direct WireGuard tunnels between those specific sites while keeping the hub for general routing and access to centralised services.
Conclusion
A WireGuard site-to-site VPN with a Hong Kong VPS as the hub provides a cost-effective, encrypted corporate network for Asia-Pacific organisations. CN2 GIA routing ensures mainland China offices (Beijing, Shanghai, Shenzhen) connect to the hub at 30–50ms — far better than routing through US-based VPN services. All inter-office traffic is encrypted, all centralised services (Gitea, monitoring, internal DNS) are accessible from any office via the VPN, and the hub costs a fraction of dedicated MPLS circuit pricing.
Build your corporate VPN: Browse Server.HK Hong Kong VPS plans — a 1–2 GB plan handles WireGuard hub routing for 10+ office sites with minimal CPU overhead.