FortiGate HA modes and their main differences
Posted: April 3, 2024
As a network engineer you often receive orders from the project team and you are going to implement standard design that is tested across multiple environments, especially if you work in corporation with dozens of customers, linked processes and rules in place. If you are going to touch a critical environment, there is not much freedom to implement new ideas. All the rules in place limit you and after some time you are doing things automatically without even thinking about challenging existing design. So as I study for NSE7 I realize that there is more to high-availability than I thought.
Network I work on dominantly deploys Active-Passive HA setup. We tested Active-Active HA for some scenarios as well.
There is however at least one other option, utilizing multiple standalone FortiGates (2-16 pieces) or multiple A-A/A-P clusters (2-16 pieces as well) utilizing FGSP protocol to balance sessions. I was not aware about the option so I decided to dive deeper. In my opinion, NSE7 training materials should go deeper as well and explain why there are multiple options for HA setup.
Let's pause for a second and explain shortcuts we will use heavily.
- FGCP (FortiGate Clustering Protocol) - connects multiple FortiGates into logical unit that shares sessions, config and external files, elects primary member that handles all traffic and config
- FGSP (Fortigate Session Life Support Protocol) - HA protocol for sharing sessions across multiple FortiGates, but FGSP doesn't sync config and external files
- A-A - active/active HA setup, A-P - active/passive HA setup
A-A and A-P HA modes rely on FGCP. FGCP HA uses one virtual MAC address that is known to the connected network. All traffic arrives at the port having mentioned virtual MAC address and that is the primary member of the cluster, always. Only after, primary member can send traffic/session to the secondary member of A-A setup for UTM processing. Therefore there is no load-balancing of traffic between connections leading towards A-A HA setup. A-A setup can and balances computing power required for traffic processing between members of A-A, by offloading traffic to secondary member(s) if needed. To cover A-P HA mode, it's enough to say that the primary device handles all traffic and the secondary device doesn't process any network traffic.
In FGSP setup, the approach to HA is different. Typically there is a device (preferably load-balancer) that stands in front of FortiGates and distributes traffic to each standalone FortiGate device. LB should be configured to send all packets of one session to the same FortiGate peer. If there is a switch or a router instead of LB, or if LB doesn't forward traffic properly, FGSP protocol moves session from one FortiGate to another one. Goal is to move the session to session owner and have single FortiGate handle all traffic related to the session. Session owner is FortiGate that received the first packet of the session.
If asymmetric routing is observed by FortiGate, the session is moved to the session owner as well.
With FGSP setup, we don't have one virtual MAC address for all FortiGates but each device has its own physical MAC address that is known to devices on segment. All lines connecting LB and FortiGates can be used. LB sends traffic based on its configuration and FortiGates can move sessions to session owners if LB doesn't forward traffic properly.
It is important to mention that devices connecting via FGSP should be of the same type, have identical licenses,same kernel 32/64 bits, same type of CPU, etc…
Devices in FGSP setup can synchronize configuration. As you might have guessed, FGCP is used, but this time, FortiGates won't form an A-A or A-P HA cluster. The protocol will elect primary and secondary member, but it sole purpose is to synchronize device configuration from primary to secondary members..