This recipe is part of the process of deploying FortiGate HA for AWS. See below for the rest of the recipes in this process:
- Customize the CFT template
- Check the prerequisites
- Review the network failover diagram
- Invoke the CFT template
- Connect to the FortiGates
- [Connectivity test] Configure FortiGate firewall policy
- [Failover test] Shut down FortiGate A
- 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://220.127.116.11, 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://18.104.22.168, 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.
- 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.
Latest posts by In Hye Lee (see all)
- Connect to the FortiGate - February 21, 2018
- Deploying FortiGate for GCP - February 21, 2018
- (Connectivity test) Configure FortiGate firewall policies and virtual IPs - February 14, 2018