FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
darisandy
Staff
Staff
Article Id 363357
Description This article describes the behavior when changing the configuration on the Secondary unit of the HA Cluster.
Scope FortiGate.
Solution

Two FortiGates can provide redundancy by configuring the units within the same HA Cluster. One will become the Primary unit and the other is the Secondary unit.

  • The primary unit will handle all the traffic processing most of the time.
  • The secondary unit is in standby to take over when the Primary becomes unavailable.

 

In a general scenario, configuration change can only be done on the Primary unit. For the FortiGate HA cluster, there is no such restriction.

 

Configuration change can be done on the Secondary unit, and it will sync up to the Primary unit.

 

HA.png

 

Configuration change on Secondary unit:

 

FGT-02 # 2024-12-08 19:25:18 <hatalk> vcluster_1: ha_prio=1(secondary), state/chg_time/now=3(standby)/1733714416/1733714718

2024-12-09 10:25:48 0: config system interface
2024-12-09 10:25:48 0: edit "port3"
2024-12-09 10:25:48 0: set ip 1.1.1.1 255.255.255.0
2024-12-09 10:25:48 cmd=config system interface
edit port3
set ip 1.1.1.1 255.255.255.0
end

2024-12-09 10:25:48 0: end
2024-12-09 10:25:48 0: config system interface
2024-12-09 10:25:48 0: edit "port3"
2024-12-09 10:25:48 0: config ipv6
2024-12-09 10:25:48 0: end
2024-12-09 10:25:48 cmd=config system interface
edit port3
config ipv6
end
end

2024-12-09 10:25:48 0: end

 

At the same time, the change gets reflected in the Primary unit:

 

FGT-01 # 2024-12-09 10:25:07 <hatalk> vcluster_1: ha_prio=0(primary), state/chg_time/now=2(work)/1733714394/1733714707
2024-12-09 10:25:48 <hasync:WARN> conn=0x55c1bd341700, peer closed the connection: dst=169.254.0.2, sync_type=10(cli-command)
2024-12-09 10:25:48 <hasync:WARN> conn=0x55c1bd341700, peer closed the connection: dst=169.254.0.2, sync_type=10(cli-command)
2024-12-09 10:25:49 0: config system interface
2024-12-09 10:25:49 0: edit port3
2024-12-09 10:25:49 0: set ip 1.1.1.1 255.255.255.0
2024-12-09 10:25:49 0: end
2024-12-09 10:25:49 0: config system interface
2024-12-09 10:25:49 0: edit port3
2024-12-09 10:25:49 0: config ipv6
2024-12-09 10:25:49 0: end
2024-12-09 10:25:49 0: end

 

FGT-01 # sh sys int port3
config system interface
 edit "port3"
  set vdom "root"
  set ip 1.1.1.1 255.255.255.0
  set type physical
  set snmp-index 3
next
end

 

Important Note:

To make sure of the consistency in configuration, it is highly recommended to always make a configuration change on the Primary unit.

 

Making any changes from the Secondary unit may cause some unpredictable issues, even though it is technically possible.

If a HA Monitored Interface were to be disabled on the Secondary unit, this could cause an HA failover. This change made on the Secondary will propagate to the Primary.

The HA standalone units should not handle any user traffic apart from the heartbeat and monitoring traffic. If there are user traffic is being sent from the user side will be discarded locally at the interface level. If the user traffic is handled by the standby unit, can end up with split-brain scenario and cause an interruption in network services.

Related article:
Technical Tip: High Availability - Split Brain