- Let's test the failover situation where FortiGate A fails to run. First, while the two FortiGate instances are running, log into FortiGate A by connecting to the front-end public IP address, which is https://18.104.22.168, associated with 192.168.1.13.
- Let's see if FortiGate B promotes itself to the primary when FortiGate A fails to run. On the EC2 console, shut down FortiGate A.
- Connect to the same public front-end IP address, https://22.214.171.124, by refreshing the browser. You have now successfully logged into FortiGate B, not FortiGate A, since the secondary IP address 192.168.1.13 has moved to FortiGate B’s public-facing port.
- Check FortiGate B’s secondary IP address in EC2 console.
Any existing AWS routes are updated to reference the new primary FortiGate's ENI1/port2 instead of the original primary FortiGate's ENI1/port2. In this example, FortiGate B, which was originally the secondary FortiGate, is promoted to the role of primary FortiGate.
- Check the HA status while FortiGate A is down.
- Once FortiGate A comes back online, it runs as the secondary. It takes time for the HA to settle and the synchronization to function, as indicated by the green checkmarks.