| Solution |
In this FortiGate Session Synchronization (FGSP) example, IPS inspection is enabled on the firewall policy, and the option tcp-session-without-syn is enabled on the policy.
config firewall policy
edit <policyid>
set tcp-session-without-syn all
FGSP supports up to 16 cluster members. For illustrative purposes, this article uses a simple example with two members (referred to as FortiGate A and FortiGate B).
Due to asymmetric routing, the initial SYN packet (half-open connection) is received and processed by one member (FortiGate A in the example), but the returning SYN-ACK packet is received by another member (FortiGate B).
Important Note: In FGSP, TCP half-open sessions (created upon receipt of the initial SYN) are also synchronized to other cluster members. This synchronization helps minimize the occurrence of Case 2 scenarios, but brief delays in synchronization can still lead to situations where the SYN-ACK arrives before the half-open session has been fully synced.
This article explains how the member receiving the SYN-ACK handles the packet in the two possible scenarios.
Behavior: When the receiving member (FortiGate B in the example) gets the SYN-ACK packet, it first attempts to match the packet against its local session table.
Case 1: Matching Session Exists on the Receiving Member (Session Already Synced).
- The receiving member finds a matching session in its session table.
- The session ownership check determines that another member (FortiGate A) is the owner of the session (i.e., the session was originally created by that member).
Action taken by the receiving member:
- It forwards the SYN-ACK packet to the session owner over the FGSP session synchronization link.
- The owner processes the packet normally, including performing UTM inspection (e.g., IPS, Application Control, Antivirus, etc.) if UTM features are enabled on the policy.
- UTM inspection is supported only on the session owner; the receiving member does not perform local UTM processing on forwarded packets.
- After processing, updated session information (including the updated protocol state) is synced to all other members, overwriting the existing state where applicable.
Result: The connection proceeds normally without disruption, with full UTM feature support.
Case 2: No Matching Session on the Receiving Member (Half-Open Session Not Yet Synced)
- The receiving member does not find a matching session in its session table (the TCP half-open session created on the owner has not yet been synchronized, despite half-open sessions being synced in FGSP).
Action taken by the receiving member:
- If the matching firewall policy has tcp-session-without-syn enabled, the receiving member will create a new local session for the SYN-ACK packet and allow the connection to proceed.
- In this newly created local session, UTM features (if enabled) will be performed locally on the receiving member.
- If tcp-session-without-syn is disabled (default behavior), the receiving member will drop the SYN-ACK packet because it does not match any existing session, as no SYN was seen by this unit.
Result:
- With tcp-session-without-syn enabled: The connection is preserved even during brief synchronization delays across the cluster. UTM processing occurs on whichever member handles the packet.
- Without the option: The SYN-ACK is dropped, potentially causing connection failures in a highly asymmetric environment.
|
