Created on
07-17-2023
09:04 PM
Edited on
08-29-2025
10:40 AM
By
Stephen_G
| Description |
This article describes that due to the need to navigate the traffic between iBGP neighbors to a central FortiGate (a Hub) all the time, it was necessary to create a star topology with the Hub connecting to multiple Spoke using Site-to-Site IPsec tunnel. It is necessary to make that the Hub will advertise Spoke’s internal subnet to the other Spokes with itself as the next hop Topology:
Spoke-1 ==(To-Hub | To-Spoke-1)== Hub ==(To-Spoke-2 | To-Hub)== Spoke-2
Tunnel interfaces on Hub and both spokes which creation is not covered in this article but they will be referenced in later section for firewall policies and BGP:
Hub:
Spoke1:
Spoke2:
Additional internal networks will be 10.x.0.0/24 and 172.16.x.0/24 with:
|
| Scope | FortiGate v6.4.2 and above. |
| Solution |
Be aware that implementing the star topology will produce a single point of failure (i.e. the Hub). The recommendation is to configure the ADVPN tunnel with BGP as the routing protocol between the Hub and Spoke to mitigate this issue and decrease the workload of network processing on the Hub through the creation of a dynamic VPN tunnel (aka shortcuts) between Spokes.
For the creation of the Site-to-Site IPSec tunnel between the Hub and its Spokes, it is always recommended to create through the IPsec wizard to prevent any human error that may cause the tunnel not to come up. An additional benefit when using the wizard is that the firewall will automatically create an address group with address objects for the local and remote subnet(s), firewall policies for traffic between internal resources and tunnel, and a static route to reach the remote subnets through the IPsec tunnel and through the blackhole interface if the tunnel goes down.
To configure any advanced settings like changing the phase1 and phase2 proposals, it is possible to convert to a custom tunnel to see more settings:
For phase2 configuration, in this example, local and remote subnets are set to all, and firewall policies will have source and destination addresses set to 'all'. It is possible to control which subnets got through the tunnel through the BGP advertisement and firewall policies to restrict subnets.
After going through the configuration, the following tunnels should be created and up on both phases on Hub and Spokes respectively:
To establish the BGP neighbors between the Hub and Spokes, it is recommended to use the Loopback interface due to its nature of always staying up.
Configure basic BGP configuration on the GUI on both Hub and Spoke:
For any internal networks to route through the tunnel, a pair of firewall policies would be necessary for incoming and outgoing traffic between the tunnel and internal interfaces. This can be achieved with the IPSec wizard. However, in the future, adding more internal interfaces with internal subnets to go through the tunnel, will be a requirement.
After completing the configuration, we will dive into additional settings needed, configured either via the GUI or the CLI on each device.
Spoke: Configure the following BGP settings. This can be achieved either through the CLI or through the GUI setting for newer FortiOS version (7.0.x or 7.2.x and above):
config router bgp set ibgp-multipath enable set additional-path enable config neighbor edit "192.168.0.1" set soft-reconfiguration enable set interface "To-Hub"<----- specify the interface used to participate in the BGP network. set remote-as 65400 set update-source "Loopback1"<----- specify the source IP used to reach the BGP neighbor next end end
Hub: Since the Hub is the center point in the star topology to forward internal traffic from one spoke to another, a pair of firewall policies to allow traffic from one tunnel to another is needed. Alternatively, to prevent any human errors while creating the firewall policies, these tunnels can be grouped in an interface zone and set to all intra-zone traffic. The risk of missing a tunnel or two when configuring the firewall policies or when adding them to the interface zone is another concrete reason for configuring the Hub and Spoke model using the ADVPN tunnel instead.
Here is an example of the firewall policies pair needed:
Configure the following BGP settings. This can be achieved either through the CLI or through the GUI settings for newer FortiOS version (7.0.x or 7.2.x and above):
config router bgp set ibgp-multipath enable set additional-path enable config neighbor edit "192.168.2.1" set next-hop-self-rr enable<----- To set the Hub as the next-hop when advertising to other Spoke. set soft-reconfiguration enable set interface "To-Spoke-2" set update-source "Loopback-Hub" set route-reflector-client enable <----- To enable the iBGP advertisement next edit "192.168.1.1" set next-hop-self-rr enable set soft-reconfiguration enable set interface "To-Spoke-1" set update-source "Loopback-Hub" set route-reflector-client enable next end
The 'next-hop-self' setting will not work on the next hop of iBGP routes reflected by the Hub. It only modifies the next hop of local or eBGP learned routes.
After configuring all the settings needed, please reset the BGP session:
execute router restart
To verify the BGP routes advertised by the Hub on each spoke. Pay attention to routes installed as static (S) by IKE process on the hub and spokes, namely: On the hub: S 192.168.1.1/32 [10/0] is directly connected, To-Spoke1 S 192.168.2.1/32 [10/0] is directly connected, To-Spoke2 On spoke 1: S 192.168.0.1/32 [10/0] is directly connected, To-Hub On spoke 2: S 192.168.0.1/32 [10/0] is directly connected, To-Hub
Related documents: |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2026 Fortinet, Inc. All Rights Reserved.