Other stuff...

FortiAuthenticator – HA Clustering

René Jorissen on February 3, 2016 1 Comment • Tags: #clustering #fac #fortiauthenticator #ha

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:

  1. use port1 as the default (production) port;
  2. use port2 as HA cluster port;
  3. The slave unit can only be managed via port2;
  4. When a failover occurs, the slave takes over the IP address of the masters port1;
  5. The HA IP address is always unique, so I use this IP address to register the licenses for both appliances;
  6. Configure priority High for the master and priority Low for the slave, like show in the image;

FAC-HA-config

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’
interfaces=[any]
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.

The following two tabs change content below.

René Jorissen

Co-owner and Solution Specialist at 4IP Solutions
René Jorissen works as Solution Specialist for 4IP in the Netherlands. Network Infrastructures are the primary focus. René works with equipment of multiple vendors, like Cisco, Aruba Networks, FortiNet, HP Networking, Juniper Networks, RSA SecurID, AeroHive, Microsoft and many more. René is Aruba Certified Edge Expert (ACEX #26), Aruba Certified Mobility Expert (ACMX #438), Aruba Certified ClearPass Expert (ACCX #725), Aruba Certified Design Expert (ACDX #760), CCNP R&S, FCNSP and Certified Ethical Hacker (CEF) certified. You can follow René on Twitter and LinkedIn.

Latest posts by René Jorissen (see all)

  1. Mohammed says:

    can we use TACACS+ for authenticaton now with the version 6.3.0? any reason to use radius and not tacacs+?

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.