Description
This article explains the behavior of FSSO collector agent failover.
Scope
FortiGate FSSO.
Solution
When the Primary and Secondary FSSO Collector Agents are configured in the FortiGate firewall, the firewall connects with the primary Collector Agent and once the primary goes down, failover occurs with the secondary.
Now once the secondary CA connection is established, if the primary CA connectivity is up, the firewall still fetches the user info from the secondary only.
In order to failover back to the primary, secondary connectivity must go down.
Below is an example of the FSSO CA configuration in the lab firewall:
config user fsso
edit "TEST"
set server "10.14.4.107"
set password ENC VtgmK7kNLMDeIFPBcE6/nenHubjHX+sxgVn/dTI0FnnMszZ4BhRFzahhlHWF0Xi5dCqyqYDELQgU9vhM6lSo6bs6yrbHfch2c09MCzEWZsfxe6NUL1gY8ulSirG3wlh1sX4CF8xx12olk456KlSg35OQ+a8CSDjdSnAlsTKuxJxjsZCR/mqy1te30SisBnk==
set server2 "10.5.20.107"
set password2 ENC o/30GG5rrzPp/+7SJg1yeOo5vmK3ntH9aJVW18R1cuBWnT4q3yKo9nS5UXPvWWypBOq6IKjkXOikOsvV/+b2S4K3Eu3LlglTJOjjy/oQ26Ghok3/KOhNwlE3NJkzDsYR9o1cxB29oVt2pLRgYiBb62nytPvLNMzo2ZV854i9dKqmFn3Y4WkN6l2K3Afw==
next
end
Here, there are CAs: 10.14.4.107(primary) and 10.5.20.107(secondary). Currently, the primary is up. Upon checking the status:
di de en
di de authd fsso server-status
Server Name Connection Status Version Address
----------- ----------------- ------- -------
TEST connected FSSO 5.0.0304 10.14.4.107
When both are up, the authd debug can be seen:
[_process_logon:1072]: ADMINISTRATOR (10.14.4.107, 0) logged on from TEST.
[_process_logon:1115]: ADMINISTRATOR (10.14.4.107, 0) from TEST exists.
[_process_logon:1072]: ADMINISTRATOR (10.5.20.107, 0) logged on from TEST.
Here, the primary server 10.14.4.107 is disabled:
_event_error[TEST]: error occurred in epoll_in: Connection timed out
disconnect_server_only[TEST]: disconnecting <- Disconnecting from the current primary.
authd_timer_run: 1 expired
authd_epoll_work: timeout 920
authd_timer_run: 1 expired
authd_epoll_work: timeout 9990
authd_epoll_work: timeout 9990
Server challenge:
03 3d fc 32 88 3d af 6c 4a 76 f3 49 79 1c 9a 1f
MD5 response:
a9 9b 7c 3f a6 d8 75 ff a0 bd e8 4f 5d 40 38 ab
authd_epoll_work: timeout 9990
connected_state[TEST]: entering CONNECTED state (vfid=0)
_send_pending_requests[TEST]: need_gai=0 need_gli=1
[authd_fsae_send_group_info:288]: called
authd_epoll_work: timeout 9990
[_process_logon:1072]: ADMINISTRATOR (10.14.4.107, 0) logged on from TEST.
[_process_logon:1115]: ADMINISTRATOR (10.14.4.107, 0) from TEST exists.
[_process_logon:1072]: ADMINISTRATOR (10.5.20.107, 0) logged on from TEST.
[_process_logon:1115]: ADMINISTRATOR (10.5.20.107, 0) from TEST exists.
di de authd fsso server-status
authd_epoll_work: timeout 5260
Server Name Connection Status Version Address
----------- ----------------- ------- -------
TEST connected FSSO 5.0.0304 10.5.20.107 <- Active FSSO CA is 10.5.20.107.
Now, the 10.14.4.107 is enabled.
execute ping 10.14.4.107
PING 10.14.4.107 (10.14.4.107): 56 data bytes
64 bytes from 10.14.4.107: icmp_seq=0 ttl=128 time=0.5 ms
64 bytes from 10.14.4.107: icmp_seq=1 ttl=128 time=0.6 ms
64 bytes from 10.14.4.107: icmp_seq=2 ttl=128 time=0.5 ms
64 bytes from 10.14.4.107: icmp_seq=3 ttl=128 time=0.7 ms
^C
--- 10.14.4.107 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.7 ms
From the authd debug, the following can be seen:
[_process_logon:1072]: ADMINISTRATOR (10.14.4.107, 0) logged on from TEST. <- The primary is connected.
[_process_logon:1072]: ADMINISTRATOR (10.5.20.107, 0) logged on from TEST. <- The secondary is also connected.
[_process_logon:1115]: ADMINISTRATOR (10.5.20.107, 0) from TEST exists. <- 10.5.20.107 exists, which means it is active already, so it is not making 10.14.4.107 active.
di de authd fsso server-status
authd_epoll_work: timeout 13430
Server Name Connection Status Version Address
----------- ----------------- ------- -------
TEST connected FSSO 5.0.0304 10.5.20.107 <- The active CA is still 10.5.20.107, though 10.14.4.107 is primary.
In order to fallback on the primary 10.14.4.107, 10.5.20.107 connectivity should be broken.
When the 10.5.20.107 was disabled, the debug output looked like the following:
_event_error[TEST]: error occurred in epoll_in: Connection timed out
disconnect_server_only[TEST]: disconnecting
authd_epoll_work: timeout 270
authd_timer_run: 1 expired
authd_epoll_work: timeout 9980
authd_epoll_work: timeout 9980
Server challenge:
6d 41 21 72 13 0e c1 77 15 6b 2b 05 25 0b 35 2b
MD5 response:
52 3d a3 b8 65 c9 d4 d2 9a 08 a0 08 cf 59 a0 30
authd_epoll_work: timeout 9980
connected_state[TEST]: entering CONNECTED state (vfid=0)
_send_pending_requests[TEST]: need_gai=0 need_gli=1
[authd_fsae_send_group_info:288]: called
authd_epoll_work: timeout 9980
[_process_logon:1072]: ADMINISTRATOR (10.14.4.107, 0) logged on from TEST.<- Connected on 10.14.4.107.
[_process_logon:1115]: ADMINISTRATOR (10.14.4.107, 0) from TEST exists.
di de authd fsso server-status
Server Name Connection Status Version Address
----------- ----------------- ------- -------
TEST connected FSSO 5.0.0304 10.14.4.107 <<<<<<<<<<<<< 10.14.4.107 primary is active after the secondary went down.
