Connecting two office networks securely over the internet used to require an expensive MPLS circuit and a six-month telco contract. Today, a site to site VPN setup can be done in an afternoon, costs nothing beyond your existing firewalls, and delivers encrypted connectivity that’s good enough for nearly any small or mid-sized business. This guide walks you through it from scratch — what a site-to-site VPN actually is, the parameters you need to match on both ends, vendor-specific configuration examples, and the common mistakes that cause tunnels to fail at 2am.
Written for IT generalists and small business owners who need a working VPN tunnel, not a PhD in cryptography.
What Is a Site-to-Site VPN?
A site-to-site VPN creates an encrypted tunnel between two networks — typically two office locations, or an office and a cloud environment — so devices on each side can reach each other as if they were on the same local network. Unlike a remote-access VPN (where individual users connect from laptops), a site-to-site VPN runs continuously between two firewalls or routers, encrypting all qualifying traffic that crosses between the sites.
The most common protocol used is IPsec, often with IKEv2 for key exchange. Other options exist (WireGuard, OpenVPN site-mode, GRE-over-IPsec), but IPsec remains the universal standard because every enterprise firewall — Cisco, Juniper, Fortinet, Palo Alto, pfSense, SonicWall, Sophos, MikroTik — supports it natively and can interoperate with the others.
When You Need a Site-to-Site VPN (and When You Don’t)
Site-to-site VPNs make sense when:
- You have two or more office locations that need to share file servers, ERP systems, VoIP infrastructure, or access control.
- You need to connect your office to a cloud VPC (AWS, Azure, GCP) for private application access.
- You’re connecting to a partner or vendor network for data exchange (B2B integrations).
- You have a remote workforce that needs predictable, always-on access to internal resources at multiple locations.
Skip site-to-site VPN and consider alternatives when:
- All your applications are in the cloud (SaaS) and accessed via browser — in that case, a SASE or ZTNA platform is a better fit.
- You only need occasional remote access for a handful of users — a client VPN or ZTNA solution is simpler.
- You need guaranteed bandwidth and SLA — internet-based VPNs can’t match dedicated MPLS or SD-WAN with backup transports.
Site-to-Site VPN: How It Actually Works
Every IPsec site-to-site VPN goes through two negotiation phases. Understanding what happens in each phase is the difference between confidently troubleshooting a broken tunnel and randomly clicking buttons hoping something works.
Phase 1 (IKE — Internet Key Exchange)
Phase 1 establishes a secure management channel between the two firewalls. The firewalls authenticate each other (using a pre-shared key or digital certificates), agree on encryption and hashing algorithms, and create a Security Association (SA) used only for the next negotiation step. Think of Phase 1 as “the two firewalls shaking hands and proving who they are.”
Key Phase 1 parameters that MUST match on both sides:
- IKE version (IKEv1 or IKEv2 — always use IKEv2 in 2026)
- Authentication method (pre-shared key or certificate)
- Encryption algorithm (AES-256 recommended)
- Hash algorithm (SHA-256 or SHA-384)
- Diffie-Hellman group (Group 14 minimum; Group 19 or 20 preferred)
- Lifetime (typically 28,800 seconds / 8 hours)
Phase 2 (IPsec)
Phase 2 uses the secure channel from Phase 1 to negotiate the actual data tunnel — the one that will carry your real traffic. It establishes a second Security Association with its own encryption parameters and defines which subnets on each side are allowed through the tunnel (the “interesting traffic” or “proxy IDs”).
Key Phase 2 parameters that MUST match:
- Encryption algorithm (AES-256-GCM preferred; AES-256-CBC acceptable)
- Hash algorithm (SHA-256 minimum)
- PFS (Perfect Forward Secrecy) group (use the same DH group as Phase 1)
- Lifetime (typically 3,600 seconds / 1 hour)
- Local and remote subnets (must be exact mirrors on both ends)
The single most common reason site-to-site VPN setup fails is a mismatch in one of these parameters. Even a single algorithm difference, or a subnet defined as /24 on one side and /16 on the other, will cause the tunnel to fail with a misleading error message.
Pre-Setup Checklist
Before you touch either firewall, gather the following information for both sides:
| Information Needed | Site A Example | Site B Example |
|---|---|---|
| Public IP address (WAN) | 203.0.113.10 | 198.51.100.20 |
| Internal LAN subnet | 192.168.1.0/24 | 192.168.2.0/24 |
| Firewall vendor/model | Juniper SRX320 | Fortinet FortiGate 60F |
| Pre-shared key (strong, 32+ chars) | Same on both sides — generate once, share securely | |
Critical: the LAN subnets on each side must not overlap. If both offices use 192.168.1.0/24, you’ll have to renumber one of them before the VPN will work properly. NAT-over-VPN workarounds exist but cause endless pain — renumber early.
Step-by-Step: Configuring an IPsec Site-to-Site VPN
Here’s the universal workflow that applies to every vendor. We’ll then show vendor-specific examples below.
Step 1: Plan the Tunnel
Document the parameters you’ll use on both sides. Save this somewhere accessible — you’ll reference it during config. Example planning sheet:
- Site A public IP: 203.0.113.10
- Site B public IP: 198.51.100.20
- Site A LAN: 192.168.1.0/24
- Site B LAN: 192.168.2.0/24
- IKE version: IKEv2
- Phase 1: AES-256, SHA-256, DH Group 14, lifetime 28800s
- Phase 2: AES-256-GCM, SHA-256, PFS Group 14, lifetime 3600s
- Pre-shared key: (generate 32+ random characters)
Step 2: Configure Phase 1 on Site A
On Site A’s firewall, create a new IPsec VPN object with:
- Remote gateway = Site B’s public IP (198.51.100.20)
- Authentication = pre-shared key (paste the key)
- Phase 1 parameters as planned
Step 3: Configure Phase 2 on Site A
Define the encryption parameters for the actual data tunnel, then specify the proxy IDs (selectors):
- Local subnet: 192.168.1.0/24
- Remote subnet: 192.168.2.0/24
- Phase 2 parameters as planned
Step 4: Mirror the Configuration on Site B
Repeat steps 2 and 3 on Site B’s firewall, with local and remote values reversed:
- Remote gateway = Site A’s public IP (203.0.113.10)
- Local subnet: 192.168.2.0/24
- Remote subnet: 192.168.1.0/24
- Same pre-shared key, same Phase 1 and Phase 2 parameters
Step 5: Configure Routing
On each firewall, add a static route pointing the remote subnet to the VPN tunnel interface. Some platforms (Fortinet, pfSense) do this automatically via the VPN wizard; others (Juniper, Palo Alto) require explicit configuration.
Step 6: Configure Firewall Policies
The tunnel can be up and routing correctly, but if your firewall policies don’t allow traffic between the LAN zones and the VPN zone in both directions, nothing will pass. Create policies:
- LAN-A zone → VPN zone: allow traffic from 192.168.1.0/24 to 192.168.2.0/24
- VPN zone → LAN-A zone: allow traffic from 192.168.2.0/24 to 192.168.1.0/24
- (Mirror on Site B)
Step 7: Bring the Tunnel Up and Test
On most firewalls, the tunnel will negotiate automatically once both sides are configured. Trigger negotiation by pinging from a device in LAN A to a device in LAN B. Watch the VPN status page — Phase 1 should show “established,” followed by Phase 2.
If ping works in both directions, your IPsec VPN tutorial deployment is complete. If it doesn’t, jump to the troubleshooting section below.
Vendor-Specific Configuration Examples
Juniper SRX (CLI)
On Juniper SRX, the configuration uses Junos OS hierarchical syntax. Here’s a minimal working config for Site A:
# Phase 1 (IKE) configuration
set security ike proposal IKE-PROP authentication-method pre-shared-keys
set security ike proposal IKE-PROP dh-group group14
set security ike proposal IKE-PROP authentication-algorithm sha-256
set security ike proposal IKE-PROP encryption-algorithm aes-256-cbc
set security ike proposal IKE-PROP lifetime-seconds 28800
set security ike policy IKE-POL mode main
set security ike policy IKE-POL proposals IKE-PROP
set security ike policy IKE-POL pre-shared-key ascii-text "YourStrongPSKHere"
set security ike gateway GW-SITE-B ike-policy IKE-POL
set security ike gateway GW-SITE-B address 198.51.100.20
set security ike gateway GW-SITE-B external-interface ge-0/0/0
set security ike gateway GW-SITE-B version v2-only
# Phase 2 (IPsec) configuration
set security ipsec proposal IPSEC-PROP protocol esp
set security ipsec proposal IPSEC-PROP authentication-algorithm hmac-sha-256-128
set security ipsec proposal IPSEC-PROP encryption-algorithm aes-256-gcm
set security ipsec proposal IPSEC-PROP lifetime-seconds 3600
set security ipsec policy IPSEC-POL perfect-forward-secrecy keys group14
set security ipsec policy IPSEC-POL proposals IPSEC-PROP
set security ipsec vpn VPN-SITE-B bind-interface st0.0
set security ipsec vpn VPN-SITE-B ike gateway GW-SITE-B
set security ipsec vpn VPN-SITE-B ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-SITE-B establish-tunnels immediately
# Routing
set routing-options static route 192.168.2.0/24 next-hop st0.0
# Security zones and policies (simplified)
set security zones security-zone vpn interfaces st0.0
set security policies from-zone trust to-zone vpn policy ALLOW-VPN match source-address 192.168.1.0/24
set security policies from-zone trust to-zone vpn policy ALLOW-VPN match destination-address 192.168.2.0/24
set security policies from-zone trust to-zone vpn policy ALLOW-VPN then permit
set security policies from-zone vpn to-zone trust policy ALLOW-VPN-IN match source-address 192.168.2.0/24
set security policies from-zone vpn to-zone trust policy ALLOW-VPN-IN match destination-address 192.168.1.0/24
set security policies from-zone vpn to-zone trust policy ALLOW-VPN-IN then permit
commitVerify with: show security ike security-associations and show security ipsec security-associations.
Fortinet FortiGate (GUI)
Fortinet provides the fastest path to a working tunnel via the VPN Wizard:
- Go to VPN → IPsec Wizard.
- Choose template type: Site to Site. Remote device type: FortiGate (or “Custom” for cross-vendor).
- Authentication: enter the remote gateway IP (Site B’s public IP) and the pre-shared key.
- Local interface: select your WAN interface. Local subnet: 192.168.1.0/24. Remote subnet: 192.168.2.0/24.
- Click Create. The wizard auto-generates Phase 1, Phase 2, routing, and firewall policies.
To use IKEv2 and modern algorithms instead of the wizard defaults, edit the created VPN under VPN → IPsec Tunnels and adjust Phase 1/Phase 2 proposals to match your planning sheet.
pfSense (GUI)
On pfSense, navigate to VPN → IPsec → Tunnels → Add P1. Set Key Exchange Version to IKEv2, enter the remote gateway, choose pre-shared key authentication, and configure Phase 1 algorithms. Then add a Phase 2 entry under that tunnel with the local and remote subnets and Phase 2 algorithms. Apply changes, then add firewall rules under Firewall → Rules → IPsec to permit traffic. The pfSense Netgate documentation has a step-by-step recipe that mirrors this guide closely.
Palo Alto Networks (GUI)
Configure under Network → IPsec Tunnels. Palo Alto requires you to first create a tunnel interface (under Network → Interfaces → Tunnel), an IKE Gateway, and an IPsec Crypto Profile and IKE Crypto Profile before tying them together. Then add a static route pointing the remote subnet to the tunnel interface and create security policies. More steps than other vendors, but the granular control is why enterprises prefer Palo Alto for complex deployments.
Troubleshooting: Why Your Tunnel Isn’t Coming Up
Site-to-site VPN failures usually fall into one of five categories. Diagnose in this order:
1. Phase 1 Won’t Establish
Symptoms: tunnel status shows “down” or “negotiating.” Logs reference IKE_SA failure, “no proposal chosen,” or “authentication failed.”
Causes: mismatched Phase 1 algorithm, wrong pre-shared key, IKE version mismatch, or remote gateway IP unreachable. Run a ping from Site A’s firewall to Site B’s public IP to confirm reachability, then carefully compare every Phase 1 parameter on both sides character-by-character.
2. Phase 1 Up, Phase 2 Down
Symptoms: tunnel shows partial status. Logs reference “no proposal chosen” or “invalid traffic selectors.”
Causes: mismatched Phase 2 algorithms, mismatched PFS group, or mismatched proxy IDs (local/remote subnets). The most common culprit is subnet definition — if Site A says “local 192.168.1.0/24, remote 192.168.2.0/24” and Site B says “local 192.168.2.0/24, remote 192.168.1.0/16”, Phase 2 will refuse to establish.
3. Tunnel Up, No Traffic Passes
Symptoms: VPN status shows both phases established, but ping between LANs fails.
Causes: missing static route on one or both sides, missing or wrong firewall policy, or NAT incorrectly applied to VPN traffic. On most platforms, VPN traffic must be explicitly excluded from outbound NAT. On pfSense, this is the “Outbound NAT” rule; on Juniper SRX, ensure your security policy doesn’t accidentally apply source NAT.
4. Tunnel Works Briefly, Then Drops
Symptoms: traffic flows for a few minutes, then stops. Sometimes recovers after re-keying, sometimes not.
Causes: mismatched lifetime values, NAT-Traversal not enabled when one side is behind NAT, MTU/fragmentation issues. If either firewall is behind NAT (a common ISP setup for SMBs), enable NAT-T on both sides. For MTU issues, lower the tunnel interface MTU to 1400 and enable TCP MSS clamping.
5. Tunnel Works for Some Traffic, Not Others
Symptoms: ping works, but RDP or file shares fail. Or vice versa.
Causes: firewall policy too restrictive on protocol/port, or asymmetric routing where return traffic takes a different path. Verify your firewall policies allow the necessary ports and that the static route covers the full destination subnet.
Site-to-Site VPN vs MPLS: The Cost Reality
A frequent question from SMB owners: “Why would I pay for MPLS when I can build a VPN for free?” Here’s the honest MPLS vs VPN cost comparison for a typical two-site business in 2026:
| Cost Component | Site-to-Site VPN | MPLS Circuit | SD-WAN |
|---|---|---|---|
| Monthly cost (1 Gbps, 2 sites) | $0 (uses existing internet) | $1,400 – $2,800 per site | $1,000 – $1,800 per site |
| Setup cost | $0 – $500 (config time) | $2,500 – $10,000 | $1,500 – $5,000 |
| Bandwidth quality | Best-effort internet | SLA-backed, low jitter | SLA on managed transports |
| Encryption | Yes (IPsec) | No (private network) | Yes (varies) |
| Scalability | Fast (configure tunnel) | Slow (telco install) | Fast (zero-touch) |
| Best for | SMBs, occasional traffic | Latency-sensitive apps | Most modern deployments |
For most SMBs in 2026, the answer is clear: start with site-to-site VPN. If you grow to four or more sites, or you have latency-sensitive applications (VoIP, real-time financial trading, video production), graduate to SD-WAN. MPLS still has a place for very large enterprises with strict SLA requirements, but pure-MPLS deployments are increasingly rare.
Business VPN Solutions: When DIY Isn’t Enough
If you don’t want to manage IPsec tunnels yourself, several business VPN solutions wrap the same underlying technology in a friendlier package:
- NordLayer, Perimeter 81, Twingate, Tailscale Business — managed VPN services priced $7–$15 per user per month. They handle the infrastructure; you just install agents.
- Cloudflare Magic WAN — site-to-site connectivity delivered as a service, no on-premises hardware required beyond a small connector.
- AWS Site-to-Site VPN, Azure VPN Gateway, Google Cloud VPN — cloud-managed endpoints for connecting your office to cloud VPCs. Typically $0.05/hour plus data transfer.
These services trade the cost of a dedicated firewall against the simplicity of zero-maintenance VPN. For VPN connecting a remote workforce to internal apps, the managed services are usually a better fit. For office-to-office, traditional firewall-based IPsec still wins on price and performance.
VPN Security Best Practices for 2026
Even a working VPN tunnel needs basic security hygiene:
- Always use IKEv2, never IKEv1. IKEv1 has known weaknesses and is being deprecated by most vendors.
- Use AES-256 and SHA-256 minimum. AES-128 is acceptable for low-sensitivity traffic but not recommended new deployments.
- Disable older Diffie-Hellman groups. Anything below DH Group 14 is cryptographically weak. Use Group 19 or 20 if both firewalls support it.
- Use a 32+ character random pre-shared key. Generate it with a password manager, not “Companyname2026!”.
- Rotate keys annually. Or move to certificate-based authentication for higher-security deployments.
- Restrict tunnel source/destination subnets. Don’t write a policy that allows “any-to-any” over the tunnel.
- Log Phase 1 and Phase 2 events to a SIEM. Repeated negotiation failures often indicate brute-force attempts.
- Monitor tunnel health. Set up alerts in your monitoring tool when the tunnel drops or fails to re-key.
VPN for Remote Workforce: A Quick Note
This guide covers site-to-site VPN — the network-to-network kind. For a VPN for remote workforce use case (individual employees connecting from home), you’ll want either a client-based remote access VPN (FortiClient, GlobalProtect, AnyConnect, NCP Secure Client) or a more modern Zero Trust Network Access (ZTNA) solution. Both are different architectures from what we’ve covered here, though they share the underlying IPsec or TLS encryption.
Frequently Asked Questions
Can I set up a site-to-site VPN between different firewall vendors?
Yes — IPsec is interoperable. The most common cross-vendor pairings (Cisco-to-Juniper, Fortinet-to-pfSense, SonicWall-to-Palo Alto) work reliably as long as Phase 1 and Phase 2 parameters match exactly. Use IKEv2 and avoid vendor-specific extensions for best interoperability.
Do both sides need a static public IP address?
One side must have a static public IP. The other can use a dynamic IP if your firewall supports “Dynamic DNS” or “Aggressive Mode” IKE. Most modern firewalls support this — just configure the dynamic-IP side as the initiator and the static-IP side as the responder.
How much bandwidth does the VPN consume?
IPsec overhead is roughly 50–80 bytes per packet — usually 5–10% extra bandwidth compared to unencrypted traffic. AES-GCM has slightly less overhead than AES-CBC because it combines encryption and authentication.
Will a site-to-site VPN slow down my internet?
Only the traffic crossing the tunnel is affected. Internet browsing and other non-VPN traffic isn’t impacted. Tunnel performance depends on your firewall’s encryption throughput — most modern firewalls handle 500 Mbps to 5 Gbps of IPsec traffic.
Can I run multiple site-to-site VPNs from one firewall?
Yes. Enterprise firewalls can run dozens or hundreds of simultaneous tunnels. For hub-and-spoke topologies (multiple branches connecting to HQ), this is the standard deployment pattern.
What’s the difference between policy-based and route-based VPN?
Policy-based VPN encrypts traffic that matches specific policies; route-based VPN treats the tunnel as a virtual interface that you route traffic to. Route-based is more flexible, supports dynamic routing protocols, and is preferred for new deployments. Juniper SRX, Palo Alto, and Fortinet all default to route-based; older Cisco ASA configurations are typically policy-based.
How do I know if my tunnel is actually encrypting traffic?
Run a packet capture on the WAN interface while traffic passes through the tunnel. You should see ESP (protocol 50) packets between the two public IPs, with encrypted payloads. If you see your internal subnet IPs in the capture, encryption isn’t working.
Wrapping Up
Site-to-site VPN setup looks intimidating the first time, but the underlying logic is simple: two firewalls agree on encryption parameters in Phase 1, negotiate a data tunnel in Phase 2, route traffic between matched subnets, and let policies decide what’s allowed through. Master those four ideas and you can configure a tunnel between any two firewalls in under an hour.
For the vast majority of small and mid-sized businesses in 2026, site-to-site IPsec VPN over commodity internet is the right answer for connecting offices. It costs nothing beyond what you’ve already spent on firewalls, scales easily as you add sites, and uses encryption strong enough for any sensible compliance regime. Save your MPLS budget for the workloads that genuinely need it, and put the rest of the savings into faster internet and better firewalls.
Want to go deeper? Read our guides on choosing the right business firewall, SASE architecture explained, and setting up VPN on Windows clients.
Leave a Reply