Sanity check on HA setup

[druber]

So my HA setup now works.  Details:

2 40F units on verizon DHCP broadband

lan1 => LAN

lan2 => heartbeat (priority 200)

lan3 => heartbeat (priority 100)

a => OOB mgmt (192.168.2.11 and 192.168.2.12 in vlan2)

interface monitoring set for lan1 and wan.

I have:

session-pickup
session-pickup-connectionless
session-pickup-delay

Does this look reasonable?  Anything missing?  Thanks!

[vdralio]

Dear @druber ,

Please find below the article for Fortinet's best practices, you can find their detailed information regarding it. Just keep in mind every setup is unique and depends on the requirements that need to be configured. 

https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/6b151c0a-67d4-11ea-9384-005056...

Best Regards,

Vasil

[ede_pfau]

Looks sound. Some advice not necessarily applying to this quite simple setup, but from experience:

1- always (always) change the "HA-group-id" to something other than the default "0"! this will determine the virtual MAC addresses used for the interfaces. This parameter is CLI-only.

2- equal priorities and no "override enable" setting - this way, when a failover occurs, there will be no fallback to the original primary, thus avoiding a second interruption

3- "set uninterruptable enable" which might already be enabled per default

4- "session-pickup": yes, for TCP sessions only. UDP sessions are way less critical and do not cause a huge overhead when they have to be restarted, so I prefer "connectionless disable". IPsec sessions always break on failover.

Session sync increases both the traffic volume on the HA links and CPU load. This setting should not be set "per default" but deliberately.

5- no encryption on the HA link(s). Unless the cluster units are located far apart via WAN lines. Increases CPU load.

6- by default, HA monitoring will detect link failure, in addition to device failure. In a switched environment, links can stay up forever even though the line is broken further up. Install ping target monitoring (system link-monitor) to ensure a WAN line really is up. Either choose the ISP's gateway (preferably it's loopback IP) or number the WAN line and ping the other end (for instance, with VPNs).

[Debbie_FTNT]

Tiny nitpick - HA group ID can be set via GUI in newer firmware versions.

Screenshot from my lab 7.2.1 cluster:

[druber]

What is the motivation for changing the HA-group-id?  My heartbeat links are directly connected between the two firewalls, but encryption and authentication seem disabled by default.  I can't monitor the ISP's gateway, since it's a DHCP connection, and the gateway may change?

[Debbie_FTNT]

Hey druber,

as Ede mentioned, the group ID determines the virtual MAC addresses associated with the cluster (the MAC addresses the primary unit will use for its interfaces instead of the actual physical MAC addresses).

If you have more than one FortiGate cluster with the same HA group ID, they would have the same virtual MAC addresses.

[druber]

Makes sense, thanks.  This is SOHO setup with only 1 cluster, so I'm ok...

[mclegg]

One additional comment.  You are using Lan2 and Lan3 as your HA ports, make sure that they are not part of the hardware switch that the default config comes with.

Convert them to individual interfaces.

See the best practices for HA here and the warning box at the top of the page: https://docs.fortinet.com/document/fortigate/6.0.0/best-practices/956481/heartbeat-interfaces

[druber]

I did in fact make sure to convert lan1, lan2 and lan3 to physical before doing this.

[druber]

I do appreciate all the helpful information.  Thanks again!