Site to Site VPN Setup for Secure Branch Networks

A site to site VPN setup connects two or more business networks through encrypted tunnels so offices, stores, and remote facilities can share approved resources without exposing them to the public internet. For a medical practice linking a satellite office to its main location, or a retailer connecting point-of-sale systems to a central server, the objective is not simply to make a tunnel show as "up." The objective is controlled, dependable connectivity that supports daily operations without creating an unnecessary security path into the network.

What a Site to Site VPN Setup Must Accomplish

A properly designed site-to-site VPN extends selected network services between locations. Staff may need access to a file server, a line-of-business application, an internal phone system, or a management VLAN. That does not mean every device at one location should be able to reach every device at the other.

The tunnel should enforce the same security discipline used inside the office. Each site needs clear network segmentation, defined traffic requirements, firewall policies, logging, and a plan for monitoring the connection after deployment. A VPN that permits unrestricted traffic between flat networks can turn a problem at one site into a larger incident across the organization.

For many small and midsize businesses, FortiGate firewalls are a practical fit because they combine IPsec VPN services, firewall policy enforcement, SD-WAN controls, security inspection, and centralized visibility in one platform. The right model and design depend on internet speeds, user volume, application requirements, and the number of locations being connected.

Start With Network Design, Not Tunnel Configuration

VPN configuration is usually the easy part. The harder and more valuable work happens before the first encryption proposal is selected. A site survey should document each location's WAN service, firewall, internal subnet structure, VLANs, wireless networks, servers, cloud applications, and dependencies such as voice, payment processing, or security cameras.

Use Unique Subnets at Every Location

Overlapping IP address ranges are one of the most common reasons a site-to-site VPN becomes difficult to deploy or unreliable to troubleshoot. If both offices use 192.168.1.0/24, a device cannot reliably determine whether that address exists locally or across the tunnel.

Each location should receive unique, documented subnets. A business might use separate VLANs for staff workstations, guest Wi-Fi, voice devices, payment terminals, cameras, servers, and network management. This structure makes routing predictable and gives the firewall meaningful boundaries for policy enforcement.

For example, a branch office may need access to an accounting server at headquarters, while its guest Wi-Fi should have internet access only. The VPN design should route the approved staff VLAN to the accounting server network, not extend guest traffic, cameras, or every unmanaged device across the connection.

Identify the Traffic That Actually Needs to Cross

Before creating policies, define the source, destination, protocol, and business purpose for each connection. This is especially relevant for organizations handling payment data, protected health information, legal records, or customer information.

A restaurant may require its back-office systems to reach a central reporting application. A law office may need encrypted access to a document management server. A medical office may need connectivity to an approved practice-management system. These are different requirements, and they should not be addressed with one broad "allow all" rule.

Documenting traffic flows also exposes dependencies that are easy to miss, including DNS resolution, Active Directory services, print services, time synchronization, and application licensing. A tunnel can be established successfully while the application still fails because a required supporting service was not included in the design.

Choose the Right Tunnel and WAN Model

Most business site-to-site deployments use IPsec VPN tunnels between firewalls. IPsec provides encryption, authentication, integrity checking, and interoperability across internet providers. It is generally the preferred approach when the organization controls security appliances at both ends.

A single tunnel can be appropriate for two locations with stable broadband circuits and modest uptime requirements. However, a business that depends on the connection for payment processing, cloud phone services, or access to central applications should consider secondary internet service and automatic failover.

With FortiGate SD-WAN, multiple WAN circuits can be monitored for packet loss, latency, and jitter. The firewall can steer traffic through the best available path and fail over when a provider or circuit degrades. This adds design and licensing considerations, but it can substantially reduce disruption for sites where an internet outage means lost revenue or halted operations.

Static public IP addresses simplify certain deployments, but they are not always required. Dynamic DNS, dial-up IPsec configurations, and properly configured peer identification can support locations where a static address is unavailable. The trade-off is that the design must be documented carefully and tested after WAN address changes.

Configure IPsec With Security and Operations in Mind

A secure IPsec deployment should use current encryption standards and avoid legacy settings retained only for compatibility. In most cases, IKEv2, AES encryption, SHA-2 integrity algorithms, strong Diffie-Hellman groups, and certificate-based authentication or protected pre-shared keys are appropriate starting points. The exact proposal must be compatible with both endpoints and aligned with the firewall firmware version.

Pre-shared keys must be long, unique, stored securely, and changed when personnel or vendor access changes. A reused or casually shared VPN key weakens the entire connection. Certificates can improve identity management at scale, though they introduce certificate lifecycle responsibilities that smaller organizations should plan to support.

Firewall policies should be explicit in both directions. Define the approved source VLAN, destination network or host, and required services. Apply NAT only when the design calls for it. In many routed site-to-site VPN environments, traffic between internal networks should not be source-NATed because the destination system needs to see the original client address for logging, access control, or troubleshooting.

Security profiles require careful consideration. Inspecting encrypted tunnel traffic can provide greater visibility, but it also affects performance and may not be suitable for every protocol. The correct choice depends on the traffic type, the firewall's capacity, compliance requirements, and whether endpoint controls already protect the devices involved.

Validate More Than Tunnel Status

A green status indicator is not proof that the implementation is complete. Validation should confirm that intended users can reach approved resources, unauthorized VLANs remain blocked, name resolution works, and applications perform acceptably under normal load.

Testing should include failover if secondary WAN circuits are present. Disconnect the primary path during a maintenance window and verify that the tunnel re-establishes through the backup connection. Test voice quality, transaction processing, remote printing, and any cloud applications that depend on route selection. Document the expected behavior so future support staff can distinguish a true outage from normal failover activity.

Logs should record tunnel negotiation events, policy denials, WAN health, and unusual traffic patterns. FortiAnalyzer can provide centralized retention, reporting, and investigation support for organizations that need better visibility across multiple firewalls. Configuration backups should be taken before and after deployment, then stored according to the organization's recovery process.

Treat the VPN as an Ongoing Security Service

A site-to-site VPN is infrastructure, not a one-time task. Internet providers change equipment, firmware updates alter supported cryptographic settings, new applications create routing needs, and business expansion introduces additional sites. Without review, old firewall rules tend to accumulate until no one can explain why broad access exists.

A disciplined support process includes firmware planning, backup verification, policy hygiene, tunnel health checks, license renewal tracking, and periodic review of who and what can traverse the connection. It should also include a current network diagram and an escalation plan for internet provider outages.

Kamanel Consulting designs and supports Fortinet-based VPN environments with the surrounding firewall, VLAN, wireless, switching, and operational controls considered together. That approach helps South Florida businesses avoid treating branch connectivity as an isolated firewall feature.

The best VPN deployment is one employees rarely think about because authorized systems work as expected, failures have a tested response path, and access remains limited to what the business genuinely needs.