Connecting multiple sites over the internet remains a fundamental need for many companies, even though the landscape has changed significantly. It’s no longer just about linking a headquarters with two branches. Today, there are hybrid users, cloud applications, cameras, point-of-sale systems, warehouses, VoIP telephony, SaaS services, remote desktops, backups, monitoring, and equipment that need to work as if they were within a common network.
In this context, an IPsec hub-and-spoke VPN architecture with FortiGate remains a practical way to create encrypted connectivity between sites without necessarily relying on dedicated private circuits. The concept is simple: a central site or data center acts as the hub, and each remote office, or spoke, establishes an IPsec tunnel to that central point. Fortinet describes site-to-site VPNs as connections that enable fixed-location offices to establish secure links over a public network like the internet.
The value of this design lies in its balance. It’s relatively easy to understand, allows for central policy management, and facilitates remote sites’ access to shared resources at the main site, such as ERP systems, files, databases, internal services, or administrative tools. But it also has limitations. As the number of sites grows or when offices need to communicate extensively with each other, the traditional model can start to introduce latency, bottlenecks, and increased load on the hub.
The hub-and-spoke model: simple, secure, and easy to operate
In a hub-and-spoke VPN, each remote site maintains its own local network and connects securely to the hub via IPsec. The hub is typically located in the data center, main office, or a site with better connectivity, higher firewall capacity, and shared services.
A typical example would be a company with a headquarters in Madrid and offices in Valencia, Bilbao, and Seville. Each office would have its own FortiGate, local network, and an IPsec tunnel to the central FortiGate. Traffic to corporate applications would flow through the hub. If one office needs to communicate with another, the traffic can first go to the hub and then to the other site, based on routing and policy configurations.
Fortinet documents this pattern as a setup where VPN connections originate from a central unit toward multiple remote peers. It also indicates that traffic can pass between private networks behind the hub and behind the spokes, and even between remote networks via the hub.
| Element | Role in the architecture |
|---|---|
| Hub | Central VPN termination point and security policies |
| Spoke | Remote site establishing an IPsec tunnel to the hub |
| IPsec Tunnel | Encrypts traffic between sites over the internet |
| Routes and policies | Define which networks are reachable and what traffic is permitted |
| Monitoring | Allows inspection of tunnel status, latency, outages, and usage |
The main advantage is management. All sites have a clear path to the central hub. Rules can be configured systematically, and security control is centralized within a comprehensible architecture. For many SMBs, retail chains, clinics, law firms, schools, hotels, or companies with multiple branches, this design is sufficient and avoids unnecessary complications.
It also makes initial expansion easier. Adding a new office usually involves deploying a new FortiGate, creating the tunnel to the hub, publishing internal networks, adjusting policies, and verifying connectivity. If FortiManager is used, centralized management further simplifies maintaining templates, objects, policies, and configurations with less manual effort.
Where the limits appear
Traditional hub-and-spoke setups have a natural weakness: the hub becomes a central bottleneck. This can be beneficial for control but may not be optimal for performance.
If a remote office mainly needs to access the main site, the model works well. However, if many branches need to communicate directly with each other, routing everything through the hub introduces unnecessary traversal. For example, traffic from Seville to Bilbao may go through Madrid, even if both offices are well connected to the internet. This increases latency and firewall load.
There’s also a point of concentration. If the hub goes down, many sites could become isolated. For medium or large environments, it’s advisable to consider redundant hubs, dual operators, backup routes, active monitoring, failover testing, and clear continuity policies. High availability isn’t just about having two firewalls; it also involves verifying that routes, DNS, services, certificates, tunnels, and dependencies continue functioning during outages.
Another often underestimated aspect is IP addressing. To keep a multi-site network clean, each site should have well-defined, non-overlapping IP ranges. Using the same 192.168.1.0/24 subnet across multiple offices may seem convenient initially but complicates routing, NAT, support, and troubleshooting. In a VPN architecture, the IP plan is a critical design decision, not a minor detail.
Security doesn’t end once the tunnel is established. IPsec encrypts traffic but doesn’t automatically define what’s permitted. Firewall policies, network segmentation, access controls, event logging, log review, and adherence to the principle of least privilege are all necessary. A poorly segmented VPN can turn a local incident into a corporate security breach.
ADVPN: when sites need to communicate directly with each other
For larger deployments, Fortinet offers ADVPN (Auto Discovery VPN). Its goal is to overcome a classic hub-and-spoke limitation: enabling spokes to establish direct, on-demand tunnels between each other without all traffic necessarily passing through the hub. Fortinet describes ADVPN as an IPsec technology that allows spokes in a traditional hub-and-spoke VPN to create direct, dynamic tunnels between themselves when needed.
This is especially useful when many sites, significant lateral traffic, or distributed applications exist. For instance, a company with warehouses, sales offices, and regional hubs may require frequent inter-branch communication. Routing everything through the central site would be inefficient. ADVPN maintains the hub for control and discovery, but allows shortcuts to reduce latency and traffic load.
Fortinet’s support for ADVPN is integrated into their IPsec hub-and-spoke VPN assistant. When verifying tunnels, documentation indicates each spoke maintains its connection to the hub, and if another spoke is active, a direct spoke-to-spoke shortcut can also be established.
Combining ADVPN with SD-WAN can further optimize the architecture. If a site has fiber primary, 5G backup, and secondary links, SD-WAN policies can select the best path based on latency, packet loss, jitter, or availability. The challenge is to avoid confusing ease of deployment with the absence of design. While ADVPN and SD-WAN provide flexibility, they also require thorough documentation, monitoring, and testing.
To decide between a basic hub-and-spoke and ADVPN, ask yourself: do remote sites mainly consume central services or do they need to communicate heavily among themselves? If most traffic goes to the center, traditional hub-and-spoke might suffice. If inter-branch traffic is substantial, ADVPN becomes more attractive.
The ideal multi-site architecture isn’t always the most advanced but one that best fits operations. A three-office network doesn’t need the same complexity as an organization with 80 sites, multiple providers, critical applications, and high continuity requirements. Fortinet provides components for both scenarios, but the design must start with the business needs: what sites exist, what applications are used, what traffic is generated, what latency is acceptable, and what happens if a connection fails.
A well-designed IPsec VPN can cut costs relative to traditional WAN models, leverage internet links, and maintain encryption across locations. However, for true effectiveness, it must be complemented by orderly IP addressing, restrictive policies, redundancy where needed, monitoring, and centralized management. Security isn’t just about the tunnel; it’s about how everything passing through it is governed.
Frequently Asked Questions
What is an IPsec site-to-site VPN?
It’s an encrypted connection between two or more fixed networks, typically company sites, using a public network like the internet.
What does hub-and-spoke mean?
It’s a topology where a central site acts as the hub and remote sites, called spokes, connect to it via VPN tunnels.
When does ADVPN make sense?
When many sites need to communicate directly with each other, and routing everything through the central hub would be inefficient.
Does IPsec alone guarantee security?
No. IPsec encrypts traffic, but you also need firewall policies, segmentation, access controls, monitoring, and proper configuration.
What common mistakes should be avoided in a multi-site VPN?
Using overlapping IP ranges, not documenting routes, allowing excessive traffic between sites, relying on a single hub without backup, and not monitoring tunnels.
