Site to site VPN servers connect two or more separate networks, such as a head office and a branch office, so devices on each side can reach resources on the other as if they were on one local network. This article explains what these servers do, how they work, and what to plan before setting one up.
The guide is written for everyday readers and small organizations that want to understand the option before speaking with an IT professional. It covers the components, common deployment models, security settings, and the routine maintenance that keeps such a connection reliable over time.
Why Two Office Networks Sometimes Need to Talk Privately
Many organizations operate in more than one place. A company might have a headquarters in one city, a warehouse in another, and a small sales office across the country.
Each location has its own local network with file shares, printers, and internal applications. Staff at one site often need to reach a system at another site without sending that traffic across the open internet in plain form.
A site to site VPN, short for virtual private network, solves this by building an encrypted tunnel between two gateways over the public internet. Traffic inside the tunnel is scrambled so that anyone observing the connection between the sites sees only unreadable data. The two networks then behave as one extended network for the purposes that matter.
The servers at each end handle the encryption, the authentication of the other side, and the routing of packets into the tunnel. Understanding that role is the first step toward deciding whether this design fits your needs.
What Site to Site VPN Servers Actually Do
A site to site VPN server, often called a VPN gateway, sits at the edge of a local network. It is the device that connects the internal network to the internet and manages the tunnel to the remote gateway.
When a computer at one site sends a packet destined for a subnet at the other site, the gateway recognizes that the destination belongs to the remote network and wraps the packet inside encrypted data.
The wrapped packet travels across the internet to the remote gateway, which verifies its integrity, decrypts it, and forwards the original packet to the correct internal host. Replies follow the same path in reverse. The process is called encapsulation, and the encrypted envelope is what travels across the public network.
Gateways also negotiate the rules of the tunnel at startup. They agree on encryption algorithms, exchange keys, and confirm each other’s identity.
These steps are handled by protocols such as IPsec, which is a suite of standards for securing IP traffic, and IKE, the Internet Key Exchange protocol that negotiates keys. Many modern gateways also support WireGuard, a newer and simpler tunnel protocol.
Core Components of a Site to Site VPN Deployment
A working site to site connection depends on several parts that must agree with one another. Each item below plays a distinct role, and a gap in any one of them can prevent the tunnel from coming up or leave traffic unprotected.
- Two VPN gateways, which may be dedicated appliances, firewalls with VPN features, routers, or software running on a server
- Public IP addresses or stable hostnames for each gateway so the two ends can find one another
- Matching tunnel settings such as encryption method, key lifetime, and authentication method on both sides
- Defined subnets at each site, so the gateways know which internal address ranges to route through the tunnel
- Firewall rules that allow the VPN traffic and permit the relevant internal traffic to pass in both directions
Configuration details differ between vendors, but the logic is the same everywhere. Before any device is set up, write down each site’s address ranges, the gateway addresses, and the agreed security settings. Keeping that record in one place makes troubleshooting far faster later, and it helps whoever maintains the network after the original installer has moved on.
Choosing the Right Deployment Model
Site to site VPN servers can be deployed in several ways, and the choice shapes cost, control, and how much work the organization must do. The main options are hardware appliances, software gateways running on general-purpose servers, and managed or cloud-hosted gateways offered by infrastructure providers. Each has trade-offs in performance, maintenance, and flexibility.
Hardware appliances are purpose-built devices that handle encryption efficiently and usually come with a management interface. Software gateways give more flexibility and can run on virtual machines, but the operator must keep the operating system and gateway software patched. Cloud-hosted gateways reduce hardware work but place part of the setup in a provider’s environment, which should be evaluated carefully.
Selecting a model is easier when you answer a few questions first. How many sites need to connect? How much traffic flows between them? Who will manage the equipment? What level of control does the organization require? Performance figures vary widely by hardware and configuration, so check vendor documentation rather than relying on general claims.
Security Settings That Matter Most
Encryption protects the contents of the tunnel, but the strength of the overall setup depends on several choices made during configuration. Use modern, widely reviewed algorithms for encryption and integrity checking, and avoid legacy options that have known weaknesses. Vendors publish recommended cipher suites, and those recommendations change over time, so review them when you configure a new gateway.
Authentication determines whether each gateway can trust the other. Certificate-based authentication, where each side presents a digital certificate issued by a trusted authority, is generally stronger and easier to manage at scale than a shared secret written into both configurations. Pre-shared keys remain common in small setups, but they must be long, random, and kept confidential.
Perfect forward secrecy is a property that generates fresh session keys so that compromise of a long-term key does not expose past traffic. Enabling it is a sound default. Also restrict the tunnel so only the necessary subnets and ports are reachable, following the principle of least privilege.
Planning and Configuring the Connection Step by Step
A careful, documented approach prevents most problems. The subsections below walk through the planning and configuration stages in a sequence that suits small and medium networks. Adjust the details to match your equipment and your organization’s policies.
Mapping Addresses and Subnets Before Configuration
Begin by listing every internal subnet at each site, including the address ranges used by servers, workstations, printers, and guest networks.
The two sites must not use overlapping address ranges, because the gateways cannot tell which side a packet belongs to when the addresses are the same. A common cause of failed connections is two offices that both use the same default home-style range.
Record the public IP address or hostname of each gateway as well. If a site has a dynamic public address that changes, plan for that, either by using a dynamic DNS name or by choosing a provider that offers a static address. Writing these details down in a shared document reduces errors during setup.
Decide which subnets should be reachable across the tunnel and which should stay local. Limiting the tunnel to what is genuinely needed reduces exposure and makes the firewall rules easier to audit later.
Setting Up the Gateways and Tunnel Parameters
Configure each gateway with the agreed encryption and authentication settings, the local and remote subnets, and the peer address.
Both sides must match on key parameters, so it helps to configure one gateway, then mirror the settings on the other while checking each value against the written plan. Many connection failures trace back to a single mismatched setting such as a lifetime or a cipher choice.
Once the tunnel is defined, bring it up and check its status in the gateway’s management interface. Look for an established security association or an equivalent indicator. If the tunnel does not come up, read the gateway logs, which usually state whether the problem is authentication, a proposal mismatch, or unreachable peers.
After the tunnel is established, test connectivity with simple tools. A ping from a device at one site to a device at the other confirms basic reachability. Then test the specific applications that depend on the link, since a ping success does not guarantee that file sharing or database access will work.
Confirming Firewall Rules and Routing
Firewalls at both sites must allow the traffic that the tunnel carries. Typically this means permitting the protocol and ports used by the VPN itself, then allowing the internal traffic that should cross the tunnel in each direction. Be precise: a rule that allows all traffic from the remote subnet is broader than most organizations need.
Routing ensures that packets destined for the remote subnet reach the local gateway. Depending on the design, this may involve a static route on internal routers, or the gateway may advertise the routes automatically. Check that devices at each site use the gateway as their path to the other network, and verify that return traffic follows the same tunnel.
Document the final rules and routes in your network records. Future changes to one site often break the tunnel silently, and a clear record lets the next administrator find the cause quickly.
Monitoring, Maintenance and Ongoing Reliability
A site to site connection is not a one-time project. Gateways need regular attention to stay secure and dependable. Keep the gateway firmware or software updated, since vendors release fixes for vulnerabilities in VPN software, and unpatched gateways are a common entry point for attackers. Schedule updates during quiet periods and test them on a non-production gateway first when possible.
Monitoring helps catch problems early. Track whether the tunnel is up, how often it renegotiates, and whether error messages appear in the logs.
Some organizations set alerts that notify staff when a tunnel drops, so that an outage is noticed before users report it. Keep logs for a period your policy requires, and restrict who can read them, since logs can reveal network layout and user activity.
Plan for certificate and key renewal. Certificates expire, and pre-shared keys should be rotated periodically under a documented schedule. An expired certificate is one of the most common causes of a sudden, unexplained outage, so calendar the renewal date well in advance.
Common Problems and How to Approach Them
Most site to site VPN problems fall into a few categories, and recognizing them speeds recovery. The tunnel fails to establish, traffic flows in only one direction, the connection works but applications are slow, or the tunnel comes up and then drops repeatedly. Each pattern points to a different area to examine.
When the tunnel will not establish, check the authentication settings, the peer addresses, and whether the internet path between the gateways is open for the VPN protocol.
A firewall between the gateway and the internet is a frequent culprit. When traffic moves in only one direction, look at routing on the return path and at firewall rules on the receiving site.
Slow performance often comes from the capacity of the gateway hardware, from the internet connections at either site, or from packet fragmentation caused by the tunnel overhead.
Adjusting the maximum transmission unit, a setting that controls the largest packet size, sometimes helps. Test the underlying internet speed before blaming the tunnel, since a slow site connection can look like a slow VPN.
Limits and Responsibilities to Keep in Mind
A site to site VPN protects traffic while it crosses the public internet between the two gateways. It does not protect data once it leaves the remote network, and it does not replace endpoint security, access control, or application-level encryption. A device that is infected or misconfigured can still cause harm even when the tunnel itself is working correctly.
The tunnel also creates trust between two networks. Anyone with access to one site gains a path toward the other, so the security of both sides matters. Limit the subnets shared across the tunnel, require strong authentication for administrative access to the gateways, and treat the gateway configuration as sensitive material.
Legal and contractual obligations may also apply, especially when data about customers, employees, or health and financial records crosses sites. Check your organization’s policies and any applicable regulations, and involve the appropriate staff or advisors before transmitting regulated data across a new link.
Questions to Ask Before Choosing a Gateway
Before buying equipment or engaging a provider, a short list of questions helps you compare options fairly. The answers reveal whether a product fits your sites, your skills, and your budget.
- Which tunnel protocols and encryption standards does the gateway support, and are they current?
- How is the device updated, and does the vendor publish security advisories in a timely way?
- Can the gateway handle the expected number of tunnels and the throughput your sites need?
- Does the management interface support strong authentication and logging you can review?
- What support is available, and what does the maintenance agreement cover over time?
Ask vendors or providers to explain these points in writing, and compare their answers against your written requirements. Avoid relying on marketing summaries alone. If your organization lacks in-house expertise, consider working with a qualified network professional for the initial design and a review of the final configuration, since a careful review often prevents costly mistakes later.
Next Steps for a Secure Multi-Site Network
If you are considering a site to site connection, begin with a written inventory of your sites, their subnets, and the resources that must be shared. Decide which deployment model fits your skills and budget, then draft the security settings you intend to use. This preparation turns an abstract idea into a concrete plan that others can review.
Test the design in a limited pilot before connecting every site. Choose one pair of locations, confirm the tunnel, verify the applications, and document what you learned. Expanding gradually lets you refine the configuration and build confidence in the maintenance routine before the whole organization depends on the link.
Schedule regular reviews. Revisit the tunnel settings, firewall rules, and certificates at least once a year, and whenever a site changes its network layout. A site to site VPN that is checked and maintained on a steady schedule will serve your organization far better than one that is configured once and forgotten.