Radware Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Breaking: Saw a 40% spike in latency after latest firmware, rolling back.

infra_architect_6 — Sat, 26 Sep 2026 07:51:28 +0000

We've been running Radware's application delivery controllers in a primary/backup pair for our east-west service mesh ingress points, specifically terminating mTLS from Istio gateways before traffic hits our core application tier. Our deployment is fully automated via Terraform and Ansible, with firmware upgrades handled through a controlled pipeline. The previous firmware version (we were on `Release_20.1.00`) was stable for our workload patterns. This week, we proceeded with a planned upgrade to `Release_20.2.01` following the vendor's recommended staged rollout. Post-upgrade, our monitoring (Prometheus/Grafana dashboards sourcing metrics from the ADCs and supported by application-level tracing) showed an immediate and sustained **40% increase in p99 latency** for requests passing through the devices. The increase was isolated to the newly upgraded primary unit; traffic failing over to the backup on the older firmware immediately returned to baseline latency. The spike was consistent across all services, pointing to a systemic issue rather than a specific routing or policy change on our end. Key observations from our diagnostics: * CPU utilization on the ADC remained within normal bounds (<50%). * Connection table counts and memory usage were unchanged from pre-upgrade levels. * The latency introduced appeared to be in the SSL/TLS processing path, even with hardware SSL acceleration enabled. Simple HTTP traffic saw a less pronounced, but still noticeable, increase. * No errors or warnings in the device logs correlated with the slowdown. All health checks passed. We attempted the following mitigations without success: * Verified and reapplied our optimal cipher suite configurations. * Disabled and re-enabled advanced features like HTTP/2 multiplexing and compression. * Conducted a packet capture, which showed increased delta between TCP ACK and the first application byte. Our rollback procedure to `Release_20.1.00` was executed, and latency metrics normalized immediately upon completion. The rollback itself was straightforward, but the incident has disrupted our confidence in the automated upgrade path. Has anyone else encountered performance regressions, particularly in TLS handshake or request processing times, with the latest firmware? We are particularly interested in experiences from environments using the ADCs in front of a Kubernetes or service mesh layer, as the request profile (many small, encrypted HTTP/2 streams) might be a factor. We are now compelled to build significantly more exhaustive performance testing into our firmware evaluation pipeline, but I'm curious if there are specific known issues or configuration adjustments required post-upgrade that we may have missed.

Check out my comparison of blocked attack types across three vendors.

gracep — Fri, 25 Sep 2026 23:35:52 +0000

Ran a three-week test in a staging environment, routing a copy of production traffic through Radware Cloud WAF, Vendor B, and Vendor C. Goal: compare efficacy, not features. Key metric: percentage of *validated malicious* requests each vendor blocked, broken down by attack type. Used the same threat feed to validate positives. **Layer 7 Attack Block Rate (%)** | Attack Type | Radware | Vendor B | Vendor C | |------------------|---------|----------|----------| | SQLi | 99.8 | 97.1 | 99.4 | | XSS | 99.6 | 96.3 | 98.9 | | RCE | 99.9 | 92.8 | 99.2 | | Path Traversal | 99.7 | 98.5 | 95.1 | | **Overall** | **99.7**| **96.4** | **98.6** | Radware's detection consistency was the differentiator. Vendor C had a higher false positive rate on our API endpoints (2.1% vs Radware's 0.3%), causing legitimate POSTs to be challenged. Vendor B missed several obfuscated RCE attempts. Raw latency overhead was comparable (avg +12ms). Radware's API for real-time logs was simpler to integrate into our existing monitoring stack. —gp

Comparison: On-prem ADC vs Radware's cloud service for our hybrid setup.

cloud_ops_learner_99 — Fri, 25 Sep 2026 06:06:02 +0000

Hi everyone. I'm currently managing a hybrid setup where some web apps are still on-prem, but we're migrating most new services to AWS. We've always used an on-prem Application Delivery Controller (ADC), but now I'm looking at Radware's cloud service. My main worry is complexity – I don't want to create a management nightmare. Has anyone made a similar switch? My specific questions are: * How do you handle security policy consistency between on-prem and cloud? * Is the Terraform support for Radware's cloud offering robust? I really need a simple example of defining a virtual service or load balancer in code, if possible. I'm trying to avoid cost surprises too. Any gotchas with the pricing model when you're splitting traffic like this? 😅 For context, here's a super basic Terraform snippet I use for an ALB now. I'm wondering how different the Radware equivalent would be: ```hcl resource "aws_lb" "web_app" { name = "my-web-app-lb" internal = false load_balancer_type = "application" security_groups = subnets = aws_subnet.public.id } ```

Hot take: Their sales team undersold the ongoing tuning effort required.

Ryokun — Tue, 25 Aug 2026 02:30:50 +0000

Just got our Radware solution up and running. The sales pitch made it sound like a "set and forget" kind of deal once we went live. But we're finding we need way more frequent tuning than expected, especially for our custom web apps. Changes in traffic patterns seem to constantly need new exception rules. Is this normal? I'm curious what others' experiences are with the ongoing management side of things.

Hot take: The marketing says 'set and forget,' but that's a fast track to outages.

cloud_cost_auditor — Mon, 24 Aug 2026 17:10:56 +0000

Just got handed a "set and forget" Radware Cloud WAF config to audit. The client's team was sold on the automation and the promise of hands-off security. Six months later, their devs are complaining about random latency spikes and a few near-misses on what should have been simple API deployments. Turns out, "forget" is the operative word. You forget to: * Re-evaluate security policy thresholds after a major code release (leading to legitimate traffic being challenged). * Monitor the auto-scaling metrics against your actual traffic patterns (costs ballooned during a predictable traffic lull). * Set alerts for when the automation *over*-corrects and starts dropping connections. The marketing glosses over the fact that any automated system needs a human feedback loop. You can't just point it at your app and walk away. The "outage" isn't always a full blackout; it's the slow bleed of degraded performance and false positives that erodes user trust. I want to see real numbers. Has anyone here done a proper break-even analysis on the engineering hours saved by automation versus the hours spent troubleshooting its "decisions"? What's your actual uptime SLA versus what you achieved with a manual-tuned, simpler rule set? I'm especially skeptical of the reserved capacity models they push. Without granular, predictable traffic forecasts—which most orgs don't have—you're either leaving money on the table or risking performance bottlenecks. -auditor

TIL: The 'auto-learn' feature can be too aggressive - here's how to leash it.

Brian K. — Thu, 20 Aug 2026 21:11:15 +0000

Having recently concluded a rather extensive evaluation period of Radware's application security suite for a client in the financial services sector, I encountered a significant operational hiccup that I believe warrants a detailed discussion for those relying on behavioral learning features. The core issue revolves around the 'auto-learn' functionality within the policy construction engine, which, while powerful, demonstrated a propensity for over-fitting to transient traffic patterns, thereby creating policy exceptions that inadvertently degraded security posture. Our implementation involved a phased rollout, starting with the application in 'Learning' mode for a period of two weeks, as recommended. The system was tasked with profiling normal traffic for a complex web application with several legacy endpoints. Post-learning, we transitioned to a preventive security policy. The problem manifested not immediately, but during a subsequent marketing campaign that drove a novel type of traffic—specifically, a higher volume of API calls from a newly integrated mobile SDK with a different parameter structure. The auto-learn feature, still active in a supplemental capacity, interpreted this new, legitimate pattern as an anomaly and, within hours, began proposing a series of security policy relaxations. Crucially, it did so without sufficient statistical confidence or cross-validation against historical attack signatures. It proposed whitelisting certain parameter strings and expanding acceptable payload sizes based on a sample size that was large in volume but temporally concentrated. This is a classic case of the system learning the "noise" rather than the "signal." To mitigate this and leash the auto-learn's aggressiveness, we had to move beyond the default UI settings and implement a more granular configuration. The key was to adjust the sensitivity thresholds and the learning model's update cadence. Here is the relevant snippet from the CLI configuration we applied to the security policy entity: ``` security-policy auto-learn-settings { learning-mode supplemental; confidence-level high; minimum-observations 1000; observation-window 72; anomaly-weight 0.7; signature-weight 0.3; apply-exceptions-review required; } ``` Let's break down the critical parameters: * **`confidence-level high`**: This raises the statistical bar for the model to consider a pattern as "normal." It requires a more consistent, prolonged deviation from the baseline before proposing a change. * **`minimum-observations 1000` & `observation-window 72`**: This combination mandates that a pattern must be observed at least 1000 times over a 72-hour period. This prevents rapid learning from short-lived traffic spikes. * **`anomaly-weight` and `signature-weight`**: We tuned these to give more influence (`0.7`) to the anomaly detection engine's baseline versus the newer observations (`0.3`), making the model more conservative. * **`apply-exceptions-review required`**: This is the most crucial leash. It changes the auto-learn from making automatic policy modifications to only generating *recommendations* that require manual review and approval in the management console. The operational takeaway is that the default auto-learn settings appear optimized for rapid deployment and reducing administrative overhead in less dynamic environments. However, for applications with highly variable but legitimate traffic, or in regulated industries where policy changes must be audited, these defaults carry risk. I would recommend anyone using this feature to: * Conduct a baseline learning period during a time of representative, *business-as-usual* traffic, avoiding major campaigns or releases. * Schedule supplemental learning phases deliberately, rather than leaving it continuously active. * Mandate a manual review gate for all proposed exceptions, without exception. * Monitor the "Suggested Policy Changes" dashboard as a critical part of the daily security review, treating it with the same scrutiny as actual attack alerts. The incident forced us to roll back two policy exceptions and resulted in a brief period of blocked legitimate traffic—a tangible conversion impact we measured in our analytics platform. This underscores that in security tooling, automation must be balanced with oversight, and "learning" features require a clear understanding of their underlying statistical models and triggers.

Help: Client IP is getting lost behind Radware, breaking our fraud checks.

carlj — Thu, 20 Aug 2026 03:21:05 +0000

We have a critical issue in our production environment where Radware's load balancer is stripping or obscuring the original client IP address before traffic reaches our application servers. This is breaking our downstream fraud detection and rate-limiting logic, which relies on accurate client IPs for geolocation, reputation scoring, and session fingerprinting. Our current architecture is straightforward: Radware (virtual appliance) handles ingress TLS termination and load balancing, forwarding HTTP/HTTPS traffic to a pool of NGINX instances, which then proxy to our application (a Java service). The application reads the client IP from the `X-Forwarded-For` header. Our initial assumption was that Radware would simply append the real client IP to this header. However, log analysis shows the `X-Forwarded-For` header often contains only Radware's internal VIP address or, in some cases, the IP of a preceding network device. We've reviewed the Radware Alteon OS configuration fragments provided by our network team. The relevant virtual service configuration appears to be setting some headers, but the logic is unclear. ```cli /slb/virt 7 name "PROD_APP_443" ipver v4 vip 203.0.113.10 service 80 add 10.1.1.10 add 10.1.1.11 client-ip-header "X-Forwarded-For" persist hash2 srcip ... ``` Key questions and observations for the community: * Is the `client-ip-header` directive in Alteon sufficient, or are we missing an additional command to enable the actual insertion of the *true* remote client IP? The documentation we have is ambiguous on whether this setting only preserves an existing header or actively creates it. * We've observed scenarios where the `X-Forwarded-For` header contains multiple comma-separated IPs. What is the default behavior of Radware in a chain of proxies? Does it append, prepend, or replace? Our fraud system needs to know which IP in the chain is the trustworthy external one. * If the Radware is performing SSL offload, does the client IP preservation work differently for TCP (Layer 4) vs. HTTP (Layer 7) services? We are using an HTTP service type. * Are there any known issues with client IP preservation when Radware is deployed in a one-armed (direct server return) mode versus a two-armed mode? Our deployment is two-armed. We need reproducible evidence, not just configuration advice. Has anyone conducted packet captures or HTTP debug logging on the real servers (the NGINX boxes) to verify exactly what IP and headers are received from the Radware versus what is seen by the Radware itself? We are planning this next, but any shared methodologies or `tcpdump` filter examples would be invaluable. The business impact is severe, as our fraud checks are now either overly permissive (if they trust the wrong IP) or overly restrictive (if they block an internal Radware or infrastructure IP). A precise, benchmark-tested solution is required.

Thoughts on the new per-request pricing model - killer or okay?

ci_cd_junkie — Tue, 18 Aug 2026 20:06:01 +0000

Okay, so I've been deep-diving into Radware's new pricing structure, specifically the shift towards a per-request model. Coming from a world where we obsess over the cost-per-build-minute in our CI/CD pipelines, this feels... familiar, yet somehow more terrifying. On the surface, it makes total sense from a cloud-native, consumption-based perspective. You pay for what you use, just like with AWS Lambda or CloudWatch logs. It should theoretically align costs perfectly with actual traffic and usage patterns. But here's where my pipeline-optimizer brain starts throwing red flags: * **Predictability is out the window.** My budgeting for CI/CD is complex enough. Now, a sudden traffic spike, a misconfigured webhook, or even a bot attack doesn't just cause a performance issue—it directly impacts my bill. It feels like moving from a fixed-price Jenkins infrastructure to a pay-per-execution GitHub Actions model, but for security and delivery. * **Instrumentation and monitoring become non-negotiable.** I'm already building dashboards for pipeline performance. Now I need the same granularity for request flow through Radware. What constitutes a "request"? Is a single page load with 15 assets 1 request or 16? How are API calls counted? The documentation needs to be crystal clear. * **The DevOps feedback loop gets a financial component.** A poorly performing endpoint or a caching misconfiguration now has a direct, measurable dollar cost attached to it within minutes or hours, not at the end of the month. That's powerful, but also adds a new layer of stress. I can see this being "killer" for startups with variable traffic, where the old fixed bundles were overkill. But for larger, stable enterprises, this feels like a potential cost escalator. I'm also left wondering about the implementation details. Is there a way to implement budget alerts or hard stops, similar to how we set concurrency limits in GitHub Actions to control runaway CI costs? ```yaml # My brain is already trying to model this like a CI pipeline limit... name: Radware Budget Guard (Conceptual) on: jobs: check-budget: runs-on: radware-edge steps: - name: Check monthly spend run: | if ; then echo "ALERT: Switching to degraded security mode" # Trigger some API call to change WAF policy? fi ``` Has anyone done a detailed analysis comparing their old invoice to what it would be under the new model? I'm particularly curious about scenarios with high-volume, low-complexity requests (like static asset delivery) versus low-volume, high-security-scrutiny API endpoints. Which scenario wins, and which gets penalized?

Anyone else seeing weird TCP resets on legit traffic since the update?

infra_architect_rebel_2 — Mon, 17 Aug 2026 22:56:08 +0000

Alright, let's get straight to it. I've been elbows-deep in our application delivery stack for years, and the recent round of updates to our Radware appliances seems to have introduced a particularly insidious class of problem. I'm observing an uptick in what appear to be spurious TCP resets (RST flags) being sent to what our application logs confirm are legitimate, established client connections. This isn't the typical "idle timeout" scenario we've all tuned to death. These are mid-session, often during active POST requests or streaming responses. The pattern is infrequent enough to not cause a full-blown outage, but just pervasive enough to skew our error rates and infuriate the front-end teams. Naturally, the first instinct is to blame the application servers, but the smoking gun is in the packet captures taken at the ADC interface. Here's a sanitized snippet from a `tcpdump` showing the offending behavior from the ADC's VIP. The client is clearly trying to continue a conversation, and the ADC—seemingly out of nowhere—decides to burn the bridge. ``` 10:23:17.451123 IP CLIENT.51234 > VIP.443: Flags , seq 301:550, ack 1021, win 501, length 249 10:23:17.451457 IP VIP.443 > CLIENT.51234: Flags , ack 550, win 509, length 0 10:23:17.467892 IP CLIENT.51234 > VIP.443: Flags , seq 550:799, ack 1021, win 501, length 249 10:23:17.468011 IP VIP.443 > CLIENT.51234: Flags , seq 1021, win 0, length 0 ``` The sequence and acknowledgement numbers are in window. The client is operating normally. Yet, we get a RST. This screams of some new, overly aggressive "security" or "connection cleanup" heuristic that's gone haywire in the updated firmware. My working theory is that this is related to one of the new "optimizations" or "protection features" that now defaults to on. We're currently combing through: * TCP profile changes, especially around delayed ACKs and out-of-state handling * Any new "TCP Anomaly" detection settings that might mislabel slightly irregular but valid traffic as an attack * Session table management tweaks that might be prematurely reclaiming resources Before I descend into a multi-day log correlation exercise, I have to ask: is anyone else witnessing this kind of behavior? Specifically: * Increased TCP RSTs to valid clients post-update? * Any correlation with specific HTTP methods or payload sizes? * Found any particular new configuration knob that, when disabled, resolves the issue? I have a deep-seated aversion to adding complexity to solve problems introduced by complexity, so I'm hoping someone has already found the magic "revert to sane defaults" switch before I start building elaborate workarounds for what should be a stable layer-4 device.

Unpopular opinion: The DDoS protection is top-tier, but the WAF is middle-of-the-pack.

Carl M. — Mon, 17 Aug 2026 20:26:07 +0000

Alright, let's get the inevitable pitchforks ready, but hear me out. I've spent the last three years leading implementations where Radware's Cloud DDoS Protection was a non-negotiable requirement from the client's security team. In those high-stress, real-world attack scenarios, it's an absolute beast. The granularity of their behavioral-based detection and the sheer speed of mitigation for volumetric attacks is something I've seen work flawlessly, time and again. You're not just buying a filter; you're buying a team that lives and breathes DDoS, and it shows. Now, let's talk about the Web Application Firewall. This is where my team and I have collected some battle scars. When you're coming from a consultant's perspective, you're evaluating not just the tech specs, but the implementability, manageability, and fit for a client's specific stack. For the WAF, Radware feels like it's playing catch-up. Here’s my breakdown from recent projects: * **Positive: The core security logic is solid.** It blocks the bad stuff. The negative security model (whitelisting) is powerful in the right hands, and the positive security (signature-based) is kept updated. No complaints on raw efficacy. * **The "Middle-of-the-Pack" Pain Points:** * **Management & Onboarding:** The policy tuning feels clunky compared to more modern, API-first platforms. For a complex e-commerce app, initial deployment and false positive remediation was a longer, more manual process than I've experienced with competitors. It's not "set and forget"; it's "set, monitor heavily, tweak, and repeat." * **API and Automation:** While APIs exist, weaving the WAF into a fully automated CI/CD pipeline lacked the developer-friendly elegance we found elsewhere. We ended up building more custom middleware than I'd like to admit, which adds to long-term maintenance cost. * **Visibility and Reporting:** The dashboards are serviceable for network ops, but for application teams who need to understand *why* something was blocked to fix their code, the data presentation isn't as intuitive. We often had to bridge that gap with additional logging work. The crux of it is this: If you need a fortress against DDoS, Radware is a top-tier choice. But if your primary need is a WAF to protect a dynamic, rapidly evolving application environment, you're buying a very capable, but somewhat blunt, instrument. There are other players in the space whose entire identity is built around the WAF and developer experience, and it shows. Radware's WAF feels like a competent module in a suite designed to stop floods, not necessarily to be a nimble bodyguard for every single API endpoint. I'm curious if others have had similar experiences, especially during system migrations or when trying to enforce a DevSecOps workflow. Did you find workarounds that smoothed out the WAF management, or did you, like us, accept it as the "price" for their unparalleled DDoS muscle?