SRX

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Hello,

The show chassis forwarding command is not available on the SRX4600. Instead, I am sharing the output of show chassis routing-engine, but I am not currently testing under an attack. The device is idle. Do you think the routing engine would have issues during an attack?

root@SRX4600-FW> show chassis routing-engine
Routing Engine status:
    Total memory              3852 MB Max   462 MB used ( 12 percent)
    Memory utilization          11 percent
    5 sec CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     0 percent
      Interrupt                  0 percent
      Idle                      99 percent
    1 min CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      99 percent
    5 min CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      99 percent
    15 min CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      99 percent
    Model                          SRX Routing Engine
    Start time                     2025-08-01 11:13:18 UTC
    Uptime                         82 days, 14 minutes, 44 seconds
    Last reboot reason             0x1:power cycle/failure
    Load averages:                 1 minute   5 minute  15 minute
                                       0.21       0.20       0.17

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

I think you've already established the routing-engine (a.k.a. control plane, "CPU") is nearly completely idle even under attack, though it seems odd.

I'm not very familiar with the higher-end SRX devices, but there's got to be a command to show you how busy the data plane (a.k.a. packet forwarding engine, "SPU") is. Maybe "show security monitoring performance spu"

You should monitor both control plane and data plane. Full utilization on either of them will cause problems for legitimate traffic.

Also, it's not clear what sort of attack(s) you're facing. From your posts I gather maybe it's SYN flood? Or maybe lots of TCP traffic that doesn't belong to any established session? But then you should have a number of Drop sessions created (assuming you run JunOS 23.4 or later).  You mentioned "no load on the session table or CPU" -- does that mean 0 sessions?

Lastly, you mentioned you mentioned you can't tell if you did something wrong, but unless you share what you did, no one else will be able to tell as well.

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 16:36
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello,

The show chassis forwarding command is not available on the SRX4600. Instead, I am sharing the output of show chassis routing-engine, but I am not currently testing under an attack. The device is idle. Do you think the routing engine would have issues during an attack?

root@SRX4600-FW> show chassis routing-engine
Routing Engine status:
    Total memory              3852 MB Max   462 MB used ( 12 percent)
    Memory utilization          11 percent
    5 sec CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     0 percent
      Interrupt                  0 percent
      Idle                      99 percent
    1 min CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      99 percent
    5 min CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      99 percent
    15 min CPU utilization:
      User                       0 percent
      Background                 0 percent
      Kernel                     1 percent
      Interrupt                  0 percent
      Idle                      99 percent
    Model                          SRX Routing Engine
    Start time                     2025-08-01 11:13:18 UTC
    Uptime                         82 days, 14 minutes, 44 seconds
    Last reboot reason             0x1:power cycle/failure
    Load averages:                 1 minute   5 minute  15 minute
                                       0.21       0.20       0.17

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 16:22
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 16:06
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 15:59
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

I think I captured a log that might point to the root cause. In the historical logs I see the following output:

Oct 20 17:54:28 SRX4600-FW PERF_MON: RTPERF_CPU_THRESHOLD_EXCEEDED: FPC 0 PIC 0 CPU utilization exceeds threshold, current value = 99
Oct 20 17:54:28 SRX4600-FW PERF_MON: RTPERF_CPU_UTIL_MAX: FPC 0 PIC 0 CPU Utilization greater than 99, expect packet loss

I suspect a component on the line card that drops packets is getting saturated at high PPS. Yet I can drop the same attack without issues on my software-based OEM server (which I use as a firewall) that cost me $1,000 USD.

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Something still doesn't make sense to me ... 

The datasheet quotes 400 gbps throughput ... If we're generous and take that number to be for 1518-byte packets (even though they quote the same performance for IMIX), that still translates to 30M+ PPS.

In a normal flow (i.e. traffic is allowed) -- there's input checks, check session table (session found), screens, output checks, and out it goes.

In your flow (no-session non-syn tcp) -- there's input checks, check session table (session not found), check TCP flags and drop the packet.

I can't imagine your flow is that much more complex than a normal flow. If datasheets are to be believed, the firewall should be able to do your flow 30M times per second. But let's be generous and say that your flow of seeing the missing SYN flag and dropping the packet is twice as complex as a normal established-session forwarding flow, still you'd want to see 15M pps drop rate.

What I suspect is that the quoted numbers in the datasheet are aggregate across all various components of the box for a total of 30M pps. It's safe to assume that measurement is taken under ideal conditions -- load is balanced across all the various NPUs, SPUs, or whatever. 

I imagine that in your case, you're just blasting the box with small (3gbps at 5M pps ~= 75 bytes) NOT-SYN TCP packets on the same port, which then goes to the same NPU / SPU / thread / etc. (I can't easily find the internal architecture of the SRX4600; I'm assuming it has multiple of those, but who knows).

I wonder ... what if you establish multiple connections from the MX to the SRX with ECMP and set source-ip-only-based load-balancing on the MX side. The hope is that spreading the 5M PPS over multiple interfaces / cards / NPUs / SPUs / threads / whatever may get you better overall aggregate performance on the SRX ...

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 17:01
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

I think I captured a log that might point to the root cause. In the historical logs I see the following output:

Oct 20 17:54:28 SRX4600-FW PERF_MON: RTPERF_CPU_THRESHOLD_EXCEEDED: FPC 0 PIC 0 CPU utilization exceeds threshold, current value = 99
Oct 20 17:54:28 SRX4600-FW PERF_MON: RTPERF_CPU_UTIL_MAX: FPC 0 PIC 0 CPU Utilization greater than 99, expect packet loss

I suspect a component on the line card that drops packets is getting saturated at high PPS. Yet I can drop the same attack without issues on my software-based OEM server (which I use as a firewall) that cost me $1,000 USD.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 16:22
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 16:06
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 15:59
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Thank you very much for your reply. The idea of applying this kind of scenario by distributing the load to the other interface via LACP sounds reasonable. Also, when I checked I see there are no modules in FPC 0. Maybe that isn't the problem. At the moment I don't have a test attack of 5M+ PPS available. If one of my customers receives such an attack, I will move the load onto the SRX and perform the checks during the attack.

root@SRX4600-FW> show chassis hardwareHardware inventory:Item             Version  Part number  Serial number     DescriptionChassis                                JN12672C8JCA      SRX4600Midplane         REV 54   750-069375   CALG2210          SRX4600 MidplaneRouting Engine 0          BUILTIN      BUILTIN           SRX Routing EnginePseudo CB 0  Mezz           REV 16   711-066896   CAKT9951          Control Mezz BoardFPC 0            REV 13   711-065484   CALC1726          SRX4600 SPM  PIC 0                   BUILTIN      BUILTIN           4x 10GE SFP+ HAFPC 1            REV 14   711-065676   CALG2210          SRX4600 MPC  PIC 0                   BUILTIN      BUILTIN           MRATE-4xQSFPP-XGE-XLGE-CGE    Xcvr 0       REV 01   740-038153   FDC3NA46038-1     QSFP+-40G-CU3M    Xcvr 2       REV 01   740-061000   FDC4NA34013-1     QSFP28-100G-CU1M  PIC 1                   BUILTIN      BUILTIN           8x 10GE SFP+    Xcvr 0       REV 01   740-021308   AQQ24P7           SFP+-10G-SR    Xcvr 1       REV 01   740-021308   ARB14HQ           SFP+-10G-SRPower Supply 0   REV 01   740-066937   1HS18270137       JNP-PWR1600-ACPower Supply 1   REV 01   740-066937   1HS18250333       JNP-PWR1600-ACFan Tray 0                                               Fan Tray 0, Front to Back Airflow - AFOFan Tray 1                                               Fan Tray 1, Front to Back Airflow - AFOFan Tray 2                                               Fan Tray 2, Front to Back Airflow - AFOFan Tray 3                                               Fan Tray 3, Front to Back Airflow - AFOFan Tray 4                                               Fan Tray 4, Front to Back Airflow - AFO

Here no active ports are visible on FPC 0. Maybe the logs I took earlier are not related to the issue I experienced. I will send another message after I perform the necessary checks during an attack. Thank you very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 18:59
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Something still doesn't make sense to me ... 

The datasheet quotes 400 gbps throughput ... If we're generous and take that number to be for 1518-byte packets (even though they quote the same performance for IMIX), that still translates to 30M+ PPS.

In a normal flow (i.e. traffic is allowed) -- there's input checks, check session table (session found), screens, output checks, and out it goes.

In your flow (no-session non-syn tcp) -- there's input checks, check session table (session not found), check TCP flags and drop the packet.

I can't imagine your flow is that much more complex than a normal flow. If datasheets are to be believed, the firewall should be able to do your flow 30M times per second. But let's be generous and say that your flow of seeing the missing SYN flag and dropping the packet is twice as complex as a normal established-session forwarding flow, still you'd want to see 15M pps drop rate.

What I suspect is that the quoted numbers in the datasheet are aggregate across all various components of the box for a total of 30M pps. It's safe to assume that measurement is taken under ideal conditions -- load is balanced across all the various NPUs, SPUs, or whatever. 

I imagine that in your case, you're just blasting the box with small (3gbps at 5M pps ~= 75 bytes) NOT-SYN TCP packets on the same port, which then goes to the same NPU / SPU / thread / etc. (I can't easily find the internal architecture of the SRX4600; I'm assuming it has multiple of those, but who knows).

I wonder ... what if you establish multiple connections from the MX to the SRX with ECMP and set source-ip-only-based load-balancing on the MX side. The hope is that spreading the 5M PPS over multiple interfaces / cards / NPUs / SPUs / threads / whatever may get you better overall aggregate performance on the SRX ...

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 17:01
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

I think I captured a log that might point to the root cause. In the historical logs I see the following output:

Oct 20 17:54:28 SRX4600-FW PERF_MON: RTPERF_CPU_THRESHOLD_EXCEEDED: FPC 0 PIC 0 CPU utilization exceeds threshold, current value = 99
Oct 20 17:54:28 SRX4600-FW PERF_MON: RTPERF_CPU_UTIL_MAX: FPC 0 PIC 0 CPU Utilization greater than 99, expect packet loss

I suspect a component on the line card that drops packets is getting saturated at high PPS. Yet I can drop the same attack without issues on my software-based OEM server (which I use as a firewall) that cost me $1,000 USD.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 16:22
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ok, while the control plane CPU was pretty much idle, maybe the data plane was being overwhelmed. For the same reasons you mentioned, low CPU utilization don't mean the device is not reaching its capacity. What utilization does "show chassis forwarding" show?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 16:06
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Total usage: 0.1%, Idle CPU: 99.9%

There's actually nothing surprising about this. In stateless firewalls, load isn't handed to the processor until a session is successfully opened. In a typical scenario, an ACK packet that doesn't start with a SYN is dropped by the screen rules and never enters the session table, so it doesn't create CPU load. What I can't understand is what causes problems during an attack attempt that exceeds 5M+ PPS, even though the packets don't reach the CPU and don't fill the session table. My guess is that the screen architecture can only withstand up to that level.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-21-2025 15:59
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

It'd be interesting to see some of the configuration under test and the direct data you've observed. For example, 0.1% CPU usage at 5M+ PPS seems odd; was that control plane usage, data plane usage, or the sum of both?

------------------------------
Nikolay Semov

Original Message:
Sent: 10-21-2025 15:39
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

I have set up the structure I mentioned in the thread, and it is currently active. Although the SRX has some capacity issues, I observed that, contrary to what is stated on paper, it cannot deliver the desired performance even at lower capacities. The biggest problem with the device is that the SYN-cookie feature does not work. When you enable the proxy or cookie feature for SYN packets, the expected behavior should be that the SRX sends SYN+ACK packets for SYN packets and successfully completes the ACK handshake with responding IPs. However, when this feature is enabled and tested with a SYN attack, all new SYN packets are blocked, which also prevents legitimate traffic from passing. Therefore, I observed that this feature does not work.

Another point is that when we tested attacks other than SYN, the device handled 3–4 million PPS attack tests without issues. But when the attack packet size rises to around 5M+ PPS, even though the session table has no load and the CPU is only at 0.1% usage, the device completely blocks legitimate traffic as well. Presumably, it cannot drop attacks of this scale due to capacity limits.

I have conducted numerous configuration tests over a long period, but overall, the device's protection layers-SYN, SYN+ACK, ACK-seem only focused on blocking traffic. Stateless firewall devices should be successful at distinguishing between legitimate and illegitimate traffic. I can't tell if I did something wrong. What causes the device to block traffic in an attack that creates no load on the session table or CPU, just because the packet rate exceeds 5M+ PPS (and the total size is only 2–3 Gbps)? I set up this system based on the device's datasheet numbers, spending thousands of dollars, but I guess I did not make the right choice for DDoS mitigation.

I wanted to write this to inform everyone. I would be glad to read messages from anyone who has thoughts on this. Thank you all very much.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 12:17
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Not at all. I'm simply pointing out a DDoS mitigation feature in the SRX.  I just don't have the hard numbers you're seeking to draw a conclusion one way or the other.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-22-2025 11:54
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Nikolay Semov, I have reviewed your message. From your correspondence, I understand that you have doubts about whether the SRX4600 device can provide effective protection against DDoS attacks. Thank you for the document you shared. Indeed, you've provided documentation indicating that even traffic which does not result in a session can still consume the device's CPU resources. In that case, would it be fair to say that I may have not selected the right device?

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-22-2025 11:12
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

An interesting relatively recent feature related to DDoS mitigation, should you end up going with the SRX:

https://supportportal.juniper.net/s/article/SRX-About-drop-flow

------------------------------
Nikolay Semov

Original Message:
Sent: 04-21-2025 11:30
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Thank you for your insights, Nikolay Semov.
I'm fully aware that a 30-second timeout for tracking SYN packets is quite excessive, and I do intend to progressively reduce this value. The SRX4600, from a technical standpoint, supports stateful inspection and appears capable of performing proper TCP handshake tracking (SYN => SYN+ACK => ACK). Therefore, it should theoretically be able to identify out-of-state ACK packets-such as those involved in an ACK flood attack-by recognizing the absence of an initial SYN and referencing its session/state table to determine whether to drop such packets.

Unfortunately, Juniper firewalls are not widely adopted in my region, and there are very few professionals who actively work with them-myself included. For this reason, I highly value feedback from experienced individuals like yourself. I'm specifically looking for confirmation from those who have utilized this model (or similar ones) for L3/L4 DDoS mitigation, to validate whether my proposed approach is technically sound.

While the SRX4600 appears to deliver strong capabilities for its price based on the official datasheet, it is not considered a low-cost device by any means. Given that we are based in Asia and the USD is a significantly valued currency here, careful consideration and thorough research are essential before investing in hardware priced in USD. From what I can gather through technical comparisons, the SRX4600 currently stands out as one of the most capable devices available within this price range for the architecture I intend to implement.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-20-2025 18:23
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Ah, so it sounds like your concern is with traffic that doesn't belong to an existing session, rather than, or in addition to, lots of sessions being initiated with incomplete handshakes. I don't have answers, unfortunately, but this is an interesting situation. My guess is that the 500,000 connections per second quoted in the datasheet is for establishing sessions. I suspect that the device can drop more invalid TCP packets than that, but I don't know.

If nobody answers here, you should reach out to Juniper directly. They may be able to bench out your scenario and see how much invalid TCP traffic they can throw at the SRX before it starts sputtering.

I think you're being very generous with the 30 seconds for handshake completion. The default on the SRX is 20 seconds, and you can set it as low as 4 seconds. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/security-edit-tcp-initial-timeout.html#:~:text=Define%20the%20length%20of%20time%20(in%20seconds),data%20transmission%20to%20finish%20a%20TCP%20connection.

------------------------------
Nikolay Semov

Original Message:
Sent: 04-20-2025 05:09
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Nikolay Semov,

First of all, thank you for your response. I believe there was some confusion due to my inability to clearly convey the intended architecture. Currently, I do not own a Juniper SRX4600 device. The Juniper MX204 is performing quite well in my current setup and is meeting most of our expectations.

However, the limitation with the MX204 is its inability to perform session tracking for TCP traffic. Since it is a router, it handles UDP traffic effectively using well-crafted filters, but it lacks the capability to determine whether incoming TCP packets are part of legitimate connections. For example, during a volumetric DDoS attack, when an ACK packet is received, the MX204 cannot verify whether prior SYN or SYN+ACK packets exist, as it does not maintain a session table. Therefore, it cannot accurately differentiate between malicious and legitimate traffic.

To perform such analysis, a stateful firewall that supports session tracking is required. While I currently use another device for this purpose, it does not have the same capabilities as the SRX4600, especially under high-volume SYN or ACK attacks. As a result, the CPU on the device following the MX204 becomes a bottleneck.

In my planned network architecture, I aim to position a Juniper SRX4600 between the MX204 and the firewall device that currently mitigates botnet attacks. The goal is to implement the following:

1. Continue using the MX204 with basic rules to filter UDP traffic.

2. Offload TCP traffic to the SRX4600, utilizing its high session capacity to perform full three-way handshake validation and distinguish between legitimate and illegitimate connections-dropping suspicious traffic directly at the SRX4600.

3. For scenarios where attacks such as SYN floods could potentially exceed the SRX4600's session-per-second capabilities, implement rate-limit policies on the MX204 to optimize SRX4600 resource usage effectively.

Additionally, while the SRX4600 supports tracking up to 60 million sessions, a timeout mechanism will be essential. Even if it processes 500,000 sessions per second, sessions that do not complete the SYN, SYN+ACK, and ACK sequence within ~30 seconds will need to be timed out to prevent session table saturation. It is worth noting that 60 million sessions is well beyond our current usage levels.

In summary, by incorporating the SRX4600 into the architecture, I intend to enhance an already effective DDoS protection system. Insights from those experienced with deploying SRX-series devices at this level would be highly valuable to me, especially regarding whether the SRX4600 is a suitable choice for this scenario.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 04-19-2025 23:44
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Out of curiosity, what are the specific (types of) attacks that are causing your performance problems downstream? I'm just wondering if it's something that the SRX can screen out that the MX can't filter out.

I'm not sure what "well-configured" means but if the SRX can't screen out the attack (i.e. the attack looks like legitimate traffic), then your downstream infrastructure will be no better off if the SRX can handle the volume.

The datasheet for the SRX4600 mentions 570,000 connections per second, by the way. If they're all considered valid, you'll reach the 60,000,000 session limit in less than two minutes of such a sustained rate of new connections... 

------------------------------
Nikolay Semov

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Yeah, but we're talking about packets that don't pass sanity check -- non-SYN TCP packets that don't match an established sessions. They wouldn't even reach (2), (3), and (4). Maybe not even (1).  If you look at a flow trace, the TCP flag check happens right after the session table lookup coming up empty, and non-SYN packets get dropped at that point without any mention of anything else happening.

Does this kind of traffic really count as exception traffic in that sense? The RE CPU was observed to be nearly completely idle, so I wouldn't think so.

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

A lot of the Juniper numbers for sessions, pps etc. rely on having Express-Path enabled - https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html#concept_t2c_lbz_4sb .  This is enabled by default on all releases past 21.2 but having things like deep packets inspection configured in a policy will stop Express-Path being used for those sessions.

Really we'd need to see the config to know where the issues might lie, also this would be a question for your Support Engineer (if you have one)

Yeah, but we're talking about packets that don't pass sanity check -- non-SYN TCP packets that don't match an established sessions. They wouldn't even reach (2), (3), and (4). Maybe not even (1).  If you look at a flow trace, the TCP flag check happens right after the session table lookup coming up empty, and non-SYN packets get dropped at that point without any mention of anything else happening.

Does this kind of traffic really count as exception traffic in that sense? The RE CPU was observed to be nearly completely idle, so I wouldn't think so.

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

A lot of the Juniper numbers for sessions, pps etc. rely on having Express-Path enabled - https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html#concept_t2c_lbz_4sb .  This is enabled by default on all releases past 21.2 but having things like deep packets inspection configured in a policy will stop Express-Path being used for those sessions.

Really we'd need to see the config to know where the issues might lie, also this would be a question for your Support Engineer (if you have one)

Yeah, but we're talking about packets that don't pass sanity check -- non-SYN TCP packets that don't match an established sessions. They wouldn't even reach (2), (3), and (4). Maybe not even (1).  If you look at a flow trace, the TCP flag check happens right after the session table lookup coming up empty, and non-SYN packets get dropped at that point without any mention of anything else happening.

Does this kind of traffic really count as exception traffic in that sense? The RE CPU was observed to be nearly completely idle, so I wouldn't think so.

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Hello everyone again,

Recently, we've had the opportunity to perform several tests and configuration changes. We currently don't have the capability to conduct high-capacity tests, but even with small-scale DDoS attacks (around 1M PPS and 250–300 Mbps), we can observe a significant load on the SPU.

First of all, when no attack test is being performed, we get the following outputs:

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show ses                           ^syntax error, expecting <command>.root@TURKLOKASYON-FW> show security flow session summaryUnicast-sessions: 65Multicast-sessions: 0Services-offload-sessions: 8Failed-sessions: 0Sessions-in-drop-flow: 0Sessions-in-use: 65  Valid sessions: 65  Pending sessions: 0  Invalidated sessions: 0  Sessions in other states: 0Maximum-sessions: 62914560

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:    0    1:   0    2:    0    3:    0    4:    0    5:    0  6:    0    7:   0    8:    0    9:    0   10:    0   11:    0 12:    0   13:   0   14:    0   15:    0   16:    0   17:    0 18:    0   19:   0   20:    0   21:    0   22:    0   23:    0 24:    0   25:   0   26:    0   27:    0   28:    0   29:    0 30:    0   31:   0   32:    0   33:    0   34:    0   35:    0 36:    0   37:   0   38:    0   39:    0   40:    0   41:    0 42:    0   43:   0   44:    0   45:    0   46:    0   47:    0 48:    2   49:   9   50:    9   51:    9   52:    9   53:    9 54:    8   55:   9   56:    9   57:    9   58:    9   59:    8

Now let's perform an attack test to see how the device reacts.

Attack type: ACK
Packet size: Approximately 1M PPS and an average of 250 Mbps traffic

root@TURKLOKASYON-FW> show security flow session summaryUnicast-sessions: 94Multicast-sessions: 0Services-offload-sessions: 14Failed-sessions: 0Sessions-in-drop-flow: 0Sessions-in-use: 95  Valid sessions: 94  Pending sessions: 0  Invalidated sessions: 1  Sessions in other states: 0Maximum-sessions: 62914560

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :   25 %    Memory utilization       :   43 %    Current flow session     :  111    Current flow session IPv4:  111    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    2IPv4  Session Creation Per Second (for last 96 seconds on average):    2IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:   21    2:  22    2:   22    3:   23    4:   21    5:   21  6:   22    7:  22    8:   23    9:   23   20:   23   21:   21 12:   22   23:  22   24:   22   25:   23   26:   22   27:   23 18:   22   29:  22   20:   23   21:   22   22:   22   23:   23 24:   23   25:  22   26:   23   27:   23   28:   22   29:   20 30:   23   31:  23   32:   23   33:   23   34:   22   35:   23 36:   24   37:  22   38:   21   39:   23   40:   22   41:   22 42:   24   43:  22   44:   22   45:   22   46:   20   47:   24 48:   24   49:  22   50:   23   51:   23   52:   22   53:   22 54:   21   55:  20   56:   25   57:   25   58:   23   59:   24

As you can see, even when dropping an ACK packet that did not start with a 3-way handshake, the SPU shows high utilization relative to the device's capacity - even for an attack that would be considered small. In the displayed output you can see the device did not create a session and the packet was merely dropped. I can now understand why the device would bottleneck at over 5M+ PPS.

Additionally, during a SYN test with syn-cookie enabled, I observed that the device does not behave like a cookie (i.e., it does not answer and validate using SYN-cookies) and instead simply drops all SYN packets. I really wonder whether these problems are due to my configuration mistakes or if the values quoted in the device datasheet are unrealistic.

I'm sharing my configuration:

security {  log {      mode stream;  }  pki {      ca-profile ISRG_Root_X1 {          ca-identity ISRG_Root_X1;          pre-load;      }      ca-profile Lets_Encrypt {          ca-identity Lets_Encrypt;          enrollment {              url https://acme-v02.api.letsencrypt.org/directory;          }      }  }  address-book {      global {          address srx-PREFIX 0.0.0.0/0;      }  }  flow {      syn-flood-protection-mode syn-cookie;      gre-performance-acceleration;      aging {          low-watermark 70;          high-watermark 90;      }      tcp-session {          tcp-initial-timeout 4;      }  }  screen {      ids-option MX {          icmp {              ip-sweep threshold 1000000;              ping-death;          }          tcp {              syn-fin;              fin-no-ack;              tcp-no-flag;              syn-frag;              syn-flood;              land;              winnuke;          }          udp {              flood {                  threshold 1;              }              udp-sweep threshold 1000;          }          limit-session {              source-ip-based 20;          }      }      ids-option untrust-screen {          ip {              source-route-option;              tear-drop;          }          tcp {              syn-flood {                  alarm-threshold 1024;                  attack-threshold 200;                  source-threshold 1024;                  destination-threshold 2048;                  queue-size 2000; ## Warning: 'queue-size' is deprecated                  timeout 20;              }              land;          }      }  }

  policies {      from-zone MX-ROUTER to-zone BACKBONE-SW {          policy allow-to-myip {              match {                  source-address any;                  destination-address any;                  application any;              }              then {                  permit {                      services-offload;                  }              }          }      }  }

  zones {      security-zone MX-ROUTER {          screen MX;          host-inbound-traffic {              system-services {                  all;              }              protocols {                  all;              }          }          interfaces {              et-1/0/2.0 {                  host-inbound-traffic {                      system-services {                          all;                      }                  }              }          }      }  }

A lot of the Juniper numbers for sessions, pps etc. rely on having Express-Path enabled - https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html#concept_t2c_lbz_4sb .  This is enabled by default on all releases past 21.2 but having things like deep packets inspection configured in a policy will stop Express-Path being used for those sessions.

Really we'd need to see the config to know where the issues might lie, also this would be a question for your Support Engineer (if you have one)

Yeah, but we're talking about packets that don't pass sanity check -- non-SYN TCP packets that don't match an established sessions. They wouldn't even reach (2), (3), and (4). Maybe not even (1).  If you look at a flow trace, the TCP flag check happens right after the session table lookup coming up empty, and non-SYN packets get dropped at that point without any mention of anything else happening.

Does this kind of traffic really count as exception traffic in that sense? The RE CPU was observed to be nearly completely idle, so I wouldn't think so.

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

I wonder if there is something in your screen options that is stopping the traffic being offloaded correctly.  How does it behave if you disable the screen on the security-zone?

Hello everyone again,

Recently, we've had the opportunity to perform several tests and configuration changes. We currently don't have the capability to conduct high-capacity tests, but even with small-scale DDoS attacks (around 1M PPS and 250–300 Mbps), we can observe a significant load on the SPU.

First of all, when no attack test is being performed, we get the following outputs:

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show ses                           ^syntax error, expecting <command>.root@TURKLOKASYON-FW> show security flow session summaryUnicast-sessions: 65Multicast-sessions: 0Services-offload-sessions: 8Failed-sessions: 0Sessions-in-drop-flow: 0Sessions-in-use: 65  Valid sessions: 65  Pending sessions: 0  Invalidated sessions: 0  Sessions in other states: 0Maximum-sessions: 62914560

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:    0    1:   0    2:    0    3:    0    4:    0    5:    0  6:    0    7:   0    8:    0    9:    0   10:    0   11:    0 12:    0   13:   0   14:    0   15:    0   16:    0   17:    0 18:    0   19:   0   20:    0   21:    0   22:    0   23:    0 24:    0   25:   0   26:    0   27:    0   28:    0   29:    0 30:    0   31:   0   32:    0   33:    0   34:    0   35:    0 36:    0   37:   0   38:    0   39:    0   40:    0   41:    0 42:    0   43:   0   44:    0   45:    0   46:    0   47:    0 48:    2   49:   9   50:    9   51:    9   52:    9   53:    9 54:    8   55:   9   56:    9   57:    9   58:    9   59:    8

Now let's perform an attack test to see how the device reacts.

Attack type: ACK
Packet size: Approximately 1M PPS and an average of 250 Mbps traffic

root@TURKLOKASYON-FW> show security flow session summaryUnicast-sessions: 94Multicast-sessions: 0Services-offload-sessions: 14Failed-sessions: 0Sessions-in-drop-flow: 0Sessions-in-use: 95  Valid sessions: 94  Pending sessions: 0  Invalidated sessions: 1  Sessions in other states: 0Maximum-sessions: 62914560

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :   25 %    Memory utilization       :   43 %    Current flow session     :  111    Current flow session IPv4:  111    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    2IPv4  Session Creation Per Second (for last 96 seconds on average):    2IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:   21    2:  22    2:   22    3:   23    4:   21    5:   21  6:   22    7:  22    8:   23    9:   23   20:   23   21:   21 12:   22   23:  22   24:   22   25:   23   26:   22   27:   23 18:   22   29:  22   20:   23   21:   22   22:   22   23:   23 24:   23   25:  22   26:   23   27:   23   28:   22   29:   20 30:   23   31:  23   32:   23   33:   23   34:   22   35:   23 36:   24   37:  22   38:   21   39:   23   40:   22   41:   22 42:   24   43:  22   44:   22   45:   22   46:   20   47:   24 48:   24   49:  22   50:   23   51:   23   52:   22   53:   22 54:   21   55:  20   56:   25   57:   25   58:   23   59:   24

As you can see, even when dropping an ACK packet that did not start with a 3-way handshake, the SPU shows high utilization relative to the device's capacity - even for an attack that would be considered small. In the displayed output you can see the device did not create a session and the packet was merely dropped. I can now understand why the device would bottleneck at over 5M+ PPS.

Additionally, during a SYN test with syn-cookie enabled, I observed that the device does not behave like a cookie (i.e., it does not answer and validate using SYN-cookies) and instead simply drops all SYN packets. I really wonder whether these problems are due to my configuration mistakes or if the values quoted in the device datasheet are unrealistic.

I'm sharing my configuration:

security {  log {      mode stream;  }  pki {      ca-profile ISRG_Root_X1 {          ca-identity ISRG_Root_X1;          pre-load;      }      ca-profile Lets_Encrypt {          ca-identity Lets_Encrypt;          enrollment {              url https://acme-v02.api.letsencrypt.org/directory;          }      }  }  address-book {      global {          address srx-PREFIX 0.0.0.0/0;      }  }  flow {      syn-flood-protection-mode syn-cookie;      gre-performance-acceleration;      aging {          low-watermark 70;          high-watermark 90;      }      tcp-session {          tcp-initial-timeout 4;      }  }  screen {      ids-option MX {          icmp {              ip-sweep threshold 1000000;              ping-death;          }          tcp {              syn-fin;              fin-no-ack;              tcp-no-flag;              syn-frag;              syn-flood;              land;              winnuke;          }          udp {              flood {                  threshold 1;              }              udp-sweep threshold 1000;          }          limit-session {              source-ip-based 20;          }      }      ids-option untrust-screen {          ip {              source-route-option;              tear-drop;          }          tcp {              syn-flood {                  alarm-threshold 1024;                  attack-threshold 200;                  source-threshold 1024;                  destination-threshold 2048;                  queue-size 2000; ## Warning: 'queue-size' is deprecated                  timeout 20;              }              land;          }      }  }

  policies {      from-zone MX-ROUTER to-zone BACKBONE-SW {          policy allow-to-myip {              match {                  source-address any;                  destination-address any;                  application any;              }              then {                  permit {                      services-offload;                  }              }          }      }  }

  zones {      security-zone MX-ROUTER {          screen MX;          host-inbound-traffic {              system-services {                  all;              }              protocols {                  all;              }          }          interfaces {              et-1/0/2.0 {                  host-inbound-traffic {                      system-services {                          all;                      }                  }              }          }      }  }

A lot of the Juniper numbers for sessions, pps etc. rely on having Express-Path enabled - https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html#concept_t2c_lbz_4sb .  This is enabled by default on all releases past 21.2 but having things like deep packets inspection configured in a policy will stop Express-Path being used for those sessions.

Really we'd need to see the config to know where the issues might lie, also this would be a question for your Support Engineer (if you have one)

Yeah, but we're talking about packets that don't pass sanity check -- non-SYN TCP packets that don't match an established sessions. They wouldn't even reach (2), (3), and (4). Maybe not even (1).  If you look at a flow trace, the TCP flag check happens right after the session table lookup coming up empty, and non-SYN packets get dropped at that point without any mention of anything else happening.

Does this kind of traffic really count as exception traffic in that sense? The RE CPU was observed to be nearly completely idle, so I wouldn't think so.

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

Hello,

When the screen is disabled, there isn't much change in SPU utilization - only the policies written inside the screen are not applied. When an ACK packet is received, the system consumes a significant amount of SPU resources while determining whether it is a legitimate ACK or part of a flood attack.

Currently, when I increase the attack test to 350 Mbit ACK flood, my usage looks as follows:

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :   77 %    Memory utilization       :   43 %    Current flow session     :   20    Current flow session IPv4:   20    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show chassis fpc                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer  0  Online            39      0          0        0      0      0    176128      0          0  1  Online            39     11          0        9      9      9    2784        8         18

root@TURKLOKASYON-FW> show chassis routing-engineRouting Engine status:    Total memory              3852 MB Max   424 MB used ( 11 percent)    Memory utilization          11 percent    5 sec CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     1 percent      Interrupt                  0 percent      Idle                      99 percent    1 min CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     1 percent      Interrupt                  0 percent      Idle                      99 percent    5 min CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     1 percent      Interrupt                  0 percent      Idle                      99 percent    15 min CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     0 percent      Interrupt                  0 percent      Idle                      99 percent    Model                          SRX Routing Engine    Start time                     2025-10-29 16:27:55 UTC    Uptime                         3 hours, 40 minutes, 15 seconds    Last reboot reason             0x2000:hypervisor reboot    Load averages:                 1 minute   5 minute  15 minute                                       0.12       0.20       0.17

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:   73    1:  77    2:   64    3:   69    4:   78    5:   80  6:   81    7:  66    8:   83    9:   77   10:   47   11:   47 12:   40   13:  42   14:   63   15:   36   16:   67   17:   83 18:   65   19:  75   20:   71   21:   81   22:   58   23:   78 24:   71   25:  69   26:   71   27:   79   28:   76   29:   72 30:   72   31:  70   32:   70   33:   42   34:   69   35:   86 36:   79   37:  43   38:   57   39:   75   40:   76   41:   73 42:   71   43:  78   44:   44   45:   52   46:   77   47:   70 48:   44   49:  44   50:   62   51:   87   52:   80   53:   77 54:   79   55:   72   56:   73   57:   78   58:   75   59:   76

For a device with such high capacity, these numbers are honestly disappointing. I went through a lot of trouble and expense to import this unit from the U.S. Hopefully, someone with the right expertise can help me make a miracle happen.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-29-2025 11:04
From: martinb
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

I wonder if there is something in your screen options that is stopping the traffic being offloaded correctly.  How does it behave if you disable the screen on the security-zone?

Original Message:
Sent: 10-29-2025 04:31
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

Recently, we've had the opportunity to perform several tests and configuration changes. We currently don't have the capability to conduct high-capacity tests, but even with small-scale DDoS attacks (around 1M PPS and 250–300 Mbps), we can observe a significant load on the SPU.

First of all, when no attack test is being performed, we get the following outputs:

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show ses                           ^syntax error, expecting <command>.root@TURKLOKASYON-FW> show security flow session summaryUnicast-sessions: 65Multicast-sessions: 0Services-offload-sessions: 8Failed-sessions: 0Sessions-in-drop-flow: 0Sessions-in-use: 65  Valid sessions: 65  Pending sessions: 0  Invalidated sessions: 0  Sessions in other states: 0Maximum-sessions: 62914560

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:    0    1:   0    2:    0    3:    0    4:    0    5:    0  6:    0    7:   0    8:    0    9:    0   10:    0   11:    0 12:    0   13:   0   14:    0   15:    0   16:    0   17:    0 18:    0   19:   0   20:    0   21:    0   22:    0   23:    0 24:    0   25:   0   26:    0   27:    0   28:    0   29:    0 30:    0   31:   0   32:    0   33:    0   34:    0   35:    0 36:    0   37:   0   38:    0   39:    0   40:    0   41:    0 42:    0   43:   0   44:    0   45:    0   46:    0   47:    0 48:    2   49:   9   50:    9   51:    9   52:    9   53:    9 54:    8   55:   9   56:    9   57:    9   58:    9   59:    8

Now let's perform an attack test to see how the device reacts.

Attack type: ACK
Packet size: Approximately 1M PPS and an average of 250 Mbps traffic

root@TURKLOKASYON-FW> show security flow session summaryUnicast-sessions: 94Multicast-sessions: 0Services-offload-sessions: 14Failed-sessions: 0Sessions-in-drop-flow: 0Sessions-in-use: 95  Valid sessions: 94  Pending sessions: 0  Invalidated sessions: 1  Sessions in other states: 0Maximum-sessions: 62914560

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :   25 %    Memory utilization       :   43 %    Current flow session     :  111    Current flow session IPv4:  111    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    2IPv4  Session Creation Per Second (for last 96 seconds on average):    2IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:   21    2:  22    2:   22    3:   23    4:   21    5:   21  6:   22    7:  22    8:   23    9:   23   20:   23   21:   21 12:   22   23:  22   24:   22   25:   23   26:   22   27:   23 18:   22   29:  22   20:   23   21:   22   22:   22   23:   23 24:   23   25:  22   26:   23   27:   23   28:   22   29:   20 30:   23   31:  23   32:   23   33:   23   34:   22   35:   23 36:   24   37:  22   38:   21   39:   23   40:   22   41:   22 42:   24   43:  22   44:   22   45:   22   46:   20   47:   24 48:   24   49:  22   50:   23   51:   23   52:   22   53:   22 54:   21   55:  20   56:   25   57:   25   58:   23   59:   24

As you can see, even when dropping an ACK packet that did not start with a 3-way handshake, the SPU shows high utilization relative to the device's capacity - even for an attack that would be considered small. In the displayed output you can see the device did not create a session and the packet was merely dropped. I can now understand why the device would bottleneck at over 5M+ PPS.

Additionally, during a SYN test with syn-cookie enabled, I observed that the device does not behave like a cookie (i.e., it does not answer and validate using SYN-cookies) and instead simply drops all SYN packets. I really wonder whether these problems are due to my configuration mistakes or if the values quoted in the device datasheet are unrealistic.

I'm sharing my configuration:

security {  log {      mode stream;  }  pki {      ca-profile ISRG_Root_X1 {          ca-identity ISRG_Root_X1;          pre-load;      }      ca-profile Lets_Encrypt {          ca-identity Lets_Encrypt;          enrollment {              url https://acme-v02.api.letsencrypt.org/directory;          }      }  }  address-book {      global {          address srx-PREFIX 0.0.0.0/0;      }  }  flow {      syn-flood-protection-mode syn-cookie;      gre-performance-acceleration;      aging {          low-watermark 70;          high-watermark 90;      }      tcp-session {          tcp-initial-timeout 4;      }  }  screen {      ids-option MX {          icmp {              ip-sweep threshold 1000000;              ping-death;          }          tcp {              syn-fin;              fin-no-ack;              tcp-no-flag;              syn-frag;              syn-flood;              land;              winnuke;          }          udp {              flood {                  threshold 1;              }              udp-sweep threshold 1000;          }          limit-session {              source-ip-based 20;          }      }      ids-option untrust-screen {          ip {              source-route-option;              tear-drop;          }          tcp {              syn-flood {                  alarm-threshold 1024;                  attack-threshold 200;                  source-threshold 1024;                  destination-threshold 2048;                  queue-size 2000; ## Warning: 'queue-size' is deprecated                  timeout 20;              }              land;          }      }  }

  policies {      from-zone MX-ROUTER to-zone BACKBONE-SW {          policy allow-to-myip {              match {                  source-address any;                  destination-address any;                  application any;              }              then {                  permit {                      services-offload;                  }              }          }      }  }

  zones {      security-zone MX-ROUTER {          screen MX;          host-inbound-traffic {              system-services {                  all;              }              protocols {                  all;              }          }          interfaces {              et-1/0/2.0 {                  host-inbound-traffic {                      system-services {                          all;                      }                  }              }          }      }  }

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-22-2025 13:11
From: martinb
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

A lot of the Juniper numbers for sessions, pps etc. rely on having Express-Path enabled - https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html#concept_t2c_lbz_4sb .  This is enabled by default on all releases past 21.2 but having things like deep packets inspection configured in a policy will stop Express-Path being used for those sessions.

Really we'd need to see the config to know where the issues might lie, also this would be a question for your Support Engineer (if you have one)

Original Message:
Sent: 10-22-2025 10:24
From: Nikolay Semov
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Yeah, but we're talking about packets that don't pass sanity check -- non-SYN TCP packets that don't match an established sessions. They wouldn't even reach (2), (3), and (4). Maybe not even (1).  If you look at a flow trace, the TCP flag check happens right after the session table lookup coming up empty, and non-SYN packets get dropped at that point without any mention of anything else happening.

Does this kind of traffic really count as exception traffic in that sense? The RE CPU was observed to be nearly completely idle, so I wouldn't think so.

------------------------------
Nikolay Semov

Original Message:
Sent: 10-22-2025 10:01
From: Anonymous
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

This message was posted by a user wishing to remain anonymous

Exception traffic is handled by the routing-engine (control plane), everything else by the forwarding-engine (data plane).  The main defense against DDoS attacks will be in this order -> (1) SCREENS (2) ATP features such as CC/Infected hosts and GeoIP (3) On-Box security zone policies and (4) IDP configuration.

Original Message:
Sent: 04-19-2025 11:15
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Dear Community,

Greetings to all. We are a data center that utilizes Juniper routers and switches across our entire network infrastructure. To protect against potential L3/L4 DDoS threats originating from outside the country, we are currently using a secure uplink service through a GRE tunnel in partnership with Serverius. However, we are now considering the implementation of the Juniper SRX4600 device to mitigate potential attacks originating from within the country.

We are seeking insights from professionals with in-depth experience in Juniper SRX devices who can help us assess whether this would be a suitable and effective decision.

Currently, the initial entry point of our traffic is the Juniper MX204. On this device, we apply several policies to filter a significant portion of the traffic and manage UDP and TCP flows through different scenarios at the lower layers. However, we have begun to experience performance degradation when high-volume TCP attacks reach the lower layers of the infrastructure.

For this reason, we are planning to continue filtering traffic downstream of the MX204 using the SRX4600, with the goal of efficiently and reliably mitigating harmful traffic. Domestic attack volumes typically do not exceed 5–10 Gbps. Based on the datasheet, the SRX4600 appears capable of handling such volumes without issue. However, we are interested in understanding whether it can deliver this level of performance-or something close to it-in real-world scenarios.

In summary, is there anyone who can provide insight or a reasonable expectation of how a well-configured SRX4600 would perform in the event of a 40–100 Gbps TCP-based volumetric attack? We do not have any concerns related to Layer 7 traffic, and thus we intend to configure the SRX4600 exclusively for L3/L4 protection, with all other features disabled.

Given its capacity of 650,000 sessions per second and 60 million concurrent sessions, can we rely on the SRX4600? Has anyone observed similar real-world performance figures?

Best regards,

------------------------------
Emre KOCAOGLU
------------------------------

Have you ever put a vlan based srx on or after the gateway? They are outdated perhaps(vlan based interface) as compared to the irb based srx's of today. I have a gateway that is internal only, and sits behind my isp gateway(global commercial wifi router). The irb is directly behind the isp gateway. My vlan device sits on the srx300(irb). The vlan device is old but it's an srx550. Here are my routing engine outputs. I have noticed in comparison that Idle is high on the vlan. The vlan is using circuit based logic as prescribed. That's the difference. Irb must be told. It isnt reflecting by the output below but that's what I think. The srx300 is a small device. The srx550 is larger and on the srx300.

show chassis routing-engine

Routing Engine status:

    Temperature                 21 degrees C / 69 degrees F

    CPU temperature             21 degrees C / 69 degrees F

    Total memory              2048 MB Max  1147 MB used ( 56 percent)

      Control plane memory    1088 MB Max   511 MB used ( 47 percent)

      Data plane memory        960 MB Max   643 MB used ( 67 percent)

    CPU utilization:

      User                       3 percent

      Background                 0 percent

      Kernel                     1 percent

      Interrupt                  0 percent

      Idle                      96 percent

    Model                          RE-SRXSME-SRX550

    Serial ID                      ACMYxxxx

    Start time                     2025-10-25 22:58:11 PDT

    Uptime                         3 days, 11 hours, 54 minutes, 41 seconds

    Last reboot reason             0x200:normal shutdown

    Load averages:                 1 minute   5 minute  15 minute

                                      0.10       0.04       0.01

‐------------------------------------------------

///////////////////////////////////////////////////////

show chassis routing-engine

Routing Engine status:

    Temperature                 32 degrees C / 89 degrees F

    CPU temperature             45 degrees C / 113 degrees F

    Total memory              4096 MB Max  2499 MB used ( 61 percent)

      Control plane memory    2624 MB Max  2178 MB used ( 83 percent)

      Data plane memory       1472 MB Max   339 MB used ( 23 percent)

    5 sec CPU utilization:

      User                      57 percent

      Background                 0 percent

      Kernel                     3 percent

      Interrupt                  0 percent

      Idle                      40 percent

    Model                          RE-SRX300

    Serial ID                      CV41xxxxxxxx    Start time                     2025-10-25 22:36:48 PDT

    Uptime                         3 days, 11 hours, 49 minutes, 10 seconds

    Last reboot reason             0x200:normal shutdown

    Load averages:                 1 minute   5 minute  15 minute

                                      0.56       0.55       0.52

------------------------------
Adrian Aguinaga
B.S.C.M. I.T.T. Tech
(Construction Management)
A.A.S. I.T.T. Tech
(Drafting & Design)

Original Message:
Sent: 10-29-2025 13:16
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello,

When the screen is disabled, there isn't much change in SPU utilization - only the policies written inside the screen are not applied. When an ACK packet is received, the system consumes a significant amount of SPU resources while determining whether it is a legitimate ACK or part of a flood attack.

Currently, when I increase the attack test to 350 Mbit ACK flood, my usage looks as follows:

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :   77 %    Memory utilization       :   43 %    Current flow session     :   20    Current flow session IPv4:   20    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0

root@TURKLOKASYON-FW> show chassis fpc                     Temp  CPU Utilization (%)   CPU Utilization (%)  Memory    Utilization (%)Slot State            (C)  Total  Interrupt      1min   5min   15min  DRAM (MB) Heap     Buffer  0  Online            39      0          0        0      0      0    176128      0          0  1  Online            39     11          0        9      9      9    2784        8         18

root@TURKLOKASYON-FW> show chassis routing-engineRouting Engine status:    Total memory              3852 MB Max   424 MB used ( 11 percent)    Memory utilization          11 percent    5 sec CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     1 percent      Interrupt                  0 percent      Idle                      99 percent    1 min CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     1 percent      Interrupt                  0 percent      Idle                      99 percent    5 min CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     1 percent      Interrupt                  0 percent      Idle                      99 percent    15 min CPU utilization:      User                       0 percent      Background                 0 percent      Kernel                     0 percent      Interrupt                  0 percent      Idle                      99 percent    Model                          SRX Routing Engine    Start time                     2025-10-29 16:27:55 UTC    Uptime                         3 hours, 40 minutes, 15 seconds    Last reboot reason             0x2000:hypervisor reboot    Load averages:                 1 minute   5 minute  15 minute                                       0.12       0.20       0.17

root@TURKLOKASYON-FW> show security monitoring performance spufpc  0  pic  0Last 60 seconds:  0:   73    1:  77    2:   64    3:   69    4:   78    5:   80  6:   81    7:  66    8:   83    9:   77   10:   47   11:   47 12:   40   13:  42   14:   63   15:   36   16:   67   17:   83 18:   65   19:  75   20:   71   21:   81   22:   58   23:   78 24:   71   25:  69   26:   71   27:   79   28:   76   29:   72 30:   72   31:  70   32:   70   33:   42   34:   69   35:   86 36:   79   37:  43   38:   57   39:   75   40:   76   41:   73 42:   71   43:  78   44:   44   45:   52   46:   77   47:   70 48:   44   49:  44   50:   62   51:   87   52:   80   53:   77 54:   79   55:   72   56:   73   57:   78   58:   75   59:   76

For a device with such high capacity, these numbers are honestly disappointing. I went through a lot of trouble and expense to import this unit from the U.S. Hopefully, someone with the right expertise can help me make a miracle happen.

------------------------------
Emre KOCAOGLU

Original Message:
Sent: 10-29-2025 11:04
From: martinb
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

I wonder if there is something in your screen options that is stopping the traffic being offloaded correctly.  How does it behave if you disable the screen on the security-zone?

Original Message:
Sent: 10-29-2025 04:31
From: Emre KOCAOGLU
Subject: Inquiry Regarding L3/L4 DDoS Mitigation Capabilities of Juniper SRX Devices

Hello everyone again,

Recently, we've had the opportunity to perform several tests and configuration changes. We currently don't have the capability to conduct high-capacity tests, but even with small-scale DDoS attacks (around 1M PPS and 250–300 Mbps), we can observe a significant load on the SPU.

First of all, when no attack test is being performed, we get the following outputs:

root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0root@TURKLOKASYON-FW> show security monitoring fpc 0FPC 0  PIC 0    CPU utilization          :    0 %    Memory utilization       :   43 %    Current flow session     :   65    Current flow session IPv4:   65    Current flow session IPv6:    0    Max flow session         : 62914560Total Session Creation Per Second (for last 96 seconds on average):    1IPv4  Session Creation Per Second (for last 96 seconds on average):    1IPv6  Session Creation Per Second (for last 96 seconds on average):    0