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,