Deploying a FGT cluster a-p in 2 different locations will work.
- there needs to be a L2 connection between the FGTs
- the HA protocol uses non-standard ethertypes on the HA link, so all active devices inbetween should be able to cope with that (Nexus don't)
- depending on the line characteristics, you might have to tweak the timeout settings on the HA link
- lo and behold if that metro/long range HA connection experiences packet loss or even interruptions! Best practice demands at least 2 independent HA links, which might be difficult to provide.
- we encountered an obstacle with the WAN address of the active FGT. When failing over, the WAN address should switch as well, just to keep the (numerous) VPNs running. At that time, we solved that with having the ISP configuring it's routers in VRRP to have the WAN IP reassigned to the other location. Problem was, the FGT failed over in 1 s, the routers in 10 mins.
Today I would rather have duplicate (backup) VPNs to achieve the same redundancy. But there were other services tied to the WAN address, so this might be a point you should consider.
The HA link will use DHCP addresses from the APIPA range (169.254.), you don't have to take care of that. Other subnets depend on your needs.
Sometimes I use the loopback interface for mgmt, as it doesn't depend on a link status (Network - Create New - Loopback). It can be specified as the cluster member management interface so one can manage both HA units independently.
And never, never, do I use the ranges 192.168.1. or 192.168.2. These are default address ranges, so someone could bring in a device from the supermarket, plug it in and make it part of the network. What's wrong with 10.19.1. or 172.22.1.?
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.