Pass-through sessions

This section contains information about session failover for communication sessions passing through the cluster. In general, if session pickup is enabled, session failover is supported for most TCP traffic.

Protocol	Session failover
Most TCP sessions	Supported if session-pickup is enabled. See TCP session failover for more information.
Multicast sessions	Supported if multicast session-pickup is enabled. See Enabling multicast session failover for more information.
IPv6, NAT64, and NAT66	Supported if session-pickup is enabled.
Proxy-based security profile sessions	Not Supported; sessions have to be restarted. Proxy-based features require the FortiGate to maintain very large amounts of internal state information for each session. The FGCP does not synchronize this internal state information. As a result, proxy-based sessions are not failed over. Active-active clusters can resume some of these sessions after a failover. See Resume active-active HA subordinate units sessions after failover for more information.
Flow-based security profile sessions	Supported if session-pickup is enabled; however, internal state information is not synchronized so flow-based sessions that fail over are not inspected after they fail over. If both flow-based and proxy-based security profile features are applied to a TCP session, that session will not resume after a failover.
UDP, ICMP, or broadcast sessions	Supported if connectionless session-pickup is enabled. See Enabling UDP, ICMP and broadcast packet session failover for more information.
GPRS Tunneling Protocol (GTP)	Supported with limitations. See FortiOS Carrier GTP session failover for more information.
SIP	Supported for active-passive HA only. See SIP session failover for more information.
SIMPLE or SCCP signal session	Not supported; sessions have to be restarted.
SSL offloading and HTTP multiplexing	Not supported; sessions have to be restarted. See SSL offloading and HTTP multiplexing session failover for more information.

TCP session failover

TCP sessions that are not being processed by security profile features resume after a failover even if these sessions are accepted by security policies with security profiles. Only TCP sessions that are actually being processed by these security profile features do not resume after a failover.

• TCP sessions that are not virus scanned, web filtered, spam filtered, content archived, or are not SIP, SIMPLE, or SCCP signal traffic resume after a failover, even if they are accepted by a security policy with security profile options enabled. For example, SNMP TCP sessions through the FortiGate resume after a failover because FortiOS does not apply any security profile options to SNMP sessions.

• TCP sessions for a protocol for which security profile features have not been enabled resume after a failover even if they are accepted by a security policy with security profile features enabled. For example, if you have not enabled any antivirus or content archiving settings for FTP, FTP sessions resume after a failover.

SIP session failover

If session pickup is enabled, the FGCP supports SIP session failover (also called stateful failover) for active passive HA.

SIP session failover replicates SIP states to all cluster units. If an HA failover occurs, all in-progress SIP calls (setup complete) and their RTP flows are maintained and the calls will continue after the failover with minimal or no interruption.

SIP calls being set up at the time of a failover may lose signaling messages. In most cases the SIP clients and servers should use message retransmission to complete the call setup after the failover has completed. As a result, SIP users may experience a delay if their calls are being set up when an HA a failover occurs. But in most cases the call setup should be able to continue after the failover.

FortiOS Carrier GTP session failover

FortiOS Carrier HA supports GTP session failover. Once the GTP tunnel setup is completed, the primary unit synchronizes the GTP tunnel state across all cluster units. Although HA does not synchronize UDP sessions used by GTP, the new primary unit retains the GTP tunnel state information after a failover. This allows GTP UDP sessions using the same tunnel to continue to flow, albeit with certain limitations.

The limitation on packets continuing to flow is that there has to be a security policy to accept the packets. For example, if the FortiOS Carrier unit has an internal to external security policy, GTP UDP sessions using an established tunnel that are received by the internal interface are accepted by the security policy and can continue to flow. However, GTP UDP packets for an established tunnel that are received at the external interface cannot flow until packets from the same tunnel are received at the internal interface.

If you have bi-directional policies that accept GTP UDP sessions then traffic in either direction that uses an established tunnel can continue to flow after a failover without interruption.

SSL offloading and HTTP multiplexing session failover

SSL offloading and HTTP multiplexing requires the FortiGate to maintain very large amounts of internal state information for each session. Sessions accepted by security policies containing virtual IPs or virtual servers with SSL offloading or HTTP multiplexing enabled do not resume after a failover.

Resume active-active HA subordinate units sessions after failover

In an active-active cluster, subordinate units process sessions. After a failover, all cluster units that are still operating may be able to continue processing the sessions that they were processing before the failover. These sessions are maintained because after the failover the new primary unit uses the HA session table to continue to send session packets to the cluster units that were processing the sessions before the failover. Cluster units maintain their own information about the sessions that they are processing and this information is not affected by the failover. In this way, the cluster units that are still operating can continue processing their own sessions without loss of data.

The cluster keeps processing as many sessions as it can. But some sessions can be lost. Depending on what caused the failover, sessions can be lost in the following ways:

• A cluster unit (subordinate unit) fails. All sessions that were being processed by that cluster unit are lost.

• A link failure occurs. All sessions that were being processed through the network interface that failed are lost.