Site-to-Site VPN Setup: How to Connect Offices Reliably, Step by Step

A site-to-site VPN setup puts an encrypted tunnel between the gateways at two sites. The networks behind them can then talk as one. This guide is for IT managers in India or the GCC who must join offices, stores, plants or warehouses. It follows one link through nine steps and shows no product screens. The page on connecting offices and business locations describes the target state. For the term itself, see the virtual private network page.

Site-to-Site VPN Setup: The Build Order at a Glance

There are nine steps, and the first four happen before anyone touches a device.

1. List each site and what it needs.
2. Size the link from the work each site does.
3. Plan a second path from the start.
4. Agree address ranges before any device work.
5. Bring up the tunnel at both ends.
6. Test the switch to the second path.
7. Monitor the tunnel and both paths.
8. Document each site’s settings.
9. Hand over to the team that runs it.

The planning steps end in paperwork and decisions. Steps 5 to 7 then give you a working link, with a tested second path and alerts in place. After that, the records and the handover let someone other than the builder run it. The article on why office links break down covers the causes. This guide picks up once the firm has decided to join its sites. If a tunnel may not suit every site, read a site-by-site comparison of private circuits, mixed links and tunnels first.

Site-to-Site VPN Setup, Steps 1 to 3: Plan Sites and Paths

A site-to-site VPN setup is easier to run when you answer each site’s planning questions before configuring the first device.

Step 1: List Each Site and What It Needs

Start with one row per site, filled in with the people who work there. Each row holds the site’s public address, or the dynamic name it uses if that address changes. Add the gateway device that will end the tunnel and admin access to that device. Then add a person at the site who can help during a test, and the site’s trading hours.

Some smaller sites in India and the GCC have public addresses that change when the provider decides. A tunnel built to a fixed address can then break. Mark those sites in the list, and plan a dynamic name for each of them from the start.

Step 2: Size the Link From the Work Each Site Does

Size each link from what the site does, and read that from the site’s own use. Note the applications people open, the video calls they join, the backups that leave the site and the busiest hour of the day.

For example, a store that takes orders all day needs a link that carries small, steady traffic without a gap. In contrast, a plant that sends a nightly backup needs room for that backup. A head office hub also carries the traffic of every branch that connects to it.

This guide gives no figures. The right size depends on that use, on the circuits a provider offers and on the limits of the gateway you choose. Write the busiest-hour need next to each site’s row. Then check the provider’s lead time for the circuit before you promise a date. Lead times can differ by city and by provider, and the site list is where that shows up.

Step 3: Plan a Second Path From the Start

A second path is a route that carries the site’s traffic when the first one stops. It can be a second tunnel, a second provider, or both.

The US standards body NIST, in its guidance on IPsec VPNs, says that if a firm designs its network to be redundant, it should design the VPN gateways and management servers to be redundant too. On that reading, a second line into a site adds little if one gateway ends both.

In Signisys’s working view, a second path helps only if it does not share a failure point with the first. Two tunnels over the same line stop together if someone cuts it. Two providers can also still run through one duct. Ask each provider for the physical route and record it. Some designs also bring two tunnels to the same site, and if yours does, set up both.

Site-to-Site VPN Setup, Steps 4 and 5: Addresses and the Tunnel

Device work starts here, and the address plan has to come first.

Step 4: Agree Address Ranges Before Any Device Work

The address range at each site must differ from every other site’s range. If two sites use the same range, traffic between them can fail. A router then has no plain way to tell which site an address belongs to.

The IETF’s private address blocks standard sets aside three ranges for private networks. It also warns that when private networks are joined and some addresses repeat, the hosts holding them need renumbering.

Renumbering a live site can be slow work, so agree the ranges first. Build a small address table with one row per site: the site name, its range and the gateway’s inside address. Then check every row against every other row. If two sites already clash, fix that now, before a tunnel exists between them.

Step 5: Bring Up the Tunnel at Both Ends

NIST describes the gateway-to-gateway model like this: traffic between the two networks passes within the VPN connection between the two gateways. That is the site to site VPN IPsec arrangement this guide builds, with one gateway at each site.

First, choose how the two ends authenticate each other. NIST describes both a pre-shared secret and public-key pairs, with or without certificates. It says a good shared secret has at least 128 bits of entropy, created pseudorandomly.

Then decide how traffic finds its way. In Signisys’s working view, fixed routes written by hand suit a firm with a few sites. Routes learned between gateways suit a firm with more, because a hand-kept list gets harder to correct as the firm adds sites.

Bring the tunnel up at both ends, and read the logs on both gateways before you send anything. When the logs show an established tunnel, send real traffic in both directions from a device at each site.

Site-to-Site VPN Setup, Steps 6 and 7: Test and Watch

Once the tunnel is up, the second path still needs a real test. Someone also has to watch both paths afterwards.

Step 6: Test the Switch to the Second Path

The test is to switch a site to its second path on purpose and see what happens. Agree a window with the site, and have the person from Step 1 there.

Write the pass condition before you start. In Signisys’s working view, a pass has two parts. The site keeps its named applications working on the second path, and traffic returns to the main path when you restore it. Name the applications in the condition, so a ping that answers does not count as a pass.

For the prototype test it recommends before deployment, NIST lists connectivity, authentication, application compatibility, logging and performance among the factors to evaluate. Use that list to check that you have not tested only the easy parts.

Step 7: Monitor the Tunnel and Both Paths

Monitoring can tell you about a fault before a user does. In Signisys’s working view, alerts should cover an outage, the tunnel going down and traffic moving to the second path. A site can run on its backup for weeks without anyone knowing. If the backup then fails too, the site has no path left.

The IETF’s IKEv2 standard describes a liveness check. In it, a gateway tests that the far end is alive so that it does not keep sending to a dead peer. Wire the alert to what the gateways report when that check fails. Also decide who gets the alert and what that person does with it.

Site-to-Site VPN Setup, Steps 8 and 9: Records and Handover

After testing a site-to-site VPN setup, records and a handover let the link outlast the person who built it.

Step 8: Document Each Site’s Settings

Write down each site’s settings in one place, and keep secrets out of that document. When a link misbehaves, this site-to-site VPN configuration record is what a new engineer opens first.

Step 9: Hand Over to the Team That Runs It

Hand the link to a named owner, in writing. In Signisys’s working view, a handover names the owner and where alerts go. It also lists the provider contacts for both paths, the rule for making changes and the date of the next test.

Give the change rule as much care as the contacts. A site that changes a setting alone can break the Step 4 address plan or the Step 5 routes. Decide who may change a link, and who needs to hear about it.

After that, give the owner the records from Step 8 and the log from Step 6. Then run the next alert as a drill, to see that it reaches the right person. Each year after that, review the link with evidence checks for a link already in service.

Four Set-Up Mistakes to Catch Before Go-Live

In Signisys’s working view, these four mistakes are worth catching before a site goes live.

What This Guide Leaves Out

This guide covers site-to-site links only. The security design of each site is a separate decision. Its build is set out in the steps that lock down one branch site. To start it, read why a branch site can be easier to reach than head office. Remote access for staff is a different set-up, covered in remote access for staff. Choosing between link types is also outside its scope. Software-defined routing of site traffic is one option, and the glossary entry on software-defined routing covers it. The guide shows no product screens, because the order holds whatever make of gateway you buy.

Outside help can shorten the build when there are many sites, long circuit lead times or a stretched team. Signisys provides IT infrastructure and networking support and networking design across offices, so read this guide as a vendor’s view. If you would like help building a link or checking one against these nine steps, start with a consultation, where we settle the scope together first. No charge, with a fixed scope.

Site-to-Site VPN Setup FAQ: Questions Before the Build