Skip to main content

FortiGate HA Cluster

FortiGate HA Cluster

This is a step-by-step tutorial for configuring a high availability cluster (active-standby) with two FortiGate firewalls. Since almost all firewall vendors have different principles for their HA cluster, I am also showing a common network scenario for Fortinet.

I am using two FortiWiFi 90D firewalls with software version v5.2.5,build701. The official Fortinet documentation for “High Availability with two FortiGates” can be found here.

Network Layout

FortiGate HA NetworkBasically, all interfaces must be connected with layer-2 switches among both firewalls. (In my lab, these are the wan1 and internal1 ports.) Furthermore, two directly connected interfaces should be used for the HA heartbeats. If the firewall has no dedicated HA interfaces, any unused interfaces can be used instead. (In my lab, I am using ports internal13 and internal14 for the heartbeats on my FortiWiFi-90D firewalls.)
The crucial point is the out-of-band management for accessing both firewalls independent of their HA state. Fortinet has the feature of the “Management Port for Cluster Member“, which must be set during the initial HA process. This interface must be unused to that point and can be configured later with an IP address within the same IP subnet as an already used interface. (In my lab, I am using the internal12 ports for the management ports.)

Screenshot Guide

Note: Before cabling the HA cluster, you should configure both units and then power off (!) the secondary one. Then connect the HA heartbeat interfaces and power on the secondary unit again. This ensures that the primary unit will stay the primary (since it has the longer uptime) and syncs its configuration to the secondary one.
Following are the screenshots for this HA cluster guide. Note the descriptions under each screenshot:
The following two pictures show the physical units after the HA configuration. On the first picture, the HA cluster was not cabled, while on the second, it was. Note the green HA LED:
Via the CLI, the diagnose ha sys status  command can be used to investigate the cluster:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
fd-wv-fw04b $ diagnose sys ha status
HA information
Statistics
        traffic.local = s:0 p:18860 b:1708434
        traffic.total = s:0 p:19031 b:1726842
        activity.fdb  = c:0 q:0
 
Model=90, Mode=2 Group=0 Debug=0
nvcluster=1, ses_pickup=1, delay=0
 
HA group member information: is_manage_master=0.
FWF90D3Z13005629, 1.  Slave:128 fd-wv-fw04b
FWF90D3Z13006159, 0. Master:128 fd-wv-fw04
 
vcluster 1, state=standby, master_ip=169.254.0.1, master_id=0:
FWF90D3Z13005629, 1.  Slave:128 fd-wv-fw04b(prio=1, rev=0)
FWF90D3Z13006159, 0. Master:128 fd-wv-fw04(prio=0, rev=255)

Comments

Popular posts from this blog

CLI Commands for Troubleshooting FortiGate Firewalls

CLI Commands for Troubleshooting FortiGate Firewalls 2015-12-21 Fortinet , Memorandum , Network Cheat Sheet , CLI , FortiGate , Fortinet , Quick Reference , SCP , Troubleshooting Johannes Weber This blog post is a list of common troubleshooting commands I am using on the FortiGate CLI . It is not complete nor very detailled, but provides the basic commands for troubleshooting network related issues that are not resolvable via the GUI. I am not focused on too many memory, process, kernel, etc. details. These must only be used if there are really specific problems. I am more focused on the general troubleshooting stuff. I am using it personally as a cheat sheet / quick reference and will update it from time to time. Coming from Cisco, everything is “show”. With Fortinet you have the choice confusion between show | get | diagnose | execute . Not that easy to remember. It is “ get router info6 routing-table” to show the routing table but “ diagn...

Check Throughput of Interfaces - Palo Alto Networks NGFW

Check Throughput of Interfaces - Palo Alto Networks NGFW Following command shows brief interface throughput. > show system statistics session To see the complete statistics, run the show system state browser command > show system state browser Press Shift+L and click on Ports To enable tracking and updates press Y and U To see additional ports, press space bar

From MPLS to SD-WAN to SASE: An Evolution of Enterprise Networking

From MPLS to SD-WAN to SASE: An Evolution of Enterprise Networking The way we do business is changing. As critical business applications migrate to the cloud, and the mobile workforce continues to grow, networking and security solutions need to evolve in order to meet the changing business needs. Gartner believes (and we agree) that the future of networking lies with  SASE (Secure Access Service Edge)  – the convergence of networking and security into one cloud service. Here’s why. 1990s – 2000s: MPLS and the Era of Clear Network Boundaries? Back in the day, networking models were hardware-centric and manually configured. Applications, data, and services lived within private datacenters and relied on remote access solutions to connect remote workers. Dedicated network connectivity, known as MPLS, was the preferred approach for connecting remote locations. MPLS provides predictable performance, low latency and packet loss, and central management. However, MPLS is ...