A site-to-site VPN between two offices, without the surprises

Connecting a second office to the first is usually a site-to-site VPN between the two firewalls. Bringing the tunnel up takes an hour. Making the two offices behave as one network is the rest of the week, and the difference is almost entirely in things decided before the tunnel exists.

The two offices must not share an address range

Both offices were installed with the default 192.168.1.0/24, because every router ships with it. A tunnel between two identical ranges cannot route: a packet for 192.168.1.20 is delivered locally at both ends. The fix is to re-address one office, and it is much easier before the tunnel than after. Choose ranges that are distinct and unusual — 10.20.0.0/16 for one site, 10.30.0.0/16 for the other — so a third office, or a colleague's home router, does not collide next year.

Routing is a decision, not a side effect

Decide what crosses the tunnel. Everything, or only the server VLAN? Should the branch's guest Wi-Fi reach the head-office file server? It should not, and it will unless the tunnel's traffic selectors say otherwise. Write the list of what each site may reach on the other, and configure the tunnel to carry exactly that.

DNS is what makes it feel like one network

Staff at the branch type \\fileserver, not an address. That name has to resolve at the branch, which means the branch's DHCP must hand out a DNS server that knows it — the head-office domain controller across the tunnel, or a local resolver forwarding to it. Skip this and the tunnel is up, the ping works, and nobody can open anything.

The tunnel will drop; decide what happens then

Dead-peer detection on both ends, so a tunnel that has silently died is torn down and rebuilt rather than sitting "up" carrying nothing. A keepalive, so an idle tunnel is not timed out by an ISP's connection tracking. And a monitor that alerts on tunnel state — because the first report of a dead tunnel is otherwise a branch that cannot print.

The Tuesday problem

One branch's tunnel dropped for four minutes every Tuesday at 2 am. It was the ISP's scheduled maintenance renewing the DHCP lease on the WAN, and the branch firewall's public address changed each time. Two answers: a static public address at both ends, which is worth its small monthly cost; or a tunnel configured with a dynamic-DNS name on the branch side and the head office set to accept it. Static is better. A tunnel between two changing addresses is a tunnel that will fail on a night nobody is watching.

Bandwidth and the file server

The tunnel is as fast as the slower office's uplink, minus overhead. Opening a 200 MB drawing across it takes a while, and that is not a VPN problem. If the branch works heavily on head-office files, the answer is a file server at the branch that synchronises, not a faster tunnel.

Checklist before calling it done

• Distinct address ranges at both sites, documented.
• Traffic selectors carrying only what was agreed, in both directions.
• Name resolution working from a branch laptop for head-office names.
• Dead-peer detection and keepalives on both firewalls.
• Static public addresses, or dynamic DNS with the peer set to accept it.
• The tunnel's state monitored, with an alert that reaches a person.