A client might connect through a FortiWeb HA pair to an e-commerce site. The site runs Magento, which sets cookies, in a server pool. To prevent session stealing and some other session-based attacks, Magento can track its own cookies and validate session information in $_SESSION using server-side memory.

In the FortiWeb HA pair that protects the server pool, you have enabled Session Management, so the active appliance (FortiWeb A) also adds its own cookie to the HTTP response from Magento. The HTTP response therefore contains 2 cookies:

The next request from the client echoes both cookies. It is for an authorized URL, so FortiWeb A permits the web site to respond.

Let’s say you then update FortiWeb A’s firmware. During the update, the standby appliance (FortiWeb B) briefly assumes the role of the active appliance while FortiWeb A is applying the update and rebooting (i.e. a failover occurs).

After the failover, FortiWeb B would receive the next HTTP request in the session. Because it was previously the standby when the client initiated the session, and FortiWeb session tables are not synchronized, FortiWeb B has no knowledge of the FortiWeb session cookie in this request.

As a result, it cannot enforce sequence-specific features such as page order, since it does not know the session history. However, a FortiWeb session cookie is present. Therefore FortiWeb B would permit the new request (assuming that it has no policy violations).

If the client deletes their FortiWeb session cookie or it times out, FortiWeb B regards the next request as a new FortiWeb session, adding a new FortiWeb session cookie to Magento’s response and creating an entry in FortiWeb B’s session table, enabling it to enforce page order and start page rules again.