Connecting Multiple Office Locations With Site-to-Site VPN
When a business expands to a second location, one of the first infrastructure questions is: how do these two offices talk to each other securely? Employees at both sites need access to shared resources - file servers, internal applications, lab equipment, phone systems - without exposing anything to the public internet.
TL;DR: A site-to-site VPN encrypts selected traffic between office networks. I recommend one when locations need steady access to private services, with narrow routes, firewall rules, and monitoring from day one.
The answer, in most cases, is a site-to-site VPN tunnel.
What is a Site-to-Site VPN?
A site-to-site VPN is an encrypted connection between two or more office networks over the public internet. Unlike a remote access VPN used by individual employees, it is usually maintained between gateways at each location and carries traffic for the subnets and services administrators choose to route through it.
How a Site-to-Site VPN Works
A site-to-site VPN creates an encrypted tunnel between two gateways over the public internet. With routes and firewall policy in place, a workstation in one city can reach a server's private address in another city without exposing that server directly to the internet. The sites remain distinct networks even though permitted traffic can pass between them.
This is different from the remote access VPN that individual employees use from home or on the road. A site-to-site tunnel is intended to reconnect automatically and remain available, but it can drop and it only handles traffic selected by routing and security policy.
How I Set These Up
The typical setup uses a firewall appliance at each location running OpenVPN in peer-to-peer mode. One side acts as the server, the other as the client. The tunnel gets its own dedicated subnet so you can route traffic cleanly between the two office networks without address conflicts.
The important decisions are:
- Encryption - I choose a modern AEAD cipher supported by both gateways, usually AES-GCM on hardware with acceleration or ChaCha20-Poly1305 on smaller devices. Use the current recommendation for the VPN implementation you deploy instead of forcing one cipher onto every appliance.
- Protocol - UDP is preferred over TCP for VPN tunnels. TCP-over-TCP creates performance problems under packet loss.
- Routing - Each firewall needs to know which subnets live on the other side of the tunnel so it can route traffic correctly.
- Monitoring - The tunnel should be monitored with automated health checks. A dropped tunnel means both offices are disconnected, and you want to know about it before users start calling.
Why It Matters for Healthcare and Lab Environments
In healthcare and laboratory settings, a site-to-site VPN can be one useful way to protect traffic between locations. Lab instruments at a satellite location may need to report results to a central system, and electronic health records may need to be accessible from every clinic. The right controls come from a risk analysis and the regulations and contracts that apply; no single VPN topology establishes compliance by itself.
I've built these tunnels connecting offices across multiple states, with dedicated monitoring to alert on tunnel drops and latency spikes. The goal is always the same: make it invisible to the end users while keeping the traffic secure. Once the network is solid, it becomes the foundation for everything else - cloud migrations, remote access, and centralized management.
My recommendation is to route only the subnets and services the other site needs, block everything else at both gateways, and monitor the tunnel from day one. A tunnel that carries every network by default creates a larger incident when one location is compromised.
Scaling Beyond Two Sites
Once you have three or more locations, the topology gets more interesting. You can hub-and-spoke everything through a central office, or build mesh connections between sites that need to communicate directly. Each approach has tradeoffs in complexity, latency, and resilience.
Remote access VPN for individual employees can run alongside the site-to-site tunnels on the same firewall, using separate ports and authentication methods. Field technicians, traveling staff, and work-from-home employees all get secure access without affecting the site-to-site infrastructure.
The Bottom Line
For two or three offices that need steady access to private services, I recommend a monitored site-to-site VPN before exposing applications individually to the internet. If the sites only use SaaS and share no private resources, skip the tunnel. It adds complexity without solving a real problem.
If you're opening a new location or need to connect existing offices securely, let's talk about your network.
