Fortinet Document Library

Version:

Version:


Table of Contents

Administration Guide

Download PDF
Copy Link

FGSP example with devices using different hardware and firmware

This example demonstrates the following functionalities between different FortiGate models and firmware running the FortiGate Session Life Support Protocol (FGSP):

In this setup, it is possible to migrate to new FortiGate members that are different models while minimizing traffic interruptions. It is also possible to offload traffic to new FortiGate members in order to perform maintenance duties on the original FGSP members.

Session synchronization between all FGSP members

Session synchronization between FGSP members with the same firmware occurs when cluster-sync peers are specified, and the types of traffic to be synchronized are specified under config system ha. An external router or load-balancer directs the traffic to the peers. Sessions are then synchronized between the peers.

In this example, instead of configuring two FortiGates of the same model and firmware together in FGSP, a third FortiGate is added with a different model running different firmware. Once peering is established, sessions are synchronized between the members.

The diagnose system session {sync | list} commands can be used to verify session synchronization.

Prerequisites

The following conditions are required for session synchronization to occur:

  • The VDOMs must be identical between FGSP members.
  • The names of the logical interfaces used for traffic policies must match between FGSP members, even if their underlying physical interfaces are different.
  • The names of the IPsec tunnel interfaces must match between FGSP members.
  • Identical policy tables should be used.

See Session synchronization between all FGSP members for the results.

Session continuation while FGSP members fail

This example also demonstrates a failure where one member fails. In the topology, BGP routing with AS-Path prepending is used so that traffic through one FortiGate is always preferred. However, any type of routing or external load-balancer can be used.

When the member that is actively passing traffic goes down, routing updates ensure a path to the next preferred FortiGate. As traffic is directed to the next FGSP member, previous sessions are already synchronized so traffic continues to flow through this firewall.

See Session continuation while FGSP members fail for the results.

Devices

The following devices are used:

  • FG-3400-1: FortiGate 3401E running FortiOS 6.2.3 (build 1066)
  • FG-3600-1: FortiGate 3601E running FortiOS 6.4.0 (build 1571)
  • FG-3600-2: FortiGate 3601E running FortiOS 6.4.0 (build 1572)
Caution

This example demonstrates forming FGSP between specific FortiGate models and FortiOS firmware. In addition, it demonstrates a working scenario in a specific topology and configuration. Use caution when performing similar operations on different model units and firmware in production.

It is strongly advised to first perform testing in a lab environment before deploying this in production. It is also advisable to be on site with physical access to each unit while performing these operations to ensure business continuity in any unforeseen situations.

See FGSP for more information about FGSP support and limitations.

Physical topology

FG-3400-1, FG-3600-1, and FG-3600-2 are FGSP members. The Simulator FG-3600 has multiple VDOMs, acting as both the CORP firewall and firewalls in the cloud. The Tester is a traffic generator for simulating traffic.

In this example, the traffic makes the following round-trip: Tester > Simulator FG-3600 > Active FGSP member >  Simulator FG-3600 > Tester.

See the logical topologies for more details:

Identical policies are configured on each VDOM of each FGSP member. Each interface, VIP, and IP pool are configured with the same names.

HA configurations

For the HA configurations, each device peers with the other member devices by specifying their peer IP.

To configure HA on FG-3400-1:

The IP of this device is 10.0.0.73 and it is running FortiOS 6.2.3.

config system cluster-sync
    edit 1
        set peerip 10.0.0.82
        set ipsec-tunnel-sync disable
    next
    edit 2
        set peerip 10.0.0.8
        set ipsec-tunnel-sync disable
    next
end
To configure HA on FG-3600-1:

The IP of this device is 10.0.0.82 and it is running FortiOS 6.4.0.

config system standalone-cluster
    set standalone-group-id 1
    set group-member-id 1
end
Note

In FortiOS 6.4.0, config system standalone-cluster is used to configure session synchronization. The standalone-group-id must be the same among members.

config system cluster-sync
    edit 1
        set peerip 10.0.0.73
        set ipsec-tunnel-sync disable
    next
    edit 2
        set peerip 10.0.0.8
        set ipsec-tunnel-sync disable
    next
end
To configure HA on FG-3600-2:

The IP of this device is 10.0.0.8 and it is running FortiOS 6.4.0.

config system standalone-cluster  
    set standalone-group-id 1     
    set group-member-id 1
end
config system cluster-sync
    edit 1
        set peerip 10.0.0.73
        set ipsec-tunnel-sync disable
    next
    edit 2
        set peerip 10.0.0.82
        set ipsec-tunnel-sync disable
    next
end
To configure the types of sessions to synchronize on each FortiGate:
config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expectation enable
    set session-pickup-nat enable
end

BGP routing

FGSP does not natively perform session load-balancing or session failover. These are done by external load-balancers or routers. BGP routing is used in this example to control which FGSP member receives traffic when one member goes down:

  • There is BGP peering on all interfaces, and route maps are used to control route propagation between neighbors.
  • AS-Path prepending is used to guarantee the traffic flow on the same device.
  • For routes announced via the FG-3600-1 and FG-3600-2, an extra AS is added to the route map so that the preferred routes are on the FG-3400E-1.
  • For the overlapping subnet between the Customer cloud and CORP, there are two IPsec VPN tunnels created on the Customer VDOM on the FGSP member FortiGates. There is BGP running over the IPsec tunnel.
  • IPsec SA synchronization between members is disabled in order to avoid conflict.

See Routes learned by the simulator FortiGate 3600E for more information.

FGSP example with devices using different hardware and firmware

This example demonstrates the following functionalities between different FortiGate models and firmware running the FortiGate Session Life Support Protocol (FGSP):

In this setup, it is possible to migrate to new FortiGate members that are different models while minimizing traffic interruptions. It is also possible to offload traffic to new FortiGate members in order to perform maintenance duties on the original FGSP members.

Session synchronization between all FGSP members

Session synchronization between FGSP members with the same firmware occurs when cluster-sync peers are specified, and the types of traffic to be synchronized are specified under config system ha. An external router or load-balancer directs the traffic to the peers. Sessions are then synchronized between the peers.

In this example, instead of configuring two FortiGates of the same model and firmware together in FGSP, a third FortiGate is added with a different model running different firmware. Once peering is established, sessions are synchronized between the members.

The diagnose system session {sync | list} commands can be used to verify session synchronization.

Prerequisites

The following conditions are required for session synchronization to occur:

  • The VDOMs must be identical between FGSP members.
  • The names of the logical interfaces used for traffic policies must match between FGSP members, even if their underlying physical interfaces are different.
  • The names of the IPsec tunnel interfaces must match between FGSP members.
  • Identical policy tables should be used.

See Session synchronization between all FGSP members for the results.

Session continuation while FGSP members fail

This example also demonstrates a failure where one member fails. In the topology, BGP routing with AS-Path prepending is used so that traffic through one FortiGate is always preferred. However, any type of routing or external load-balancer can be used.

When the member that is actively passing traffic goes down, routing updates ensure a path to the next preferred FortiGate. As traffic is directed to the next FGSP member, previous sessions are already synchronized so traffic continues to flow through this firewall.

See Session continuation while FGSP members fail for the results.

Devices

The following devices are used:

  • FG-3400-1: FortiGate 3401E running FortiOS 6.2.3 (build 1066)
  • FG-3600-1: FortiGate 3601E running FortiOS 6.4.0 (build 1571)
  • FG-3600-2: FortiGate 3601E running FortiOS 6.4.0 (build 1572)
Caution

This example demonstrates forming FGSP between specific FortiGate models and FortiOS firmware. In addition, it demonstrates a working scenario in a specific topology and configuration. Use caution when performing similar operations on different model units and firmware in production.

It is strongly advised to first perform testing in a lab environment before deploying this in production. It is also advisable to be on site with physical access to each unit while performing these operations to ensure business continuity in any unforeseen situations.

See FGSP for more information about FGSP support and limitations.

Physical topology

FG-3400-1, FG-3600-1, and FG-3600-2 are FGSP members. The Simulator FG-3600 has multiple VDOMs, acting as both the CORP firewall and firewalls in the cloud. The Tester is a traffic generator for simulating traffic.

In this example, the traffic makes the following round-trip: Tester > Simulator FG-3600 > Active FGSP member >  Simulator FG-3600 > Tester.

See the logical topologies for more details:

Identical policies are configured on each VDOM of each FGSP member. Each interface, VIP, and IP pool are configured with the same names.

HA configurations

For the HA configurations, each device peers with the other member devices by specifying their peer IP.

To configure HA on FG-3400-1:

The IP of this device is 10.0.0.73 and it is running FortiOS 6.2.3.

config system cluster-sync
    edit 1
        set peerip 10.0.0.82
        set ipsec-tunnel-sync disable
    next
    edit 2
        set peerip 10.0.0.8
        set ipsec-tunnel-sync disable
    next
end
To configure HA on FG-3600-1:

The IP of this device is 10.0.0.82 and it is running FortiOS 6.4.0.

config system standalone-cluster
    set standalone-group-id 1
    set group-member-id 1
end
Note

In FortiOS 6.4.0, config system standalone-cluster is used to configure session synchronization. The standalone-group-id must be the same among members.

config system cluster-sync
    edit 1
        set peerip 10.0.0.73
        set ipsec-tunnel-sync disable
    next
    edit 2
        set peerip 10.0.0.8
        set ipsec-tunnel-sync disable
    next
end
To configure HA on FG-3600-2:

The IP of this device is 10.0.0.8 and it is running FortiOS 6.4.0.

config system standalone-cluster  
    set standalone-group-id 1     
    set group-member-id 1
end
config system cluster-sync
    edit 1
        set peerip 10.0.0.73
        set ipsec-tunnel-sync disable
    next
    edit 2
        set peerip 10.0.0.82
        set ipsec-tunnel-sync disable
    next
end
To configure the types of sessions to synchronize on each FortiGate:
config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expectation enable
    set session-pickup-nat enable
end

BGP routing

FGSP does not natively perform session load-balancing or session failover. These are done by external load-balancers or routers. BGP routing is used in this example to control which FGSP member receives traffic when one member goes down:

  • There is BGP peering on all interfaces, and route maps are used to control route propagation between neighbors.
  • AS-Path prepending is used to guarantee the traffic flow on the same device.
  • For routes announced via the FG-3600-1 and FG-3600-2, an extra AS is added to the route map so that the preferred routes are on the FG-3400E-1.
  • For the overlapping subnet between the Customer cloud and CORP, there are two IPsec VPN tunnels created on the Customer VDOM on the FGSP member FortiGates. There is BGP running over the IPsec tunnel.
  • IPsec SA synchronization between members is disabled in order to avoid conflict.

See Routes learned by the simulator FortiGate 3600E for more information.