FortiAuthenticator can be used when adding strong authentication to a network. FortiAuthenticator has more options, like FSSO (FortiNet Single Sign-On) in conjuction with a FortiGate firewall. You can create a FortiAuthenticator cluster very easily. I normally configure a active/passive cluster and not a load-balancing cluster. When creating an active/passive cluster you should follow these guidelines:
Often I use FortiAuthenticator with FortiGate or appliances like Citrix NetScaler or Pulse Secure to enable two-factor authentication. Like I stated above, the slave unit takes over the masters port1 IP address. This implies that you only need to configure one RADIUS server in your front-end appliance. This is not true.
I added the master FAC as RADIUS server to a FortiGate firewall. Authentication is working fine. Next I shutdown the master FAC. The slave unit takes over and the “masters” port1 IP address is accessible, so it can be used for authentication. But when you authenticate to the master IP address something “strange” happens. The slave unit response to the RADIUS request with its own port1 IP address. You can see this in the packet sniffer on the FortiGate below. The master IP on port1 is 10.10.10.10 and the slave IP is 10.10.10.11. I shutdown the master unit and try to authenticate.
BZO-FG500-01 # diagnose sniffer packet any ‘udp and port 1812’
filters=[udp and port 1812]
27.067084 10.10.200.201.1063 -> 10.10.10.10.1812: udp 129
27.074294 10.10.10.11.1812 -> 10.10.200.201.1063: udp 40
32.070029 10.10.200.201.1063 -> 10.10.10.10.1812: udp 129
32.070220 10.10.10.11.1812 -> 10.10.200.201.1063: udp 40
As you can see the FGT sends the RADIUS request to the master IP 10.10.10.10, but the slave FAC answers with the IP 10.10.10.11, so authentication is unsuccessful. I needed to add the slave FAC as well to the FortiGate as RADIUS server to successfully authenticate in the event the primary FAC is lost.