Last Updated: October 25, 2026
Quick Summary
To set up a site-to-site VPN for a small office, configure two IPsec-capable routers with non-overlapping LAN subnets, matching phase 1 and phase 2 settings, and a static route sending the remote subnet through the tunnel. Allow IKE (UDP 500 and 4500) and ESP through both firewalls, then test end-to-end before relying on it.
- Each site needs a VPN-capable router, a public IP or dynamic DNS, and different LAN subnets.
- Both routers must match on pre-shared key, IKE version, encryption, hash, and DH group.
- Phase 2 policies must mirror each other, pairing local and remote subnets on both sides.
- Allow UDP 500 and 4500 plus ESP through the firewall, and check rule order first.
- Keep a spare pre-configured router and a second WAN link on the main office for recovery.
Table of Contents
- What a Site-to-Site VPN Does for a Small Office
- Site-to-Site VPN Requirements: Hardware, Addresses, and Access
- IPsec VPN Setup Between Two Routers: A Step-by-Step Walkthrough
- IP Addressing, Subnet Overlap, and Routing Decisions
- VPN Tunnel Testing: How to Prove the Link Works
- Site-to-Site VPN Troubleshooting: Common Failures and Fixes
- Security Choices, Monitoring, and Recovery for Small Offices
- Choosing Routers and Getting Deployment Support
- Frequently Asked Questions
What a Site-to-Site VPN Does for a Small Office
A site-to-site VPN is a permanent, encrypted tunnel between two office networks that lets each side reach the other's shared resources as if they were in the same building. This guide covers hardware, addressing, IPsec configuration, routing, testing, and recovery.
A shared drive in the main office opens on a laptop in the branch office, and printers, file servers, and internal tools stay reachable without exposing any of them to the open internet.
What most guides miss is the failure mode. The National Cyber Security Centre's guidance on VPNs notes that VPNs need maintenance, and a VPN failure can cause organization-wide outages.
Site-to-Site VPN Requirements: Hardware, Addresses, and Access
VPN gateway. Each site needs a router that supports IPsec, check the spec sheet before buying.
Non-overlapping subnets. If both offices use the same LAN range, the tunnel cannot route correctly.
Credentials and records. Pre-shared keys, admin passwords, and a simple network diagram belong in a password manager, not a sticky note.
A quick readiness checklist:
- Two routers with IPsec support
- Public IP or dynamic DNS at each site
- Different LAN subnets at each office
Fix any unchecked box before proceeding, retrofitting addressing later means redoing the tunnel.
IPsec VPN Setup Between Two Routers: A Step-by-Step Walkthrough
The process runs in a fixed order: document, configure, route, then test. Skip a step and you will debug in the dark. For a deeper MikroTik RouterOS ISP routers setup guide, the linked article walks through router configuration step by step.
Step 1: Document Both Office Networks
Write down four values for each site before you open a config screen:
| Field | Main office (example) | Branch office (example) |
|---|---|---|
| LAN subnet | 192.168.10.0/24 | 192.168.20.0/24 |
| LAN gateway | 192.168.10.1 | 192.168.20.1 |
| WAN address | 203.0.113.10 (static) | branch.example.com (DDNS) |
| Router model | , | , |
Confirm the subnets differ. Confirm which side has the stable public IP. This one page saves hours later.
Step 2: Configure Phase 1 (the IKE peer) on Each Router
Phase 1 is the negotiation that proves the two gateways are allowed to talk. On each router, create an IPsec peer pointing at the other site's WAN address (or DDNS name). Both ends must agree on every field below, or phase 1 never comes up:
- Authentication method: pre-shared key (PSK) for a small office; certificate-based authentication if you already run an internal CA.
- Pre-shared key: a long random string, identical on both sides, stored in a password manager.
- IKE version: IKEv2 where both routers support it; IKEv1 only if an older device forces it.
Start with a single proposal and add a weaker one only if a legacy device refuses to negotiate. Never enable aggressive mode, it exposes the PSK.
Step 3: Configure Phase 2 (the tunnel policy) on Each Router
Phase 2 defines what traffic is allowed through the tunnel. On each router, create a policy that pairs the local subnet with the remote subnet:
- Local subnet: this site's LAN range (for example, 192.168.10.0/24).
- Remote subnet: the other site's LAN range (for example, 192.168.20.0/24).
- Protocol: ESP.
The two policies must mirror each other: the main office says "192.168.10.0/24 → 192.168.20.0/24"; the branch says "192.168.20.0/24 → 192.168.10.0/24". If one side lists the wrong subnet, phase 2 negotiates but no traffic passes, the classic "tunnel up, nothing works" symptom.
Step 4: Add Routes and Firewall Rules
Add a static route on each router that sends the remote subnet through the tunnel, for example, on the main office router, "192.168.20.0/24 via the IPsec interface." Then allow IKE (UDP 500 and 4500) and ESP through the firewall on both WAN interfaces. For a focused MikroTik firewall setup guide covering home and small-office rules, see the linked walkthrough.
Watch out: a firewall rule that drops IPsec before the tunnel policy is evaluated will make a perfectly good tunnel look dead. Check rule order first.
Step 5: Bring Up the Tunnel and Verify Each Phase
From the main office router, initiate the tunnel to the branch peer. Watch the IPsec status page on both ends: phase 1 should show established, then phase 2 with the correct subnets listed. If phase 1 is up but phase 2 is not, re-check the subnet definitions on both sides.
Step 6: Test End-to-End Before You Walk Away
Ping the remote router's LAN address from the local router, then ping a known device (a file server, a printer) from a PC on the other side. Run a traceroute to confirm traffic follows the tunnel and not the internet. Open a shared folder from the branch office. Only then is the tunnel real.
IP Addressing, Subnet Overlap, and Routing Decisions
Subnet overlap stops more site-to-site VPN projects than any other problem. If the main office and the branch both run 192.168.1.0/24, the routers cannot tell local traffic from remote traffic.
Routing follows the same logic: each router needs one explicit static route saying "the other office lives behind the tunnel," rather than broad routes that might catch internet traffic.
A short decision table helps:
| Situation | Action |
|---|---|
| Same subnet at both sites | Renumber one site first |
| One site on dynamic IP | Use dynamic DNS |
| Multiple branch offices | Give each a unique subnet |
| Tunnel up, no traffic | Check static route and firewall order |
Get the addressing right once and every future site becomes easier.
VPN Tunnel Testing: How to Prove the Link Works
A tunnel that shows "established" is not proof of working connectivity. Test in layers: check the IPsec status page on each router (phase 1 and phase 2 both up), ping the remote router's LAN address from the local router, then ping a known device such as a file server from a PC on the other side.
Keep a short test log with the date and result; when something breaks in six months, it tells you what "normal" looked like.
Site-to-Site VPN Troubleshooting: Common Failures and Fixes
Site-to-site VPN troubleshooting starts with one question: does the tunnel come up at all? If phase 1 fails, the problem is settings or reachability. If phase 1 works but phase 2 fails, suspect the subnet definitions.
The usual suspects:
- Mismatched pre-shared key. One typo kills the tunnel silently.
- Wrong encryption or hash settings. Both ends must match exactly.
- Overlapping subnets. The tunnel comes up but no traffic passes.
Work through them in that order. Most issues resolve in the first three.
Security Choices, Monitoring, and Recovery for Small Offices
Security decisions for a small office tunnel come down to three choices: how strong the encryption is, who holds the keys, and what the tunnel is allowed to reach. Below are the settings to pick, the checks to schedule, and what to do when the tunnel dies at 9 a.m. on a Monday. Establishing these protocols provides the foundation for robust business network security, which remains a critical component of maintaining a resilient infrastructure.
Security: The Settings That Actually Matter
Use current IPsec settings, not legacy options kept alive for one old device:
- IKEv2 with AES-256 and SHA-256. IKEv1 and SHA-1 exist only for legacy hardware; if a device forces them, isolate that device on its own tunnel rather than weakening the main one.
- Diffie-Hellman group 14 or higher. Group 2 and group 5 are deprecated.
- No aggressive mode. Aggressive mode transmits a hash of the pre-shared key in the clear; a captured handshake can be attacked offline.
Rotate pre-shared keys on a schedule (annually is a reasonable baseline for a small office) and store them in a password manager, not in a config backup on a shared drive.
Monitoring: Catch the Quiet Failure
A tunnel can fail quietly, and staff notice only when a shared drive stops opening. Build three cheap checks into your routine:
- Scheduled ping to the remote gateway's LAN address from each router, every few minutes. A drop in reply rate is the earliest signal.
- IPsec status page review, phase 1 and phase 2 should both show established. A tunnel that renegotiates every few minutes is flapping, usually from a mismatched lifetime or an unstable WAN link.
- Alert on tunnel-down events. Most small-business routers can send an email or syslog message when a tunnel drops; route it to a mailbox someone reads.
Keep a one-line log of tunnel state at the start and end of each business day, so you know what "normal" looked like when something breaks.
Recovery: What Happens When the Tunnel or the ISP Fails
Plan for two failure modes before they happen:
- Gateway failure. If the branch router dies, the branch loses access to the main office but keeps its own internet. Keep a spare router pre-configured with the same IPsec profile and a recent config backup, so swap-in is a cable change, not a rebuild.
- ISP or WAN failure. If the main office loses its internet connection, the tunnel drops and the branch loses access to shared resources. A second WAN link on the main office router, even a consumer connection, with a failover route keeps the tunnel reachable. If the branch has a dynamic WAN address, confirm DDNS is updating before you rely on it during an outage.
Keep a written rollback plan: know how to disable the tunnel and restore normal internet routing if a change goes wrong. The rollback is usually one firewall rule and one static route, write down which ones, and where they live on each router.
Choosing Routers and Getting Deployment Support
Pick routers that support IPsec in hardware, have enough ports for your LAN, and fit your rack or desk. For a wiring closet, the L009UiGS-RM mounts up to four routers in a single 1U space and adds 2.5G SFP support.
For a closer look at the hEX S (2025) specifications, the product page lists ports, CPU, and power details. If you are sourcing several units for multiple offices, MikroTik Wholesale Pricing Products lets you compare the range in one place.
BI-DISTRIBUTION supplies MikroTik routers and network gear, and our team provides expert support in network design and deployment. If you would rather have the tunnel built and tested for you, contact our team to talk through your sites.
Frequently Asked Questions
Do both offices need static public IP addresses for a site-to-site VPN?
Not always. One side can use a dynamic public IP address if the other side supports dynamic DNS or aggressive mode, but a static address on at least one gateway makes the tunnel far easier to maintain. For a small office, the simplest and most reliable design is a static public IP on each VPN gateway, with a dynamic DNS hostname as a fallback. Confirm your ISP assignment before configuration, and document the addresses so troubleshooting starts from known values.
What is the difference between a site-to-site VPN and a remote-access VPN?
A site-to-site VPN connects two networks, such as a main office LAN and a branch office LAN, through a VPN gateway at each end. Users do not install client software. A remote-access VPN connects an individual device, such as a laptop or home office computer, to the office network through a VPN client. For linking two small offices with shared resources, site-to-site is the better fit because it is transparent to staff and keeps the tunnel up without user action.
Why is my site-to-site VPN tunnel not connecting?
Start with the most common causes: mismatched pre-shared keys, mismatched encryption or authentication settings between the two routers, overlapping LAN subnets, and firewall rules blocking IKE or IPsec traffic. Check the VPN gateway logs on both sides for phase 1 and phase 2 errors. Confirm that each router can reach the other's public IP address, and verify that the IP ranges on each side do not overlap. A structured site-to-site VPN troubleshooting pass usually finds the issue in the logs.
How do I test whether a site-to-site VPN is working?
Run VPN tunnel testing from both ends. From a computer on one office LAN, ping a device on the other office LAN by IP address, then use traceroute to confirm traffic passes through the tunnel rather than the internet. Check the router's IPsec status page for active security associations. Test a shared resource such as a file server or printer. Repeat the tests after a router reboot to confirm the tunnel reconnects automatically.
Two offices, one encrypted tunnel, and a short checklist stand between your branch and its shared files. BI-DISTRIBUTION can supply the routers and handle the design, installation, and configuration, backed by 24x7 support from our technical teams. Get started with BI-DISTRIBUTION and put both offices on one secure network.
