Site-to-Site VPN Setup for Small Businesses

When two offices need to share files, applications, phones, or private services, a site-to-site VPN can connect their networks securely over the internet. It creates an encrypted path between firewalls, so employees at one location can reach approved resources at another location without exposing those systems publicly.

A reliable setup starts before anyone changes firewall settings. You need a clear IP plan, matching security settings, documented access rules, and a way to test the connection after deployment. This guide walks through the process for small businesses with a main office, branch, warehouse, or private cloud environment.

Key Takeaways

• Use separate, non-overlapping private subnets at every location.
• Prefer IPsec with IKEv2 and modern encryption, such as AES-GCM.
• Use unique credentials, certificates where practical, and MFA for firewall management.
• Define permitted networks and services before creating firewall rules.
• Treat overlapping subnets as a design problem that may require NAT or renumbering.
• Test business applications, logs, failover behavior, and tunnel recovery after setup.

What a Site-to-Site VPN Connects

A site-to-site connection links entire networks, not individual users. Each firewall creates and maintains the tunnel, while local devices use normal routes to reach approved remote subnets.

Site-to-site versus remote-access VPN

A remote-access VPN connects an employee's laptop to a business network. A site-to-site VPN connects one office network to another. For example, a Fort Myers office might connect to a warehouse, a second branch, or a private cloud network.

These designs solve different problems. Remote access needs user identity, device checks, and individual permissions. Site-to-site connectivity usually authenticates the two firewalls with certificates or a pre-shared key, then applies rules between defined networks.

MFA still matters, but apply it to firewall administrators, cloud management portals, remote users, and vendor accounts. Don't assume MFA is part of the IPsec tunnel handshake unless the selected platform supports that feature.

For related remote-user controls, review this guide to secure remote access for small businesses.

Information to collect from each location

Before configuration, document the details below for every office:

• Public WAN address, ISP, gateway, and whether the address is static
• Firewall manufacturer, model, firmware version, and support status
• Local subnet and VLAN list
• Remote subnets the location must reach
• DNS, DHCP, file server, VoIP, point-of-sale, and application requirements
• Contact information for the person who approves firewall changes

A static public IP isn't mandatory for every design, but it makes firewall-to-firewall connections and IP allowlists easier to manage. If an ISP address changes, the tunnel may stop working until the peer configuration is updated.

Design the Network Before Configuring the Tunnel

A VPN cannot fix an unclear or conflicting network plan. Map the traffic first, then decide which networks should communicate.

Confirm unique subnets

Every location should use distinct private address ranges. A repeatable plan makes future expansion easier. For example:

A /24 provides 254 usable IPv4 addresses. A /25 provides 126, and a /26 provides 62. Size each network for its expected device count rather than assigning every segment a /24 .

Keep spare ranges for a future department, warehouse, tenant network, or temporary project. Overlapping subnets can cause routing failures that look like firewall or VPN problems.

Identify permitted traffic

Don't connect every network simply because the firewall allows it. A guest VLAN should usually reach the internet only. Cameras may need access to a recorder and approved update services. Phones may need DNS, NTP, provisioning, and call-control systems.

Write a short traffic matrix before configuration. Record the source subnet, destination subnet, service, port, and business reason. This supports least-privilege firewall rules and limits lateral movement if one device is compromised.

A managed IT checklist for small businesses can also help organize network documentation, MFA coverage, firewall reviews, and asset records.

Choose Secure IPsec and IKEv2 Settings

Most small businesses should use a current IPsec implementation with IKEv2. The two firewalls must agree on authentication, encryption, integrity, key exchange, and traffic selectors.

Encryption, integrity, and DH groups

A practical baseline is AES-GCM with a current Diffie-Hellman group. NIST guidance supports DH Group 14 and ECDH Groups 19, 20, or 21 for suitable deployments.

If one firewall cannot use AES-GCM, AES-CBC with HMAC-SHA-256 may be an acceptable fallback. Avoid outdated options such as 3DES, MD5, SHA-1, and DH Groups 2 and 5.

Keep the proposal list short. Offering many combinations makes troubleshooting harder and may allow a weaker match than intended. Configure the same Phase 1 and Phase 2 values on both firewalls, including encryption, integrity, lifetimes, and perfect forward secrecy.

Authentication and management security

Use a long, unique pre-shared key if certificates aren't practical. Never reuse a VPN key across unrelated sites. Store it in a protected password manager and limit access to authorized administrators.

Certificates offer stronger identity control for larger or growing environments, but they require certificate issuance, renewal, and revocation procedures. Document who owns those tasks before deployment.

Secure the management plane separately. Require MFA for administrator accounts, use named accounts instead of shared logins, restrict management access to approved networks, and disable unused remote administration services. Keep firewall firmware current and back up the configuration after approved changes.

Use this Fort Myers small business firewall checklist to review exposed services, administrator access, logging, firmware, and rule maintenance.

Configure Both Firewalls

The exact menus and commands differ by vendor, but the logic stays consistent. Build the tunnel on both sides, define the networks, then control the traffic that crosses it.

Configure Phase 1 and Phase 2

Create a peer profile for the other firewall. Enter its public IP address or approved hostname, authentication method, IKE version, encryption, integrity settings, and key exchange group.

Phase 1 establishes the secure management relationship between the firewalls. Phase 2 defines the actual protected traffic, such as the main office staff subnet reaching a branch application subnet.

Use matching traffic selectors. If one side defines 10.20.10.0/24 to 10.30.10.0/24 , the other side must describe the same relationship in reverse. A mismatch can leave the tunnel partially established while business traffic fails.

Cisco configuration examples and NIST's workflow show the value of reviewing the active IKE policy and crypto map after configuration. Treat those commands as vendor-specific examples, not universal instructions.

Add routes and firewall rules

Many firewalls add routes automatically when you configure a policy-based VPN. Route-based VPNs may require explicit static or dynamic routes. Confirm which model your platform uses.

Create rules that allow only required services. A branch workstation might need HTTPS and SMB access to a specific file server, while a guest network should have no path to the VPN. Avoid broad rules such as "any source to any destination."

Also review return traffic, DNS behavior, and local firewall settings on servers. A tunnel can be healthy while a Windows firewall, host route, or application permission blocks the connection.

Keep a change record with the date, administrator, approved purpose, affected networks, and rollback plan. Back up both firewall configurations before making major changes.

Handle Overlapping Address Spaces

Overlapping subnets are common after a business acquires another company or connects an old warehouse. If both sites use 192.168.1.0/24 , ordinary routing cannot reliably distinguish the destinations.

Renumber when possible

Renumbering is usually the cleanest long-term solution, although it may require DHCP changes, printer updates, server changes, and maintenance time. A repeatable scheme such as 10.20.x.x for one site and 10.30.x.x for another leaves room for growth and simplifies later VPN connections.

Don't place both offices in one large shared subnet. Devices on the same Layer 2 and Layer 3 network may communicate locally instead of sending traffic through the VPN, which defeats the intended path.

Use virtual subnets or NAT when necessary

If renumbering isn't practical, use documented subnet translation. Fortinet's overlapping-subnet example maps the same real network, 192.168.111.0/24 , to different virtual networks, such as 10.1.1.0/24 and 10.2.2.0/24 .

The translated subnet must match the size of the original network. Firewall policies, static routes, DNS records, and application settings must account for the translated addresses. NAT can solve the immediate conflict, but it adds complexity and can make troubleshooting harder.

Document both the real and virtual addresses. Test connections in both directions, especially for applications that embed IP addresses, use callbacks, or depend on local discovery.

Test and Troubleshoot the Tunnel

A successful negotiation message doesn't prove that users can reach business resources. Test the actual applications and services that motivated the project.

Validate real traffic

Start with a controlled test device at each location. Confirm its IP address, gateway, DNS server, and VLAN. Then test:

1. Ping where the firewall and application support it.
2. Resolve internal DNS names across the tunnel.
3. Connect to an approved file share or application.
4. Test printing, authentication, VoIP, or point-of-sale functions as applicable.
5. Confirm that guest and restricted networks remain blocked.
6. Review logs for allowed traffic and denied attempts.

Use packet captures or traffic sniffers at both firewalls when the result is unclear. Check whether packets enter the tunnel, reach the destination, and return through the expected path.

Test after a firewall reboot, ISP interruption, and tunnel renegotiation. If the business uses dual-WAN, verify VPN reconnection on the backup circuit. A backup link that loads websites may still fail to support the tunnel, voice quality, or vendor IP allowlists.

Separate Phase 1 from Phase 2 failures

A Phase 1 failure usually points to peer reachability, public IP information, authentication, IKE version, or encryption settings. Check the firewall logs and confirm that both sides use the same proposal.

Phase 2 problems often involve mismatched traffic selectors, encryption, hash settings, or perfect forward secrecy groups. WatchGuard identifies these mismatches as common causes of IKE_AUTH or Phase 2 negotiation failures.

If the tunnel shows as active but traffic fails, review routes, firewall policies, NAT exemptions, host firewalls, DNS, and return paths. Change one setting at a time, record the result, and retest. Avoid making several undocumented changes together.

After deployment, 24/7 network monitoring services can alert the right person when a firewall, WAN circuit, or VPN fails.

Site-to-Site VPN FAQ

Does a site-to-site VPN replace a private circuit?

No. It provides encrypted connectivity across existing internet services. A private circuit may offer different performance or service guarantees, while a VPN often costs less and works across standard business connections.

Do both offices need the same firewall brand?

No. Different brands can connect when they support compatible IPsec and IKEv2 settings. Interoperability testing matters because vendors use different names, defaults, and supported algorithms.

Should the VPN allow all traffic between offices?

Usually not. Permit only the networks and services employees need. Restrict guest, camera, printer, and management traffic unless there is a documented business reason.

How often should the configuration be reviewed?

Review firewall rules, administrator accounts, firmware, VPN logs, and permitted subnets at least quarterly. Revisit the design after an office move, new ISP, new application, acquisition, or network change.

Conclusion

A dependable site-to-site VPN depends more on planning and maintenance than on a single configuration screen. Use unique subnets, current IPsec and IKEv2 settings, strong authentication, narrow firewall rules, and separate MFA protection for management access.

Test real business traffic, document every network and rule, and monitor the tunnel after deployment. When the address plan and security policy are clear, adding another location becomes a controlled network project instead of an emergency fix.