Fortinet white logo
Fortinet white logo

Handbook

Understanding FortiDDoS Asymmetric Mode

Understanding FortiDDoS Asymmetric Mode

Several FortiDDoS mitigations require the system to see both way traffic. If a single FortiDDoS does not see traffic in both directions, some mitigations must be disabled and replaced with other mitigations. Please read this section carefully if you are deploying in Asymmetric Mode.

Features that will require modification include:

These are explained below.

TCP Profile features and SYN-ACK Thresholds

FortiDDoS monitors TCP state for out-of-state packets which are dropped by the Foreign Packet Validation feature in the TCP Profile.

Enabling Foreign Packet Validation in Asymmetric Mode is recommended. In all cases but one, FortiDDoS can infer the current state of a TCP connection from the packets it does see and protect from out-of-state packet floods like RST, FIN, ACK floods (14 of the 15 possible out-of-state floods).

The exception is an inbound SYN-ACK, which must be accepted as part of the session setup. Since SYN-ACK floods are not unusual, FortiDDoS has additional mitigations.

First, in Global Protection > Deployment, enable Asymmetric Mode and Asymmetric Mode Allow Inbound Synack.

When in Asymmetric mode:

  • The system infers TCP state from the inbound packets it sees. This allows full protection from TCP out-of-state floods with one exception which requires setting of SYN-ACK Thresholds below.

  • Manual Thresholds for two SYN-ACK parameters must be set as described below.

  • Some Profile features that required observation of two-way traffic must be disabled as described below.

Failure to configure each SPP as below will result in very serious traffic interruption in Prevention Mode.

Asymmetric Mode for TCP Profile

TCP state anomaly detection depends on tracking the two-way traffic flow, so some feature options on the Protection Profiles > SPP Settings page do not work in Asymmetric Mode. The table below summarizes the configuration guidelines for these feature options. All of these options are “clean pipe” anomalies and are not known DDoS attack vectors, so disabling them has virtually no impact on protection.

Recommended TCP state anomaly detection settings in Asymmetric Mode
Settings Guidelines
SYN validation Mandatory. This option enables SYN flood mitigation mode.
Sequence validation Mandatory disable. Depends on tracking a two-way traffic flow.
State transition anomalies validation Mandatory disable. Depends on tracking a two-way traffic flow.
Foreign packet validation Strongly recommended. In Asymmetric Mode, FortiDDoS can still track foreign packets other than SYN-ACKs.
Allow tuple reuse Enabled by default to support standard test environments that reuse tuples in quick succession. The setting is valid in Asymmetric Mode. Recommended to avoid unnecessary logging of the event when it is detected.
Allow duplicate SYN-in-SYN-SENT Disable.
Allow duplicate SYN-in-SYN-RECV
Do not enable.

Allow SYN anomaly

Do not enable.

Allow SYN-ACK anomaly

Do not enable.

Allow ACK anomaly

Do not enable.

Allow RST anomaly

Do not enable.

Allow FIN anomaly

Do not enable.

Other TCP Profile Settings in Asymmetric Mode
Settings Guidelines
SYN Flood Mitigation Mode SYN Cookie
SYN Flood Mitigation Direction Inbound
Slow Connection Type Mandatory "None". Slow Connections counts packets in both directions which will not be seen in Asymmetric Traffic, resulting in unreliable outcomes.
Strict Anomalies Enable. Drops header and 48 possible TCP flag combinations that are always illegal.
Aggressive Aging Feature Control

High Concurrent Connection per Source – Enable

Slow TCP Connections – Mandatory Disable

Recording TCP SYN-ACK and SYN-ACK per Destination Traffic Statistics

The following procedure must be done after a learning period and execution of Traffic Statistics Reports and System Recommended Thresholds for each SPP. If done before, setting System Recommended Thresholds will delete these manually-entered Thresholds.

SYN-ACK and SYN-ACK per Destination Thresholds must be set manually for each SPP after changing the system to Asymmetric Mode and allowing at least 1 week of traffic learning.

After one week of learning:

  1. Navigate to Monitor > Layer 3/4/7 and select Layer 4 from the drop-down menu. The graph will default to the “default” SPP and start there.

  2. Scroll to the SYN/ACK and SYN/ACK Per Destination graphs (or close other graphs) and set the time period for each to at least 1 week.

  3. Make sure the direction is inbound.

  4. Disable the graphs for sub-graphs other than the Egress Max Packet Rate (orange sub-graph).

  5. Record the peak inbound egress traffic rate observed over the time period of the graph for both SYN/ACK and SYN/ACK Per Destination graphs.

    Be aware that SYN-ACK floods are popular and may have occurred during learning. If the peak inbound rate is many times larger than the average rate and occurs infrequently, that may have been an attack.

    Also be aware of the SPP you are observing:

    • A web server SPP should see almost no inbound SYN-ACKs, since servers receive SYNs and send SYN-ACKs

    • A DNS server SPP should see no inbound SYN-ACKs since it almost never sends SYNs

    • A firewall will see a lot of SYN-ACKs since it is sending a lot of SYNs

    If in doubt, contact Fortinet Customer Service & Support for consultation.

  6. Repeat and record for all SPPs

  7. Once done,

    • Take all the recorded numbers and multiply them x2

    • If the result is less than 500, record 500

    • If there result is over 500, record that number

    • Proceed with setting Thresholds below.

    Setting TCP SYN-ACK and SYN-ACK per Destination Thresholds
    • Navigate to Service Protection > Service Protection Policy

    • Select an SPP

    • Select the Thresholds tab

    • Ensure the pull-down menu shows Scalars

    • Click +Create

    • Scroll down the Type menu to the SYN/ACK In Asym Mode parameter.

    • Name the Threshold (“Manual_SYN-ACK”, for example). Copy that text for use in other SPPs.

    • Enter the recorded number from above in the Threshold field.

    • Save the Threshold

    • That returns you to the SPP main page where you can select the next SPP and repeat the above, using the copied Threshold name in each SPP

    • Repeat for all SPPs

    • When done, return to the first SPP and above but select SYN/ACK Per Destination In Asym Mode

    • Repeat again for all SPPs

    • When complete you should have thresholds for both parameters in all SPPs.

    • Proceed with further configuration.

Asymmetric Mode for DNS Profile

Several DNS features that are designed to mitigate DNS Amplified Reflected Response Floods need to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode they must be disabled.

Disable the highlighted features below for DNS Profiles in all SPPs


Enabling any of these features can result in total Internet blockage for local users.

DNS Rcode Thresholds, which are learned and set using System Recommendations, protect SPPs from DNS Amplified Reflected Response Floods.

Asymmetric Mode for NTP Profile

Several NTP features that are designed to mitigate NTP Amplified Reflected Response Floods need to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode they must be disabled.

Disable the highlighted features below for NTP Profiles in all SPPs

Enabling any of these features can prevent local devices from refreshing NTP.

The Reflection Deny feature above works in Asymmetric Mode and will mitigate virtually all NTP Query or Response Floods from the first packet.

The NTP Response and Response per Destination Thresholds, which are learned and set using System Recommendations, protect SPPs from NTP Response floods.

Asymmetric Mode for DTLS Profile

The DTLS Reflection Deny feature below is designed to mitigate DTLS Server Hello Floods and needs to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode this feature must be disabled.

Disable Reflection Deny for NTP Profiles in all SPPs

Asymmetric Mode for QUIC Profile

The QUIC Reflection Deny feature below is designed to mitigate QUIC Response Initial Floods (from servers) and needs to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode this feature must be disabled.

Disable Reflection Deny for QUIC Profiles in all SPPs

QUIC Response Initial per Destination Thresholds which are learned and set using System Recommendations, protect SPPs from QUIC Response Initial floods.

Understanding FortiDDoS Asymmetric Mode

Understanding FortiDDoS Asymmetric Mode

Several FortiDDoS mitigations require the system to see both way traffic. If a single FortiDDoS does not see traffic in both directions, some mitigations must be disabled and replaced with other mitigations. Please read this section carefully if you are deploying in Asymmetric Mode.

Features that will require modification include:

These are explained below.

TCP Profile features and SYN-ACK Thresholds

FortiDDoS monitors TCP state for out-of-state packets which are dropped by the Foreign Packet Validation feature in the TCP Profile.

Enabling Foreign Packet Validation in Asymmetric Mode is recommended. In all cases but one, FortiDDoS can infer the current state of a TCP connection from the packets it does see and protect from out-of-state packet floods like RST, FIN, ACK floods (14 of the 15 possible out-of-state floods).

The exception is an inbound SYN-ACK, which must be accepted as part of the session setup. Since SYN-ACK floods are not unusual, FortiDDoS has additional mitigations.

First, in Global Protection > Deployment, enable Asymmetric Mode and Asymmetric Mode Allow Inbound Synack.

When in Asymmetric mode:

  • The system infers TCP state from the inbound packets it sees. This allows full protection from TCP out-of-state floods with one exception which requires setting of SYN-ACK Thresholds below.

  • Manual Thresholds for two SYN-ACK parameters must be set as described below.

  • Some Profile features that required observation of two-way traffic must be disabled as described below.

Failure to configure each SPP as below will result in very serious traffic interruption in Prevention Mode.

Asymmetric Mode for TCP Profile

TCP state anomaly detection depends on tracking the two-way traffic flow, so some feature options on the Protection Profiles > SPP Settings page do not work in Asymmetric Mode. The table below summarizes the configuration guidelines for these feature options. All of these options are “clean pipe” anomalies and are not known DDoS attack vectors, so disabling them has virtually no impact on protection.

Recommended TCP state anomaly detection settings in Asymmetric Mode
Settings Guidelines
SYN validation Mandatory. This option enables SYN flood mitigation mode.
Sequence validation Mandatory disable. Depends on tracking a two-way traffic flow.
State transition anomalies validation Mandatory disable. Depends on tracking a two-way traffic flow.
Foreign packet validation Strongly recommended. In Asymmetric Mode, FortiDDoS can still track foreign packets other than SYN-ACKs.
Allow tuple reuse Enabled by default to support standard test environments that reuse tuples in quick succession. The setting is valid in Asymmetric Mode. Recommended to avoid unnecessary logging of the event when it is detected.
Allow duplicate SYN-in-SYN-SENT Disable.
Allow duplicate SYN-in-SYN-RECV
Do not enable.

Allow SYN anomaly

Do not enable.

Allow SYN-ACK anomaly

Do not enable.

Allow ACK anomaly

Do not enable.

Allow RST anomaly

Do not enable.

Allow FIN anomaly

Do not enable.

Other TCP Profile Settings in Asymmetric Mode
Settings Guidelines
SYN Flood Mitigation Mode SYN Cookie
SYN Flood Mitigation Direction Inbound
Slow Connection Type Mandatory "None". Slow Connections counts packets in both directions which will not be seen in Asymmetric Traffic, resulting in unreliable outcomes.
Strict Anomalies Enable. Drops header and 48 possible TCP flag combinations that are always illegal.
Aggressive Aging Feature Control

High Concurrent Connection per Source – Enable

Slow TCP Connections – Mandatory Disable

Recording TCP SYN-ACK and SYN-ACK per Destination Traffic Statistics

The following procedure must be done after a learning period and execution of Traffic Statistics Reports and System Recommended Thresholds for each SPP. If done before, setting System Recommended Thresholds will delete these manually-entered Thresholds.

SYN-ACK and SYN-ACK per Destination Thresholds must be set manually for each SPP after changing the system to Asymmetric Mode and allowing at least 1 week of traffic learning.

After one week of learning:

  1. Navigate to Monitor > Layer 3/4/7 and select Layer 4 from the drop-down menu. The graph will default to the “default” SPP and start there.

  2. Scroll to the SYN/ACK and SYN/ACK Per Destination graphs (or close other graphs) and set the time period for each to at least 1 week.

  3. Make sure the direction is inbound.

  4. Disable the graphs for sub-graphs other than the Egress Max Packet Rate (orange sub-graph).

  5. Record the peak inbound egress traffic rate observed over the time period of the graph for both SYN/ACK and SYN/ACK Per Destination graphs.

    Be aware that SYN-ACK floods are popular and may have occurred during learning. If the peak inbound rate is many times larger than the average rate and occurs infrequently, that may have been an attack.

    Also be aware of the SPP you are observing:

    • A web server SPP should see almost no inbound SYN-ACKs, since servers receive SYNs and send SYN-ACKs

    • A DNS server SPP should see no inbound SYN-ACKs since it almost never sends SYNs

    • A firewall will see a lot of SYN-ACKs since it is sending a lot of SYNs

    If in doubt, contact Fortinet Customer Service & Support for consultation.

  6. Repeat and record for all SPPs

  7. Once done,

    • Take all the recorded numbers and multiply them x2

    • If the result is less than 500, record 500

    • If there result is over 500, record that number

    • Proceed with setting Thresholds below.

    Setting TCP SYN-ACK and SYN-ACK per Destination Thresholds
    • Navigate to Service Protection > Service Protection Policy

    • Select an SPP

    • Select the Thresholds tab

    • Ensure the pull-down menu shows Scalars

    • Click +Create

    • Scroll down the Type menu to the SYN/ACK In Asym Mode parameter.

    • Name the Threshold (“Manual_SYN-ACK”, for example). Copy that text for use in other SPPs.

    • Enter the recorded number from above in the Threshold field.

    • Save the Threshold

    • That returns you to the SPP main page where you can select the next SPP and repeat the above, using the copied Threshold name in each SPP

    • Repeat for all SPPs

    • When done, return to the first SPP and above but select SYN/ACK Per Destination In Asym Mode

    • Repeat again for all SPPs

    • When complete you should have thresholds for both parameters in all SPPs.

    • Proceed with further configuration.

Asymmetric Mode for DNS Profile

Several DNS features that are designed to mitigate DNS Amplified Reflected Response Floods need to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode they must be disabled.

Disable the highlighted features below for DNS Profiles in all SPPs


Enabling any of these features can result in total Internet blockage for local users.

DNS Rcode Thresholds, which are learned and set using System Recommendations, protect SPPs from DNS Amplified Reflected Response Floods.

Asymmetric Mode for NTP Profile

Several NTP features that are designed to mitigate NTP Amplified Reflected Response Floods need to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode they must be disabled.

Disable the highlighted features below for NTP Profiles in all SPPs

Enabling any of these features can prevent local devices from refreshing NTP.

The Reflection Deny feature above works in Asymmetric Mode and will mitigate virtually all NTP Query or Response Floods from the first packet.

The NTP Response and Response per Destination Thresholds, which are learned and set using System Recommendations, protect SPPs from NTP Response floods.

Asymmetric Mode for DTLS Profile

The DTLS Reflection Deny feature below is designed to mitigate DTLS Server Hello Floods and needs to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode this feature must be disabled.

Disable Reflection Deny for NTP Profiles in all SPPs

Asymmetric Mode for QUIC Profile

The QUIC Reflection Deny feature below is designed to mitigate QUIC Response Initial Floods (from servers) and needs to see two-way traffic. Since that cannot be guaranteed in Asymmetric mode this feature must be disabled.

Disable Reflection Deny for QUIC Profiles in all SPPs

QUIC Response Initial per Destination Thresholds which are learned and set using System Recommendations, protect SPPs from QUIC Response Initial floods.