Fortinet white logo
Fortinet white logo

New Features

FGSP support for failover with asymmetric traffic and UTM

FGSP support for failover with asymmetric traffic and UTM

Note

This information is also available in the FortiOS 7.6 Administration Guide:

Session failover is now supported for asymmetric traffic. FortiGate can continue sessions on the active FGSP peers if the original FGSP peer, which initially received the session's first packet, becomes unavailable or unhealthy. It may go into this state due to:

  • Device shutdown or reboot

  • A monitored interface is down

  • A ping-server monitor goes down

When the original peer for a session is unavailable or unhealthy and other peers receive the asymmetric traffic, this traffic does not bounce back to the original peer. Instead, it gets handled by the active FGSP peer. In the case of an unhealthy peer due to failed monitored interface or ping-server monitor, it will share its not-ready status over FGSP heartbeats so other peers will know not to bounce traffic back to it.

In the case of an unavailable peer, once the original FGSP peer is back online, it will perform session sync. While it is syncing, it will share a not-ready status over FGSP so peers will not bounce traffic back to it. Once session sync is complete, it will share a ready status and accept sessions to fail back to it.

Note

UTM inspection will not occur during failover since the traffic must be scanned by the original peer only. Furthermore, during failback of the session to the original FGSP peer, the session will only be scanned if the policy is using flow-based inspection.

This enhancement ensures continuity and reliability of the network sessions, even if a device does not function as expected.

There are two new options available in the config system standalone-cluster command on the CLI:

config system standalone-clusterset monitor-interface <interface name>
    set pingsvr-monitor-interface <interface name>
end

Example

In the following configurations, two peers are configured in FGSP, and a monitored interface and ping server monitor are configured.

config system link-monitor
    edit "1"
        set srcintf "wan1"
        set server "172.16.200.254"
    next
end
config system standalone-cluster
    set standalone-group-id 22
    set group-member-id 2
    config cluster-peer
        edit 1
            set peerip 10.2.2.2
            set hb-interval 20
            set hb-lost-threshold 60
        next
    end
    set monitor-interface "wan2"
    set pingsvr-monitor-interface "wan1"
end

Traffic originally passes through UTM inspection over peer_1. The return traffic is routed to peer_2, where it will bounce to peer_1, the original FGSP peer for inspection.

Upon peer_1 becoming unavailable or unhealthy, traffic no longer bounce back to peer_1. Instead, it is failed over to peer_2 for processing.

FGSP support for failover with asymmetric traffic and UTM

FGSP support for failover with asymmetric traffic and UTM

Note

This information is also available in the FortiOS 7.6 Administration Guide:

Session failover is now supported for asymmetric traffic. FortiGate can continue sessions on the active FGSP peers if the original FGSP peer, which initially received the session's first packet, becomes unavailable or unhealthy. It may go into this state due to:

  • Device shutdown or reboot

  • A monitored interface is down

  • A ping-server monitor goes down

When the original peer for a session is unavailable or unhealthy and other peers receive the asymmetric traffic, this traffic does not bounce back to the original peer. Instead, it gets handled by the active FGSP peer. In the case of an unhealthy peer due to failed monitored interface or ping-server monitor, it will share its not-ready status over FGSP heartbeats so other peers will know not to bounce traffic back to it.

In the case of an unavailable peer, once the original FGSP peer is back online, it will perform session sync. While it is syncing, it will share a not-ready status over FGSP so peers will not bounce traffic back to it. Once session sync is complete, it will share a ready status and accept sessions to fail back to it.

Note

UTM inspection will not occur during failover since the traffic must be scanned by the original peer only. Furthermore, during failback of the session to the original FGSP peer, the session will only be scanned if the policy is using flow-based inspection.

This enhancement ensures continuity and reliability of the network sessions, even if a device does not function as expected.

There are two new options available in the config system standalone-cluster command on the CLI:

config system standalone-clusterset monitor-interface <interface name>
    set pingsvr-monitor-interface <interface name>
end

Example

In the following configurations, two peers are configured in FGSP, and a monitored interface and ping server monitor are configured.

config system link-monitor
    edit "1"
        set srcintf "wan1"
        set server "172.16.200.254"
    next
end
config system standalone-cluster
    set standalone-group-id 22
    set group-member-id 2
    config cluster-peer
        edit 1
            set peerip 10.2.2.2
            set hb-interval 20
            set hb-lost-threshold 60
        next
    end
    set monitor-interface "wan2"
    set pingsvr-monitor-interface "wan1"
end

Traffic originally passes through UTM inspection over peer_1. The return traffic is routed to peer_2, where it will bounce to peer_1, the original FGSP peer for inspection.

Upon peer_1 becoming unavailable or unhealthy, traffic no longer bounce back to peer_1. Instead, it is failed over to peer_2 for processing.